With GCC 9, enabling LTO no longer causes the boost unit tests to segfault and also doesn't increase the build time to the point that a full rebuild times out.
Maybe the "team_rgb_range" should be renamed as "named_color_range", because
it's used for everything defined by the WML `[color_range]` tag. In addition to
the ones normally used for teams (`red`, `lightblue`, etc) it has the minimap
colors for `reef`, `cave`, etc.
Separating the team colors from the terrain colors probably shouldn't be done.
Looking from the opposite perspective, using the terrain colors as team colors
has been discussed on the forums and found to be a useful feature:
* https://r.wesnoth.org/p627592
* https://r.wesnoth.org/p627588
There is no reason to do so since units get already
healed when advancing to the next scenario. Not
healing the unit gives more flexibility to wml authors
who might want the player to be able to recall injured
units by modifying the hp of a recall list unit or by using
`[put_to_recall_list] heal=no`
Furthermore this also doesn't match what is shown in the recall dialog.
Fixes#4888
Now formulas like "add=(attacker.level - defender.level)"
are possible in weapon specials that allow the author to compute
the abilities value based on the opponent. The main reason why i
choose for attacker/defender instead of self/opponent was thats
is easier to implement. (but using the self/student variable is
also possible to get a 'opponent' variable shoudl that be needed)
Also it is less ambiguous than 'self/opponent' in the case of
weapon specials that come from leadership-like abilities.
* 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.
This can be different from 'other' in case of a
an ability that effects the enemy, where 'other'
should be the unit that receives the effect
(here: the enemy), studend is the unit that
matches the [affect_adjacent], and the unnamed
unit is the unit that has the ability.
I think it'd be nice to have even more variables
available so that for example the effect could
depend on the opponent even when it doesn't
effect the opponent.
removes a call to get_ability_bool, in case that get_ability_bool
would return false, it would not be faster than get_abilities, in
case that it returns true it is useless.
removes a call to get_ability_bool, in case that get_ability_bool
would return false, it would ot be faster than get_abilities, in
case that it returns true it is useless.
