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 adds support for having up to 28 distinct sub-achievements within a single achievement. This limit exists since wesnoth's layout isn't smart enough to tell a horizontal listbox to actually use its scrollbar instead of forcing a horizontal scrollbar on the whole window.
Additionally this adds the [set_sub_achievement] and [has_sub_achievement] WML tags and their respective lua functions. [has_sub_achievement] is unsafe for use in MP, for the same reasons that [has_achievement] is.
Support (fe)male_name key in unit.
Support FEMALE_NAME in macros for named units with random gender.
Add female variants to generic unit names in DiD, TSG and UtBS.
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.
Hopefully making the whole faction more interesting and enjoyable to play.
Co-authored-by: Steve Cotton <steve@octalot.co.uk>
Co-authored-by: nemaara <nemaara@users.noreply.github.com>
Instead of being either complete or incomplete, achievements can now specify a value at which they will be considered complete. For such achievements that are not yet complete, a progress bar is added to the achievements dialog showing how close to completion the achievement is.
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.
* Add basic achievements functionality.
This reads the mainline achievements.cfg and then all the achievements of each installed add-on.
This is intentionally handled separately from other WML loading so that:
a) All achievements and their status are able to be displayed on the main menu right after Wesnoth starts and regardless of which add-ons are active.
b) Add-ons can add additional achievements to other content, whether UMC or mainline. For example, a modification that adds more achievements for mainline campaigns.
Marking something as achieved is handled by the new [set_achieved] tag and whether an achievement has been completed can be checked via [has_achievement].
There is no attempt to prevent people from manually editing which achievements they've accomplished.
NOTE: These are *not* in any way related to Steam achievements!
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.
