Each [teleport] tag should have exactly one each of [source],
[target] and [filter]. Missing any of those is caught immediately
above the new conditional block, so this makes having two or more
of any of them be treated the same.
The log should maybe be made more visible, but it's a case that
can already be detected by schema validation, so validate it
there instead.
The code in teleport.cpp uses assert() in the cases that the
newly-added code in this commit catches. That's bug 8175, and
it's probably still reachable for units with teleport abilities,
so this doesn't close that bug.
Adds support for using these in the weapons and ability filters:
* "-1", which was previously treated as an parse error (no number before the separator).
* "-3--1"
* "-infinity" as the lower number in the range, provided a different upper number is given.
This treats "-infinity" (with no other number), "-infinity--infinity",
"infinity" (with no other number) and "infinity-infinity" as errors. It seems
unlikely that someone would intend to use a filter that can't match any
reasonable number.
The range "-infinity-infinity" will be parsed successfully. I don't see a use
case for that, but nor do I see a reason to add extra C++ to reject it.
However, it's not added to the schema, as I think it's good for the schema to
give a warning when someone creates a filter which will accept every value
(including accepting the default, so "-infinity-infinity" accepts the unset
value too).
Includes new unit tests for the C++ and the Lua stringx.parse_range functions.
The next commit adds more WML tests, but is kept separate to credit the author.
This started as a change to move common filter functions from unit.cpp to
somewhere that they could be reused for other config-based filters. In the
process a missing feature was found and added, the move is still included in a
single Git commit because the move was required in order to make these
functions accessible to the Boost unit tests.
Two CodeBlocks project files additionally get src/utils/any.hpp added,
which was in one of them but missing from the other two. I noticed because
these are alphabetically at the start of the src/utils file list.
Thanks to @CelticMinstrel for the review comments and Xcode project updates.
For any given event name, events execute in order of decreasing priority.
Priority is a real number, and may be assigned via the `priority` attribute for
the WML [event] tag, or through the Lua APIs:
- wesnoth.game_events.add({priority = number})
- wesnoth.game_events.add_repeating(name, action, [priority])
Note that delayed variable substitution is not currently supported in the WML attribute.
This uses tabs instead of spaces, because although that's not our coding
standard, it is only a few lines of changes.
The alternative of running wmlindent on these files changes 4700 lines.
These keys are supported in game_config.cfg, but currently they're not used in
that file, instead falling back to the defaults in the C++.
The name show_partly_orb is inconsistent - in other places, including the WML
that's stored in the user's preferences file, it's called show_partial_orb.
These are leftovers from the original implementation of the disengage orb,
when it was a new color for the single-color orb. During the review process it
became the two-color design, but these parts were left in.
The value of orb_status_helper::get_orb_color(orb_status::disengaged) is used
(both before and after this commit) by the minimap; this commit changes
get_orb_color to return the partial_color() directly. The result will be the
same as before, because disengage_color() returned the same as partial_color().
Prior to this commit that was done by giving both orbs the same value in
game_config.cfg. If the advanced preference to change orbs colors was used, the
value chosen for the partial orb was passed to set_disengage_color() too.
Using colors to make relevant information stand out at a quick glance.
The six attack type icons are recolored using the six equidistant hues cyan, green, yellow, red, magenta and blue, with the same saturation and lightness as the old icons. The images are optimized with woptipng.
Resistances and movement costs are colored using a gradient from red to green, like the defense values.
The resistance table in the help browser now also shows the attack type icons.
Previously, the resistance table was always ordered alphabetically by their original English names (not their translation, unlike the terrain modifiers). Now, the order is set to blade - pierce - impact - fire - cold - arcane.
These changes are made in all relevant areas, including the help browser, tooltips, the sidebar and dialogs.
Missing icons are handled by replacing them with a blank image scaled to the same size.
* Add new [screen_fade] WML action
It takes (for now) the arguments:
* red, green, blue = values between 0 and 255
* alpha = value between 0 and 255
* duration = time in ms over which to fade
The game display is faded to the given colour over the duration.
It will be left with an overlay of that colour and alpha until
a screen_fade to 0 alpha is performed.
It is not used, and appears to have been unused for a long time.
It was related to mouseover hex brightening, but the brightening
amount is hardcoded. There were associated hex_semi_brightening,
mouseover_image and selected_image keys, but that info is also
hardcoded, and those keys appear to have been removed already.
This returns a label handle which allows you to remove, reposition, or replace the label later.
In addition to all the features of wesnoth.print, you can now specify where the label appears onscreen, as well as a fadeout time separate from the duration.
You can also anchor the text to an edge or corner instead of centering in on the screen,
specify the maximum width it can occupy as an absolute width or a percentage,
and specify a background colour and transparency.
It includes a demo scenario that demonstrates many of the capabilities of the API.
To play the demo scenario, run with -toverlay_text_demo or select it from the in-game test list.
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.
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
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`.
