Rewrite of StatString and Addition of New percentage based rules. #117
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New Features:
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).globalRule: true
(defaults to false). Global Rules are only meaningful onstatString
rules 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.physTraining
rule, corresponding to the oldpsiTraining
rule.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.oxceStatStringDivider
option. It defaults to "\" and does not appear in the menu.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 ofunique_ptr
s. 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. :)