The reported issue being that the FORCE_CHANCE_TO_HIT macro was able to force an increase in an attack's chance to hit, but no longer able to force a decrease.
Back when link awareness was first added (https://github.com/wesnoth/wesnoth/pull/300), this key was added
globally to label definitions alongside link_color. This had the unintended side effect of making *all* labels
link aware, leading to issues such as being able to open a do-you-want-to-open prompt from an instance of the
same ad-infinitum.
This became an active issue after 213453e6cf, since now that labels could capture
focus if link_aware was true - which it always was for most labels - labels in toggle panels would always
grab mouse_motion events and no longer allow their parent toggle panels to gain their hovered states. That
appears to be in keeping with the design of GUI2, and a further evaluation of that issue is needed at a later
time. However, the fact remains that almost every single label was marked as link-aware, even when in almost every
case that was not the desired behavior.
This change move the link_aware config option to individual label and scroll_label instances. The following uses
had this explicitly enabled:
- Addon license prompt
- Addon descriptions
- Campaign descriptions
- The Server Info popup
- The chatbox
This also moves gui2:🏷️:can_mouse_focus()'s declaration to a
section that makes more sense for it to be in. Thanks to jyrkive for
pointing out the existence of this method.
Fixes the dreaded "Mandatory WML child missing yet untested for. Please
report" error occurring when reading _info.cfg files that don't have a
valid [info] tag. In particular, this would cause the game version
dialog to crash to desktop.
Fixes#5256, which was that `{SAVE_ZOMBIE_LIST rastabahn_zombies}` overwrote
the ardonna_zombies variable.
Move the MERGE_ZOMBIE_LIST code to be next to the LOAD and SAVE code, as any
change to one of these functions should probably be done to all of them.
Prior to this commit, the scaled= attribute was undocumented and had what I
assume was a bug - when enabled the image was scaled up to the width and height
of the background - not to the same ratio as the background, but to the full
size. So if you had a 1000 pixel wide background in an 800 pixel wide window,
then scaled=yes meant each journey-marker was an 800 pixel-wide blob.
However, if anyone was using it with background-size images as overlays then
this commit will break that usage - that use case is still supported by having
multiple [background_layer]s.
Closes#5223, which was a question about whether to fix or simply remove the
scaled attribute. Given that [background_layer]scale= and [image]scaled= have
different meanings (the background_layer one should and does cause it to be
full-window), I've kept the 'd' on the end of 'scaled' too.
Use a loop instead of recursion. This cleanup is prompted by #5041 (drawing
map labels in IntroWML), which will add more items to be drawn in this loop.
The old implementation would not have triggered tail-recursion optimisations,
as the recursion site wasn't the final code in the function.
Correct documentation in the .hpp file about when the delay takes effect (this
isn't a behavior change, just a documentation correction).
Review the schema, and remove attributes that aren't supported by the code.
Many of these attributes are supported for `background_layer` but not `image`.
This is about 10 lines of translatable text, not sure if it's okay to backport to 1.14.
The storyline itself is going to have large changes by 1.18 (maybe 1.16), so I'm not sure if
this will ever be in a stable release.
If a player loads a start-of-S02 save without the who_slew_mordak variable then it will still
work, showing the "I saw the killing blow with my own eyes" version.
Explanation for what's going on (put in the commit message because this bit is non-canon):
There are some "grey mages" in the Grey Woods, who appear in the Liberty
campaign. Most of the details of these were removed from 1.15, but in 1.14's
Liberty S06 they don't tolerate necromancers. SotA mentions an ancient elvish
civil war in these woods, with the ghosts still haunting the battlefield. I'm
assuming a general truce between elves and grey mages, on the understanding
that the grey mages are doing exorcisms of ghosts from the ancient war.
The image added here is a grass background to draw units on via Image Path
Functions. For the documentation, a square image looks better than a hexagon
that has black borders.
Without this, log messages with --log-precise enabled tend to look just
a bit *off*:
20201019 23:09:21.786752info general: attempting to generate locale by name 'en_US.UTF-8'
^
This had the confusing side-effect of making some code in wesnoth.cpp
believe it was safe to prompt the user to press Enter when NOT using
--wconsole on my system, because the flag ended up with a true value by
default.
This is why you don't leave integral-type variables uninitialized, ever.
Instead of using the allied orb during their turn, the unmoved, moved and
partial orbs are shown. The player's own units will be shown with the moved orb
during the ally's turn, which matches the previous behavior. This is intended for
co-operative MP campaigns, where it will make it easier for players to discuss
possible moves. The UX is also visible in SP scenarios with allied sides, HttT's
first scenario is an easy place to see what it does.
If another status is added to the orb_status enum, this code is likely to
support it with no changes needed for the parts in this commit. For example,
issue #5155's proposed orb_status::disengaged has been tested with this.
Updated the documentation about orb colors. In these docs I've moved all of
the images to a single line above the bullet-pointed list, as otherwise the
layout looked bad once a line wrapped - the first line appeared
horizontally-aligned with the center of the image, the second started under the
image.
Added documentation about the delay in multiplayer games, as the purpose of this
orb-coloring feature is to assist discussion in multiplayer games.