Categories vs. Filter both deal with filtering -- the only difference is
that categories has a broader scope than the name-based filtering, with
the latter being applied to results for the selected categories. We
don't need two rows for both.
This is specifically meant to address the sidebar gaining a short
vertical scrollbar at higher resolutions because of button sizes
increasing slightly.
The hardcoded size of the window was too small for the large fonts on HDPI
displays, this changes to using the automatic width and calculated-based-on-dpi
height. On HDPI displays that does leave blank space on the General tab, but it's
better than not scaling.
Buttons that were placed at the bottom of pages move up so that they aren't
too far from the other controls. The sub-tab-selector buttons on the
multiplayer tab move above the sub-tabs themselves.
With HDPI text, the checkboxes are placed a little too high to align with
the font, but that's a cosmetic detail; this commit fixes the usability issue.
* Moved the combobox (sorry celmin) to the top right in a manner akin
to the search boxes in dialogs with those.
* Switched list headers to using the gold_small label variation.
This replaces the Reset button with a dedicated listbox entry, and
replaces the selection status text with code that sets the initial
selection for the listbox and an icon that's used to display whether a
selection applies globally or only to the current unit.
This does alter some of the code significantly to make it less "clever"
(no more dynamic build) but also less hostile to future modifications
like this.
(CC #5555)
While implementationally it's very simple, the feedback so far (minimal as it may be) has been negative due to the side effects on existing gameplay mechanics:
* Delaying advancement until the next time it's the advancing unit's side's turn gives enemies a much larger window to kill the unit to prevent it from leveling up.
* The majority of units don't have multiple advancement options, so delaying their advancement as well isn't helpful.
Additionally, leaving this in for 1.16 would mean that it would not be possible to remove it in 1.17 or later without breaking any replays that did use it.
As the disengaged state is part-way between the "partial" and "moved" states,
the orb has parts in each color. On the minimap these units are shown in the
partial color (which is also the color that would be used before this change).
This will match the mounted Quenoth units' "disengage" skill, when they
can still move but can't attack. It should also trigger for some UMC abilities
that get extra moves after a character attacks.
During testing, I found that TSG allows some of the bandits to attack on the
first turn of the bandit branch. There's no gameplay change there, but the orbs
make it much clearer that some units can still attack.
I think there are already too many preferences for orbs, so reused the existing
settings for the colors. A new "show disengaged orb" preference is added, which
when disabled shows the old partial orb instead.
Update the orb and ellipse sections of doc/manual/.
Notes about how I created the new orb image:
* create a color range to_ellipse_red with rgb=FF0000,FF0000,000000,FF0000
* wesnoth --render-image 'misc/orb.png~RC(magenta>to_ellipse_red)' images/misc/orb-ellipse-red.png
* open the orb.png and orb-ellipse-red.png images as layers in Gimp, add a layer mask to both of them
* use the layer mask to get each pixel from exactly one of the layers