This was caused by the same bug I added a workaround for in a02c568b785f9d30373aef806507da60000ff1c9.
Essentially, the differing size of player_teams_ and team_names_ could cause an index mismatch if
some sides had allow_player=no and debug mode wasn't on. I didn't notice this before since I always
work with debug mode on.
I've reworked the connect_engine handling of team data. Now, the team_name, user_team_name, and an
is-player-allowed-to-be-on-this-team flag are all handled by a data pod. I've completely removed the
player_teams stuff and instead generate an applicable list of teams for the team menu_button to
display at runtime.
To get around the index disparity issue, I save any displayed team option's index (relative to
connect_engine::team_data) in that option's config (the one then passed to the menu_button). This
allows me to get an appropriate value to pass to connect_engine::set_team without any fancy find-
and-adjust calculations.
See this thread, along with a few linked within:
https://forums.wesnoth.org/viewtopic.php?f=12&t=47704
The purpose of this is both to:
a) Make the unit names more descriptive, so new players especially will have an easier time learning them and knowing what they do.
b) Make them eligible for translation, like the units of other factions are.
This commit only renames the files, along with the faction/AoH faction and wmllint.
Celticminstrel recommends restricting this to off-map units until we can be sure
changing the ID is safe in all contexts. I don't see why not, though... but this
should be enough for the situation described in the bug (a unit made with copy_unit).
Turns out that it's still crashing on startup in Travis,
but no longer giving the old error message
Xlib: extension "RANDR" missing on display ":99.0".
I also removed the old line that ran test_executor.sh only if WML tests had
failed. That made no sense.
Regression from commit f2b31ba082e1ff47443120469e06b89318f37284.
The calls to get_fake_display() must not be removed. They are essential to
change the size of the fake screen. Fortunately we have a unit test to
check that constructing GUI2 windows doesn't succeed if the screen is way
too small.
