* 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 was ONLY used in one place, to calculate rotate_right_around_center, and was likely not a very efficient way of calculating that anyway. I've included a different implementation of rotate_right_around_center that uses cubic coordinates.
This code sets orb color to can-still-make-an-action if unit has no moves left,
and has a visible enemy within max and min range of a weapon. This also affects
if the unit is selectable with 'N' (units that can move or attack).
Currently, it doesn't affect the mainline much, as no unit has a weapon
max/min_range different from 1, most notice-able, it marks units with no attack
as incapable of action, after having no moves left.
The purpose of this is part of getting real-ranged attacks into the mainline.
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.
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.
