#308 added a large batch of NewRecruit values to ModifierKind, ConditionKind, ConditionGroupKind, ConstraintKind and SelectionEntryKind. The roster engine's mapping switches were written before that and do not handle them.
src/WarHub.ArmouryModel.Concrete.Extensions/Symbols/ConditionGroupingBaseSymbol.cs:34src/WarHub.ArmouryModel.Concrete.Extensions/Symbols/ModifierEffectSymbol.cs:17
Both end in _ => fallbacks that emit ERR_UnknownEnumerationValue, so there is no build break and no silent wrong answer — but NewRecruit datafiles using any of these values will fail to evaluate rather than being applied.
Unhandled values include the numeric operations (multiply, divide, modulo, power, exponent, triangular, ceil, floor, the cumulative-* family), the string operations (prepend, replace) and hide, plus the extended ConditionGroupKind set (count, min, max, greaterOrEqual, …).
This is feature work — each needs its evaluation semantics defined, not just a switch arm.
Related: ProtocolConverter in RosterEngine.Spec had the same class of problem and was fixed in #322 by deriving its wire-name maps from the [XmlEnum] attributes instead of hand-maintaining switches, so it now stays complete as the model grows. The same approach may not suit these two, since they map to behaviour rather than to names.
#308 added a large batch of NewRecruit values to
ModifierKind,ConditionKind,ConditionGroupKind,ConstraintKindandSelectionEntryKind. The roster engine's mapping switches were written before that and do not handle them.src/WarHub.ArmouryModel.Concrete.Extensions/Symbols/ConditionGroupingBaseSymbol.cs:34src/WarHub.ArmouryModel.Concrete.Extensions/Symbols/ModifierEffectSymbol.cs:17Both end in
_ =>fallbacks that emitERR_UnknownEnumerationValue, so there is no build break and no silent wrong answer — but NewRecruit datafiles using any of these values will fail to evaluate rather than being applied.Unhandled values include the numeric operations (
multiply,divide,modulo,power,exponent,triangular,ceil,floor, thecumulative-*family), the string operations (prepend,replace) andhide, plus the extendedConditionGroupKindset (count,min,max,greaterOrEqual, …).This is feature work — each needs its evaluation semantics defined, not just a switch arm.
Related:
ProtocolConverterinRosterEngine.Spechad the same class of problem and was fixed in #322 by deriving its wire-name maps from the[XmlEnum]attributes instead of hand-maintaining switches, so it now stays complete as the model grows. The same approach may not suit these two, since they map to behaviour rather than to names.