In 1.14, the default was 50 frames, or around 1.7 seconds. In 1.15.4, commit
a9d9e48c72 changed the interpretation of that
number to milliseconds, but missed that this affected the [print] tag; this
left the default time that the text is shown as an unreadable 50ms.
All places in mainline that use [print] specify a duration, so the default
isn't used. Here I've plucked the new value from UtBS S09, where it was chosen
in f405b916a1.
The special value "unlimited" is now recognised as meaning to display the text
until it's removed by another [print] tag. The tutorial uses this special case
to display the text until the player does the requested move - originally it
displayed the text for 10000 frames (around 40 minutes), which still seemed
reasonable when it changed to 10000ms.
- The t_string type is now a schema built-in type and no longer attempts a regex match.
- You can also specify that non-t_string types may be optionally-translatable; this case supports a regex match on the string (but note that the translation mark is not part of the match).
- Error messages involving keys with very large values ( > 128 characters) will now truncate the value.
- To account for occasional cases where the schema is intentionally violated, the --validate command-line option now automatically defines the SCHEMA_VALIDATION preprocessor define.
A key validates as type t_string if one of the following is true:
- The key is not present
- The key has at least one segment with a translation mark
- The key is blank (an empty string)
Any type other than t_string is not allowed to be translatable by default, unless you specify allow_translatable=yes in the [type] tag.
An optionally-translatable string could also be defined as a union of t_string and some other type.
Refactor special notes for abilities, attack types, movetypes and weapon specials
An easier way of setting special notes in the most common use-cases. Text given
in the following attributes will be collected and added to the special notes
for units and unit types (some of these were added in the previous commit):
* [ability tag name]special_note=
* [language]special_note_damage_type_TYPE=
* [movetype][special_note]note=
* [attack][specials][special tag name]special_note=
It's no longer necessary to put these notes in each unit_type's .cfg file, and
the macros for doing so are now deprecated.
C++ changes
-----
Simplify both unit_type::special_notes and unit::unit_special_notes. Add
utils::stable_unique, similar to std::unique but accepts non-ordered input and
preserves the order in the output.
Remove unit_type::has_special_notes() - callers can instead call
special_notes() and then check if the returned vector is empty, which removes
the need for duplicating code in unit_type.
Trade-off: the new [language]special_note_damage_type_TYPE is likely deprecated in 1.19.
-----
Adding [language]special_note_damage_type_TYPE= uses the same existing design
as [language]type_TYPE=, however both are hacks that don't fit the general
style of WML. It could be better to define a new [damage_type] tag that
supercedes both and also provides a place for specifying the damage icon;
however that won't be done in time for the API freeze for 1.16.
Doing it in the way that this commit does it is a hack, but it's one where
replacing it with the better solution in 1.18 will affect very few UMCs (only
those that define additional damage types). Even in the UMCs that would be
affected, it would likely only be a few changes in a single central file.
Trade-off: NOTE_DEFENSE_CAP is not auto-added
-----
It might be better to auto-add NOTE_DEFENSE_CAP when movetype.cpp detects that
the type has capped values. However as NOTE_SPIRIT already requires
[movetype][special_note], it's simple to use the same mechanism. If we decide
to change it to being auto-added, the current commit greatly reduces the number
of places that would need to change again, as it's now in the [movetype]
instead of the many [unit_type]s using that movetype.
When processing [effect]apply_to=movement, if apply_to_vision is 'yes'
(which is the default) then the vision points will change by the same amount.
Previously, it sometimes affected vision and sometimes didn't; for most cases
where it makes a difference, I expect it to be a change from unanticipated
behavior to expected behavior.
Please refer to the new unit test added in this commit for more detailed docs;
that test is also a rough draft for the Wiki update needed when this merges.
The reason it sometimes affected vision was that the special value of -1 vision
points was interpreted as "use the value of the max movement points instead".
The special value of -1 is still supported and frequently used, and refactor that
is out of scope for this commit - it's easy to check when the code path changed
in this commit is used, however it's considerably more complex to find all
routes that create a unit with vision set to -1.
I'm expecting one add-on, Rebirth In Nature, to need a large update for this;
as well as a trivial change needed to the Add Creature Pack.
There are several mods that have their own handling for vision, recalculate the
values frequently, and are expected to continue working as before, as they'll
just overwrite any changes that the engine makes.
* Proper Flying Mod / Proper Vision Mod
* LotI
* Blessed Altar Mod
* Shards Era's `CALCULATE_WEAPONS_ONLY` macro
* Castle of Evil Spirit
Rebirth In Nature is an RPG-style campaign that expects the player's unit to
have vision separated from movement along with right-click menus that change
the character's movement, this will probably need `apply_to_vision=no` in
many places. OTOH, its `item_id=mobility` uses `apply_to=movement` followed by
`apply_to=vision` to implement in 1.14 what this change will make default
behavior in 1.16.
There are a few sharpshooter units which have vision better than their
movement. If given a buff which boosts their movement, this will give
them a buff to vision too; likely a change towards expected behavior.
* Archaic Era's Royal Ranger
* Ageless Era's Royal Ranger and Dwarvish Forest Sniper
* Eastern Europe at War's Yacht and Great Yacht
* Era of More Units's Lone Wolf
* Southernerns has several sharpshooters
* WWII Era has several sharpshooters
* War of Dominions has some guard towers with very low movement
Silver Age has abilities that modify vision based on time-of-day, but unlike
the Proper Flying Mod and LotI these are done by adding and removing objects
that add or subtract one vision point, these should be unaffected by this
change. Unrelated to that, it declares values for `[unit_type]vision=` even
when the value is the same as max moves - like the sharpshooters this means
that buffs to their movement wouldn't have buffed their vision but now do.
There are few units with vision less than movement. Generally these seem to be
missile weapons that are represented as units, and they probably won't meet any
apply_to=movement statements - even if a movement power-up is available, the
player would probably choose a different unit.
The Add Creature Pack has two creatures (the Cactose Elder and Carnivore Fatal
Plant) that have reduced vision, along with AMLAs that increase those units'
movement; these AMLAs will need to use `apply_to_vision=no`. These two
creatures are used in Castle of Evil Spirit, but they won't get enough
experience to get an AMLA there.
Fixes#3356.
Add 'ability_id_active' attribute to filter
Until now, only the type of ability could be filtered with activity, and id only for unit who have ability, same if she's inactive.
When a unit gives adjacent units abilities used like weapon specials, and is not already showing an animation from giving a resistance or leadership effect, a [teaching_anim] can be played instead.
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.
