This work since vector::at throws if i < size(), and the current check was for
> size() - 1, which equated to >= size(), which is equivalent to not < size().
It does lose the error message, though.
Because updating and sending messages to lobby in staging screen hasn't
been implemented, showing lobby history there would be confusing
(it would look as if everyone had stopped talking).
Three cases could not use emplace_back since the ctor they use is private... :(
Which sucks since unit_animation looks like it'd be a bit expensive to copy.
This commit does a few things:
First, it moves the hotkey category names out of the preferences dialog and into
the more appropriate hotkey file. Each name is now properly mapped to its corresponding
category enum, so we don't have to worry about that anymore.
Second, it adds a new mapping of hotkey categories to commands so one can easily fetch
a list of hotkeys in a given category.
Third, it excludes categories with no hotkeys from the filter dropdown in the Prefs
dialog (this is the part that actually fixes the bug above).
This also includes a slight behavior change to hotkey type filtering. Previously, if a
hotkey's category didn't match any of the ones listed in the dropdown, that hotkey's
row visibility would be set to the toggle state of the first row in the filter dropdown.
Now it gets set to false.
Reported in https://forums.wesnoth.org/viewtopic.php?p=626344#p626344
Regression from commit a3d5b9d603.
The crash occurred when
* the attacker had only one weapon
* the said weapon was disabled, and
- the defender had no weapons
- the defender had only one weapon, or
- all defender's weapons were disabled
previously, if people wanted to make use of mp leader selection in mp
campaign they had to sxplicitly set no_leader=no and faction_lock=no,
with the new code its clear that no_leader= is just an alias for
faction_lock with type
Includes a minor cleanup of the Game Stats dialog to not use a game_board reference.
Dunno why I was taking a game_board reference in the show() function anyway... the
class held a display_context reference and didn't use any functions exclusive to
game_board.
This is to avoid confusion with filter_context::get_disp_context. display used to
inherit from filter_context, but that was refactored out a while back. I left
get_disp_context since it was used and useful, but I realize now it causes more
confusion than not.
Also converted help::load_terrain_types_data to use get_map() directly since I
noticed it.
And changed a stray use of `thedisp` to `disp` in unit_drawer. Doesn't do anything
but it was bugging me.
This was essentially only needed for the affects_side() helper. THAT'S IT. All this code just for
one single line... Anyway...
Utilized the display singleton's display_context getter instead. This also means fewer explicit
uses of resources::gameboard as the display_context object, meaning more compatibility with the
editor (not that that's relevant for most of the changed usecases, such as the AI, but it does
affect unit::get_abilities, which might be useful there in the future).
This also removes the display_context parameter from unit::invisible() since it was only passed to
unit::get_ability_bool().
unit::is_visible_to_team() also had its display_context parameter removed. It was used once as an
argument for invisible() and the other case was replaced with display::get_map().
Instead of a pointer to a member of a derived class, used a virtual function implemented
in both derived classes (game_display and editor_display) that return an reference to the
appropriate object.
Also removed the overlay.hpp include from display.hpp. We can forward-declare the overlay
struct.
