Re-add the popup that appears when "Load" is pressed on the title screen if
there are no files, but now check for files from previous versions too.
Improve handling of switching from a version with files to a version without
files, disabling buttons on the load dialog when there are no files in the
current directory. Versions with no files will still be shown in the drop-down.
This adds a todo about the error path at the start of evaluate_summary_string,
this path is reached by creating empty files in the save dir. The dialog's state
is reasonable, so it seemed a low priority and I don't want to introduce new
bugs by refactoring this path now.
Deleting all files now doesn't automatically close the dialog.
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.
It was already considered for registering halos, just not for rendering
regular frames. This commit touches the halo code a little so we don't
need to call get_zoom_factor() multiple times per frame.
Closes#5508.
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
The change to static_cast for the definition of LUAL_BUFFERSIZE replaces the fix previously used (d0100758f8) for Lua 5.3. 5.4 removes the static alternative for LUAL_BUFFERSIZE. A better solution would probably be to disable the old-style-cast warning for luaconf.h, but I can't figure out how to do that so using static_cast is the easiest solution. Do note that change will have to be applied each Lua update like the aforementioned commit.
The first issue was difficulty_dialog::show being called twice. The second issue was that show_difficulty_dialog
was called from both load_game_ingame and load_game. The latter is called after the former (this should probably
be refactored), so if you selected Change Difficulty when loading from within a game, the dialog prompt would be
shown when both functions were called. Fixed this by toggling off the show_difficulty flag once a difficulty had
been selected.
These now work:
[resistance_defaults]
id="special_res_for_test"
default="30"
[/resistance_defaults]
[resistance_defaults]
id="copy_of_arcane"
default="(arcane)"
[/resistance_defaults]
and so do these:
[terrain_defaults]
id="special_terrain_for_test"
[movement_costs]
default="(swamp_water + 1)"
orcishfoot="(vision_costs.swamp_water * 2)"
[/movement_costs]
[/terrain_defaults]
[terrain_defaults]
id="special_terrain_for_test"
[defense]
default="(20 + 7 * movement_costs.special_terrain_for_test)"
[/defense]
[/terrain_defaults]
For [terrain_defaults], I've approached it as a new feature rather than a
simple fix. The subtags now use the same names as the [movetype] subtags and
[effect]'s `apply_to` attribute, so [terrain_defaults][movement_costs] instead
of [terrain_defaults][movement].
The formula handling will now recognise "resistance", "movement_costs",
"vision_costs", "jamming_costs" and "defense". For [resistance_defaults], the
formula will recognise both "(arcane)" and "(resistance.arcane)" as equivalent,
similarly for [terrain_defaults] "(swamp_water)" is a shorthand for whichever
subtag is being patched.
A [terrain_defaults] tag may use data added in a previous [terrain_defaults],
as in the examples above where the second tag's [defense] is based on the first
tag's [movement_costs], this gives orcish grunts on the special terrain a 62%
chance to be hit. However, relying on data in the same [terrain_defaults] that
creates or changes it is unsupported - if the [movement_costs] and [defense]
were in a single [terrain_defaults] tag then the result would be implementation
defined, because no guarantee is made of the order in which the children of the
tag are processed.
The schema gets fixed for [resistance_defaults] and [terrain_defaults], as it
only allowed one instance of each tag. The subtags of [terrain_defaults]
already had the new names.
In the schema's MOVETYPE_PATCHING macro, the default= key is mandatory except
for the types that fallback to using movement costs as their default. The tag's
implementation doesn't need it, however omitting it seems more likely to be
an oversight than a deliberate use of an edge case.
This commit is on the master branch. There have been no changes at all to the
editor documentation in the 1.14 branch, while there have been several updates
to the master branch that would be good to backport if the help is displayed in
the 1.14 branch - therefore my plan is to get this set of changes reviewed in
the master branch, and then simply pull the entire file into the 1.14 branch
along with enabling the editor documentation (a small change to
data/core/help.cfg, as done in commit
ed611f9438).
A couple of warnings about the scenario mode being buggy are added to the
user-visible text, find these by looking for <bold> tags within the text.
