Unit description is not yet implemented. Once it is, I expect menu item is changed back to unit description, while the opened dialog has link to navigate to unit type description.
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
1. When addon is selected using Add-ons > Select active Add-on, the Unit menu will get activated so that the unit type editor can be used
2. Simplify initialize_addon_if_empty, returns success value as bool
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>
