This attribute, when set to a valid value of lawful|neutral|chaotic|liminal, will assign to the weapon a different alignment than the unit alignment used by default. This alignment is then used when attacking with this weapon.
The attribute is not accessible from lua so far since the fallback to unit alignment does not work.
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.
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)
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.
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>
- 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.
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.
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.
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.
* add resistance anim to shema validation
If a day, a resistance abilities applied to adjacent unit is added in the core, with a proper animation, it can be validated.
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>
