This removes `get_teams()`, `get_units()`, and `get_map()` from the display class. These only served as one of the many, many ways to access this data held by the display_context, and that shouldn't be the first-class responsibility of display. Instead, we either access them through the display_context pointer that display holds (whose getter has been renamed to `context()`) or through other more convenient paths (such as play_controller). The editor_display function `map()` has now taken up the mantle of `get_map()`, mostly because both `display::get_map()` and `editor_display::map()` are used, and the former outnumbered the latter.
Removed:
- debug_highlight et al. Unused, and we have the main "display coordinates" debug flag in the base class
- current_team_name. Only used in one place, clearer to just call team_name directly.
- get_terrain_on. Unimplemented
... to fix compile issues with boost 1.86.
Commit 9c665ae3c4684f8826f4b7d8e0a75b9a986e8617 does the same
for wesnothd, but campaignd still fails to compile with
overload resolution failure.
References #9284
I have no idea what's going on with the transition from ubuntu-latest from 22.04 to 24.04. It switched to 24.04, and now it looks like it's back to 22.04...
See https://github.com/actions/runner-images/issues/10636
Rename location_palette::can_swap() to the correct name so that it
overrides as intended, thus making the UI disable the "swap fg and bg
items" button.
The class structure doesn't match the responsibilities here, as part
of UX isn't part of the palette, rather it's part of the tool that
decides whether there are fg and bg items - alternatively, the tool
decides whether right-click is "place bg item", "delete items", or
"show unit tool options". However, this change seems to be enough to
make the UX correct.
The "virtual" is redundant, but add it for consistency with the other
code in these classes.
When I use an ability id=A and include [filter][filter_adjacent]ability_id_active=A, the more units with the adjacent ability I add to it, the slower the game becomes, and at the third unit the game freezes, whereas with the direct comparison of the configs the game only slows down significantly after the 5th unit added.
The only place that used these was the lua show_dialog implementation. We can just construct the window object directly instead. Since this skips out on the finalize_build step (which in the case of modal/modeless_dialog was being called by those respective ctors), I've removed that function and merged it into the window ctor. No need to do it separately.
Builds on work in af81bba53b00d29e65ee5b7b89019f27457914d7 and 247e5ff05555bb6b937036c16d0cfeeae4fd5d35
Note that location_palette::get_help_string is not virtual as it does not inherit from editor_palette (where the pure virtual get_help_string is defined) but rather common_palette.
Resolves https://github.com/wesnoth/wesnoth/issues/7926
[filter_ability] and [filter_ability_active] have been merged into a single filter equipped with the 'active' attribute which when the value is 'true' checks the units affected by the sought ability and when the value is 'false' or unset will check the units carrying the ability even if they are not affected by it.
Because of the attribute strategy, I'm afraid that the developer will be mistaken about its function and that's why I'm not at all keen on it but I want to get out of this impasse.