In the case of [leadership], the fact that the values of each ability can be added when cumulative=yes can justify the addition of limit values not to be exceeded, but this can also apply to heals and [regenerates] with the use of 'add' or 'multiply'.
As for [resistance], it already uses max_value, but if cumulative=yes, then all max_values can add up which could be problematic.
A rich text label widget that can show text marked up with help markup.
Also includes the GUI Test Window, accessible in the title screen after launching wesnoth using --clock option. It can be used as dialog template/example or as a place to test GUI2 code.
Currently for the vertical listbox only, since it does have some quirks. Removes the assert in the "show" policy checking if the callback is null. It won't be for the listbox, but doesn't really matter since it's not used.
* Redesigned the version dialog to serve as a general purpose About dialog.
* Credits button removed from title screen
* Moved community dialog contents to about dialog as new tab
Co-Authored-By: Pentarctagon
* Bugfixes to the tab_container widget
* Success indication mechanism on copy buttons
max_value is used to limit the increase in resistance with the "resistance" capability, but there was no equivalent for its reduction.
To be able to add min_value without redoing the "resistance" checking for the umpteenth time, I prefer to modify effect:: so that the checking of these two attributes is done at the same time as the other numerical attributes and keep the door open to a possible generalization of the proceed
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.
In the validation schema abilities-value in abilities.cfg contains not only the numerical attributes but also active_on and apply_to, while these two deniers are only used by [resistance], and the abilities used as weapons are validated by the schema validation of special weapons, and the abilities [leadership], [heals], [regenerate] and [illuminates] also use all numerical attributes.
super="units/unit_type/abilities/~generic~" isn't quite accurate since there are a lot of keys/tags in there that may not mean anything for dummy abilities. Probably doesn't hurt to expect they work like in mainline though.
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
Fix https://github.com/wesnoth/wesnoth/issues/7923 .when we want to detect an ability with value=0-20 and an ability with add=15 is present, this is detected because the system assigns a value of 0 when 'value' is not present, and so the system matches abilities that do not use 'value' or even no numerical value at all. it is therefore necessary to decide that the absence of an attribute is a non-correspondence to the criteria.
There are questions about how this filter should treat empty values, and the
use cases that we can think of can be implemented in other ways, for example,
if we want to look for big damage boosts, then we could filter for
`add=5-infinity` `[or]` `multiply=2-infinity`.
The simple answer seems to be to remove it from the API before we freeze for 1.18.
There's more discussion in issue 7944.
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
give abilities support of halo or overlay so that the unit benefits from a second halo or overlay when conditions are matched
One of the things that bothers me is the permanent character of the halos of the Mage of Light and other units with the "illuminates" ability, which forces them to program only a permanent illumination applied only to the possessor of the ability.
Adding the halo attribute to ability does not change anything about the behavior of the unit, but can be used in several cases:
1 allowing the use of ""illuminates" whose activity would be variable, in this case encoding the halo in [illuminates] ability and not in the unit_type allows to modulate the appearance of the halo under the same conditions
2. Applying illumination to adjacent units, I know it's pretty cheesy but a set developer might consider it easier if the hlo display follows the same logic.
3 The halo used to illustrate the possession in the unit of a special weapon used as leadership, the halo would be used to raise the possessor of the ability.
for overlay, same logic for illustrate possession of a special weapon used as leadership, or influence on student
with the "halo_image" attribute, it is now possible to give Sun Sylph units an illumination ability with an activity depending on the incarnate sun attack instead of giving the ability and the halo via obect and therefore allowing the player to have access to the description of the ability even when it is inactive.
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.
