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
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.
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.
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`.
The existing tag has a confusing name - it returns the chance to be hit rather
than the defense, for example 30 would be returned for a unit on 70% terrain.
The new tag returns a higher-is-better value.
The change in theme.cpp is just to make the "title_literal" key be consistently applied as documented. Since the key isn't used in mainline, it should have no effect on actual uses.
This warns about tag definitions that can never match any tag (or for which one element of the comma-separated list can never match) because there is an earlier-defined tag definition that would match it instead.
The new check also found some errors in the schema, which have been fixed.
The code comments talk about both Dunefolk and Quenoth Elves - of these two, only the
Dunefolk's data is changed in this commit. All Quenoth unit are race=elf at the moment,
I intend to add [race]id=quenoth in a separate PR.
Draft documentation for the Wiki:
* '''help_taxonomy''': {{DevFeature1.15|?}} in the help browser, show this
race as a group of units from another race; the value of this attribute should
be the other race's '''id''' attribute. This only affects the help browser, for
all other purposes (such as WML filters) the two races are completely separate.
How this is visualised in the help browser is a GUI design decision, this attribute
merely tells the engine that the relationship exists.
These changes to the data/gui subdirectories make it so that above a certain
screen pixel dimensions (currently 1200x900), text font sizes will be scaled
with the pixel pitch of the SDL video device. In addition, several dialogues
(such as the unit recall window, for example) are allowed to take on larger
pixel dimensions to accommodate the larger (in pixel size) fonts.
* add resistance anim to shema validation
If a day, a resistance abilities applied to adjacent unit is added in the core, with a proper animation, it can be validated.
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
All weapon specials can now be used in [abilities] to effect all weapons of the unit that pass the filter given in [filter_student][filter_weapon].
Explanation: filter_student filters on the unit that is under the effect of the ability (which is usually the unit itself, but not always if [affect_adjacent] is used). [filter_student][filter_weapon] filters on the active weapon of that unit (the student) in a specific combat.
[filter_weapon] is now supported in all filter_opponent, filter_student, filter_attacker, filter_defender
Note that constructs like [filter_student][or][filter_weapon] are not suported, [filter_weapon] must be a direct subtag of the four just mentioned tags.
[filter_second_weapon] is no longer used for abilities that come from weapon specials.
implements #4629 , #4475 , #4389
Co-authored-by: gfgtdf <daniel.gfgtdf@gmail.com>
This gives GUI2 textboxes (and password boxes since they are a subclass)
a simple hover effect by extending the canvas definitions for the widget
accordingly.
There's also a "translate" attribute which is missing in the schema,
this commit deliberately omits it as it was for WesCamp.
The commit comment in e6d1595f8 is wrong - the validator does complain
about the error fixed in that commit, I'd missed the --use-schema option.
Explicitly use t_str() to avoid an ambiguous construction from
7bee8ee1574e16ec27f8904e6808bc1515fe4a86, which made GCC9 error out because it
could alternatively use t_string::t_string(const string &).
Resolve the merge conflict from 26d1ca7a7d1216e8f19f2848f6556c456e9d1f3f
Adding this is issue 2 of #4177, changing the behavior when [find_path]
is given a SLF which matches multiple hexes.
The map and tests here should be easy enough for manually editing them. It
duplicates some of the functionality of the existing characterize_pathfinding
tests, however those tests need their expected values to be calculated and
can't be changed by hand.
'''nearest_by''': {DevFeature1.15|2} possible values "movement_cost"
(default), "steps", "hexes". If the [destination] SLF matches multiple hexes,
the one that would need the least movement points to reach may not be the one
that's closest as measured by '''hexes''', or closest as measured by steps,
from the starting point.
Behavior in 1.14 depended on which hex was checked first.
