dc00df935b
Add threshold relationships <= and >= so that the change to make < and > perform their expected comparison can be resolved. "Point release shouldn't force players to update their config files" does not carry sufficient weight given that they already had to do that to turn on status highlighting when going from 3.6.0 to 3.6.1. The 3.6.2 release notes can warn them about the need to update their status highlight options if they're currently using '<' and/or '>'. Entering new hilite rules via the 'O' command accepted '=' prefix for numbers, but rules from config files did not. Now they do. The '=' prefix is optional in both situations. With 'O', percent rules and absolute rules had separate menu entries so picking one was already choosing the rule type, but entering a numeric value without percent sign (for percent) or with one (for absolute) would change the type on the fly. If someone has already picked percentage they shouldn't be required to append '%' to the digits, so that is now optional. If explicitly included with the number after having picked absolute, the value is rejected. It is trivial to back up in those menus and choose the alternate type if someone changes his/her mind part way through. If a status field has both persistent (percent, absolute, always) and temporary highlights (up, down, changed), give the temporary one precedence when the value has changed. To do that with 3.6.1, the rules for temporary had to follow the ones for persistent highlights since whichever matched last was the one used. Now their order relative to each other doesn't matter. If a value increases and there is both an 'up' rule and a 'changed' rule, the more specific 'up' takes precedence, regardless of their relative order; likewise for decreases and 'down' vs 'changed'. There were a couple more tweaks needed to support negative values; I overlooked the 'O' menu handling before. >-1% and <101% now work for both the config file and interactive adding via 'O' methods of defining highlight rules, although new >=0% and <=100% will be clearer to anyone examining a rule set. 'enum relationship' was forcing LT_VALUE to be -1 but that fact was never utilized anywhere, and the code was using magic number -2 to mean "no relationship yet". This adds NO_LTEQGT to replace the latter and gives it value -1. EQ_VALUE is still 0 so effectively the default if a highlight hasn't been fully set up yet. LT_VALUE is now just another positive value along with GT_VALUE, LE_VALUE, &c. The Guidebook hasn't caught up with the code yet. The rule choosing code used when deciding how to highlight something only supports 'int' fields and relies on 'long' having the same bits. It needs to be extended to support 'long' properly. Fixing should be straightforward (except maybe for the initialization of min/max best fit handling) but this doesn't address that. Also, data type for encumbrance/carrying-capacity should be changed from unsigned to plain int so that no extra handling for just one field will be needed.
3.7 KiB
3.7 KiB