Comparing signed and unsigned numbers can result in a negative number
matching a positive one, which is why compilers emit a warning about it.
See boostorg/test#129. I originally missed that the issue was in our code.
Accidental regression from fbb0e0229cf4c870fef69e0b6729e9a1ea69b6fe. The variable validation
code was changed to use config::valid_tag instead of config::valid_attribute, which was the
new name of config::valid_id.
- after the change to the tentacle, adjust HP to match 500 again
- let the teamname more sound like an easter egg
- apply the same lock settings as to similar scenarios
[ci skip]
Because there are just two, and nobody should join the AI team
When playing without default settings all kind of team combinations are possible
[ci skip]
In these cases they have only in limited situations an effect:
In normal play the sides are hidden, if not using map settings they are ignored,
so this mostly only has an effect if starting the game in debug mode an using map
settings.
Other ones revert acidental changes caused by force_lock_settings.
fore_lock_settings does not only disallow the player to modify the settings,
but does also serve as default value for all the other lock settings.
The above issue was caused by the fact that image::flush_cache() wasn't called after
reload_changed_game_config() when the addons manager was exited. Using F5 at the tilescreen
caused the image to appear since that callback *did* include image::flush_cache();
reload_changed_game_config() was called in 5 places, 2 of which were followed by flush_cache.
I figured it's safest to just include the latter in the former, since the other three usecases
(multiplayer installed addons before joining a game, a new core was selected, and the addons
manager was exited) all seem like places where flushing the image cache would be appropriate.
The proliferation of game_display::get_singleton() was due to 786233d5c95913889d6f061f3749f80a5efd61c1
where I replaced resources::screen (itself a game_display* pointer) with the game_display singleton.
Using the game_display pointer has already caused one case of UB (issue #2447), so I figured it best to
call the base class pointer in all cases where a game_display-specific function or override was not used.
Was UB when drawing the minimap in the editor since the display object was an editor_disply
not game_display. No reason to access game_display anyway, since is_blindfolded() is defined
in display.
Cropped up in 786233d5c95913889d6f061f3749f80a5efd61c1.
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.
