The unit::get_ability_bool() function accessed resources::gameboard that
is not set in the editor. Now the function receives the display context
as a parameter instead.
I also fixed two crashes on editor startup in MSVC debug builds (both
caused by indexing the teams vector when there aren't any teams), and the
GUI2 unit list dialog showing wrong status icons.
Plus two minor changes:
- Support [spacer] to add space between options
(This may or may not be kept indefinitely)
- Deprecate the misleading [combo] in favour of [choice]
This goes along with the principle of using references when a pointer
cannot be null. It's also better for data encapsulation to not give
someone the address of one of your private data members.
When pressing End Scenario and proceeding to the next scenario, the user_team_name shown on Menu|Status Table is incorrect.
If you Load (from the title screen) the saved scenario-start, the correct user_team_name appears.
This is caused by the random-shuffle feature for multi-player scenario. This fixes it for Single-Player campaigns and tries not to break it too badly for randomized Multi-Player campaigns.
This means:
1. Adding the new CA to AI configs
2. Removing it whenever the combat CA is removed
3. Preventing conflicts for AIs that previously used overlapping scores
It depends on timing whether or not the guest shows the wait dialog between
scenarios. If the second scenario has already started when the guest tries
to show the dialog, the dialog is skipped: otherwise it's shown and it
changes the plugin context.
The join.lua plugin assumed the change of plugin context to mean that the
test is over and that the plugin should quit the game. As a result, it
ended up quitting in the middle of the test if the second scenario hadn't
started yet.
Commit 6016bdf2 tried to fix the problem by allowing the plugin context to
change once during the test. It resulted in the opposite problem: if the
second scenario *had* started, the plugin context didn't change. When the
test ended and the guest was thrown into the lobby, then the plugin
assumed that it was just the scenario change and kept waiting for the next
scenario that wasn't coming.
This commit finally fixes the problem by explicitly polling the name of the
scenario being played. Now join.lua ignores plugin context changes as long
as the last scenario hasn't started, but starts waiting for the game to end
when the scenario starts.
I verified locally that, with these changes applied, the tests pass both
with an unmodified build and with a build that has an artificial delay to
simulate the timing in Travis.
