Just a guess, but I think your first match might be always failing? $MONTH$ never equals “Jan-Feb”, so it always returns $CurrentMonth$, which might have a value of 1?
You’re also using a bizarre mix of old-style and Beanshell expressions: those $-signs are superfluous, and may actually be causing the expression to fail. (I’m assuming that expression is enclosed in curly braces {}; if not, then your problem is trying to use the ternary operator in an old-style expression, where it’s not supported–unless that’s actually a Calculated Property, not a Dynamic Property, in which case the curly braces are implied and shouldn’t be included.)
Why are you trying to do the year, month, and day as separate properties? If you just do all 3 in one property, you shouldn’t have to worry about leading zeros…
The alternative is to use Java string functions to pad the single character out to 2 when you assemble the final string, instead.
(So, to actually answer your question, “how do you get an expression to recognize that you intend for a number to be a string and not an integer”, the answer is: you can’t. VASSAL assumes anything that can be interpreted as an integer is an integer.)
This is one of the problems I really hate. I’ve tried to solve it in several ways, but none worked.
If Vassal decides that the string “'01” is the integer 1 there is nothing you can do to force Vassal to treat “01” as a string.
IMHO this is a bug and I hope that in the near future this will corrected.
Cheers!
thank you for your suggestion, that I will try. The most annoying thing is that I cannot always use the Send to Location trait, since every hex starting with a “0” is not considered a valid location name. For instance, hex 1032 is accepted, but hex 0804 is not. At present I use a combination of two Moved Fixed Distance traits to simulate the Send to Location trait if hex name has a value lesser than 1000.
Before I forget, where I can find a documentation about the new features in version 3.6.x ?