* Rename the vector operations to hex_vector (to emphasize that they are NOT standard vector ops) and document them as official API
* Add new get_hexes_at_radius, which returns an unfilled ring (as opposed to get_hexes_in_radius which returns a filled circle)
* Expose the new cubic coordinate conversions
It should work even when the macro appears in the same event as the
attack; this tests that.
The new one uses the COMMON_KEEP macro, but I've left the existing
one unchanged, except for the renaming.
when two special weapons use multiply and divide with the same id, both operations are used, isn't that so why should it be different with 'add' and 'sub' where it's the larger value that is used (if asub=value_sub and add=value_add are used and value_sub>value_add then value_sub is used). This logic is counter-intuitive. that multiplication/division is applied to (base_value +- add/sub) is understandable but not this discrimination. For me add and sub should still be usable; even if it means changing the rules, but I think we will gain clarity in the end.
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.
1. race/alignment/attack damage type/attack range show corresponding icons
2. attack damage type/range now use comboboxes for custom dmg types/ranges
3. quit confirmation added to cancel button so that user doesn't accidentally lose their data
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
I changed some of the lines in NR The Pursuit to fit better with the different characters. Tallin, Abhai, Krash, etc.
I did not do it for every dialogue.
Addresses issues #8319 and #8772
More PR review feedback addressed by Wedge.
---------
Co-authored-by: Wedge009 <wedge009@wedge009.net>
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)
- give side 1 starting villages near the orc base
- move Kapou'e to his keep at start
Co-authored-by: Tahsin Jahin Khalid <5283677+knyghtmare@users.noreply.github.com>
* SOTBE-S3: make allied AI smarter
- they wont attack from poor defense anymore
- will only attack from hills where they have better defense
* SOTBE-S3: fix bad code in side AI
---------
Co-authored-by: Tahsin Jahin Khalid <5283677+knyghtmare@users.noreply.github.com>
if filtering type of damage in [damage_type] for both self and opponent when apply_to=both, it will create a recursion issue.
Idem for apply_to=attacker/defender when applied to opponent of owner of special.
* Death Squire optional advancement and damage nerf
The existing {ENABLE_DEATH_KNIGHT} macro allows Revenants to advance to Death Knights. The newly core-ed Death Squire also advances to Death Knight, but has no {ENABLE_DEATH_SQUIRE} macro.
I suggest adding a new {ENABLE_DEATH_SQUIRE} macro, while keeping the old {ENABLE_DEATH_KNIGHT} for backwards compatibility.
I also propose reducing the Death Squire's attack from 8x4 to 9x3, to make the Revenant a more competitive advancement.
Who's the current maintainer of SotA? Should {ENABLE_DEATH_SQUIRE} be used there, or should we continue using {ENABLE_DEATH_KNIGHT}?
Hejnewar, if you approve, what cost should the Death Squire be after this change?
* Reduce Death Squire damage from 8x4 to 9x3
* Update Skele_Death_Squire.cfg
