Use of Boolean expressions in some traits (e.g. Restrict Command) causes spurious errors when pieces are touch / dragged from (?) a palette. For example: - Bad Data in Module: Piece: Lion Trait: Restrict Commands - Manpower Marker; permanently set to 1 once captured - Ctrl+M Source: Expression={SumStack("manpower")>0 || Captured_Active || wasCaptured}, Error=internal Error: Unimplemented binary String operator Error: Expression evaluation error. See the errorlog for more details.
Outside of the palette, similar issues can be resolved by declaring a default boolean value (true or false) as the initial value of the Global Property.
I feel that it would it be sensible for the palette to refer to a module’s global property list for the value of any Properties that it evaluates. This is not a request to prevent evaluations in a palette, they can be useful.
I know this doesn’t help for an existing module that requires an extensive rewrite, but I avoid boolean expressions entirely unless I’m forced to by Vassal, such as the “disable toolbar button” property. Vassal gets angry anytime something is undefined EXCEPT when it expects a numerical value, then it treats undefined as “0”. Thus using “0” for false and “1” for true with expressions like {$Property1$+$Property2$>0?1:0} replace boolean expressions entirely but are far less likely to result in spurious error messages. Those results also have the added benefit of being easily manipulated by all sorts of other formulas and calculations.
It’s a fair approach to avoid booleans but they do help compress expressions considerably. Provided they are “declared” to make sure that the boolean GP always has a boolean value, then they work fine, except for the palette situation.