MeridianOXC
Rewrite of StatString and Addition of New percentage based rules.
New Features:
- New StatString rules, following the format:
percentSTAT: [MIN, MAX]. The numbers are interpreted as floats but are 0-100 based rather than 0-1 based. Ranges are compared using [MIN, MAX). - Ability to mark a StatString rule as a "GlobalRule." via the syntax:
globalRule: true(defaults to false). Global Rules are only meaningful onstatStringrules on the top scope, as opposed to those onsoldiers. If true, the associated rules are processed together with any type specific rules, happening first in order (global rules are processed first, then soldier rules). Otherwise, the current logic is respected, and no global rule is processed if there are any soldier rules. - New
physTrainingrule, corresponding to the oldpsiTrainingrule. - Ability to negate a training rule by giving it the value of
false. (condition is passed if the soldier is not in training) Any value that does not translate to false (includingtrue, obviously) preserves the old behavior, and the rule will trigger true if the soldier is in training. - Ability to set a custom divider via the
oxceStatStringDivideroption. It defaults to "\" and does not appear in the menu. - All old functionality and logic is preserved.
So I ended up more or less rewriting most of the StatString code in this feature. I've tested it extensively and haven't found any bugs, but I went more deeply than intended (though not as deep as I might have wanted, lots of code I wanted to improve). The new StatStringCondition classes use inheritance and are stored in a vector of unique_ptrs. As such, copy constructors/assignment have been disabled as appropriate. I didn't bother writing any sort of clone methods, as I couldn't see the need for them, but they could be added later if necessary. None of this makes any difference to existing code but is something to keep in mind if things are refactored.
There is also a circular dependency on the Soldier class, which is less than ideal. But I couldn't see how to resolve that without doing a more major rewrite or bloating up the code and making it less flexible. Still, all in all, I think it's pretty clean, but then again, I would think that I wrote it. :)
