Don't animate unit advancements during a prestart event.
It woudl be better it u:advance() would automaticialyl not waste time animating advancements that can't be seen (during prestart events) but for this scenario this is already an improvement
(cherry picked from commit e549b03412)
The event has to use side 3 because side 2 is idle. Also remove the dollar sign because IF_VAR doesn't work with it.
(cherry picked from commit ae5b2f0da6)
Fix a typo in the add_sub_separated test, because it was testing
exactly the same code as add_sub_cumulative.
Add two new tests and clarify documentation, because in these tests
the order of the abilities determines whether the add or sub value is
used, it isn't that sub always overrides add.
(cherry picked from commit 547de5fd93)
The tag_name check is deficient for two reasons:
1.when apply_to=both is used, in the case of [damage_type] [filter_opponent][filter_weapon]type= will check the modified type for application to the owner and the original type for application to the opponent, hence a risk of infinite recursion, especially if [filter_self][filter_weapon]type= is used in the same weapon.
2. in the case of apply_to=attacker/defender, the check for [filter_attacker/defender] must take into account both the value of the variable is_attacker but also the application AFFECT_SELF/OTHER, otherwise in the case apply_to=defender with [filter_defender][filter_weapon]type=, and[filter_attacker][filter_weapon]type= otherwise we end up in the same configuration as for apply_to=both
Finally tag_name is renamed check_if_recursion to mean that this variable is used to ensure that a recursion cannot be set up even if 743b146efc prevents it from causing a crash but with an error log
this is a bachport of https://github.com/wesnoth/wesnoth/commits?author=stevecotton4afdc92f13 comit because one change of behavior is to prevent crashes of game
This adds a recursion counter which runs on a per-weapon basis; if the
recursion limit is reached then the last level of recursion is assumed
to have returned false. A warning is printed (with error severity).
At the user-visible layer, that gives the following logic:
* Abilities that depend on another ability being active will be
inactive.
* Pairs of abilities, where X depends on Y being inactive and Y
depends on X being inactive, will end up with them both inactive.
The limit is defined by ATTACK_RECURSION_LIMIT in attack_type.cpp.
The minimum for passing all the unit tests is 2, but I've left some
headroom by setting it to 4.
With the recursion limit set to 1, the following tests fail, which
seems reasonable because they're checking that the special is on
a particular type of weapon.
* event_test_filter_attack_specials
* event_test_filter_attack_opponent_weapon_condition
* event_test_filter_attack_student_weapon_condition
Output from the four_cycle_recursion_branching test:
```
error unit: Recursion limit reached for weapon 'melee_attack' while checking filter 'special_type_active = parry'
error unit: Recursion limit reached for weapon 'melee_attack' while checking filter 'special_type_active = poison'
error unit: Recursion limit reached for weapon 'melee_attack' while checking filter 'special_type_active = damage'
```
There's deduplication to prevent the logfiles getting spammed during
AI turns. As implemented, the two tests mentioned below print 3
messages each; these tests are added in separate commits because the
tests are shared between PRs while we discuss the right mechanism for
guarding against recursion.
With no rate limit:
* four_cycle_recursion_branching prints 1280 logs
* event_test_filter_attack_student_weapon_condition prints 320
With a rate limit via a flag that's reset in recursion_guard's destructor:
* four_cycle_recursion_branching prints 80 logs
* event_test_filter_attack_student_weapon_condition prints 160
Resetting the flag in specials_context_t's destructor gets better numbers,
but splits the logic across .cpp files. I think the trade-off isn't worth it:
* four_cycle_recursion_branching prints 40 logs
* event_test_filter_attack_student_weapon_condition prints 132
Co-authored-by: newfrenchy83
1. remove obviously English and English sounding female names from Dunefolk female names list
2. remove 'bakri' from male name list (means 'goat', could be offensive)
3. remove one potentially offensive name from saurian name list
4. remove 'Dalal' from dunefolk female names (can be used as slang)
The random map generator can generate starting locations so close that
ERASE_CASTLE removed not just the intended castle, but also the keep
of the nearby leader. To avoid that, create the castles after deciding
which leaders to remove.
The ERASE_CASTLE macro is obsolete; even for logic that erases
castles, using location_id makes the code simple enough that a macro
isn't useful. However, as this change is being applied to 1.18, I'm
only adding a comment about it.
This allows permanently hiding the obnoxious help text tooltip that
constantly dances between the top and bottom of the screen depending
on what you're doing in the editor.
Icons provided by babaissarkar.
In EI S11, the player encounters an orcish warlord named Dra-Nak. If not killed in S11, he continues pursuing the player in S12, but the current S12 gives him different traits and a different portrait. This PR fixes the issue.
EI's S17b has a gold refund mechanic, allowing enemies to build up large gold reserves in certain situations.
When gold gets high, enemies are supposed to start recruiting higher-level units so they can spend it faster. The former implementation had some inconsistent issues; this should restore the intended behavior.
In EI's S99, you gain gold from defeating and capturing hostile drakes. The drakes are physically moved to prison cells in the middle of the map.
Previously, the player could continue capturing drakes even if the prison cells were captured by enemies. This made it a strong strategy to abandon the center and turtle up in a corner of the map. Additionally, the prison cells stayed locked with prisoners inside.
This PR fixes this issue. This also adds 2 new strings; I'm planning to backport to 1.18.2, as this is arguably a bugfix.
EI's S11 and S99 have prison cells, one of which has an unintended backdoor entrance via an unwalkable deep water river. Flying units are involved in these scenarios, and can possibly fly into the cells through this unintended backdoor.
This PR changes the map hexes from unwalkable to impassable.
This disallows matching "0-11-2" and "1," for example. It also avoids an exponential backtracking issue which could make this regex very slow.
(cherry picked from commit 28a8959854)
The lava is supposed to stay away from the Sceptre itself.
However, 60d114b changed from using sceptre_x,sceptre_y to using
a location_id, and missed updating these macros.
Changes:
* CHECK_STRIKES macro now takes a comma-delimited list of strike counts for when units have a different number of strikes for different weapons, and updates the existing usage in the attacks tests
* Fixed a typo in the attacks_zero test
* Adds tests for berserk as a weapon special ability.
Berserk's handling differs from attacks as a weapon special ability:
* A value less than 1 is treated as effectively infinite rounds of combat (undocumented)
* The cumulative attribute is handled differently - in some cases it sums the values instead of using the highest single value whereas for attacks it always uses the highest single value
Also now exclude data/tests/ from scons pot-update since it was hitting the argument limit for number of arguments to a script.
Owaec has a crown but little other indicator that he's a leader, and this scenario requires him to be used to recruit. Make it more obvious to the player.
