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.
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
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.
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.
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>
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.
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>
When multiple negative heal abilities are present, the game now
chooses the ability with the lowest value. The leadership ability
now also uses the same get_composite_value function that is also
used by most other abilities
This adds running the WML schema validation in travis. It also updates the schema itself and fixes a few WML errors so that core and all campaigns under all difficulties pass the schema validation.
Currently this is disabled by default
Use --validate command-line argument to enable
The following new features were added in the schema format:
* Union, intersection, and list types
* Keys can specify a union of known types on-the-fly
* Key and tag names can include wildcards (* and ?, glob-style)
* Tags support any_key=yes, which means unrecognized subtags will be ignored
* Tags and keys support deprecated=yes (unimplemented)
* Specify max=infinite instead of max=-1
