While not precisely a ‘bug’, while working on a module using the latest version of VASSAL (3.2.12),
I recently ran across some behavior that would benefit from better documentation.
Specifically, when used in a Global Key Command on a piece, all BeanShell expressions
-only- get evaluated on the target piece; the ‘$xxx$’ substitution, to get a ‘local’ property,
-does not occur- inside a BeanShell expression, but only for normal property match expressions.
Attached, see three images, snips of settings from the editor;
The function called by the GKC, simply loaded the value of ‘PNum’, to a global variable.
(there were 5 of these ‘Player’ chits, in 5 different colors - sample prototype provided)
When called from a piece with color ‘yellow’,
with settings as shown, it did the correct substitution, and the global var was then used
as the follow expression in a layer, creating an image in the indicated color.
If the property match expression was ’ { Chit== “Player” && color==$color$ }’,
using a BeanShell expression (as shown in additional snip, below)
(or even, with "s added around ‘$color$’ ), it stored an incorrect value to the global var
(it appears to have matched ALL 5 of the chits in question, and the global ended up with
the value from the last one it saw; the specific value returned varied, from one run of program to another)
IMHO (as a programmer of 15+ years), as long as one knows to use the old-style expression in a GKC when doing substitutions,
rather than using a BeanShell expression, it’s not much of an issue.
Also just FYI, there’s a few operators in the standard BeanShell that you didn’t document, that could be useful for those
with more programming background - it comes with left & right-shift operators ( << and >> , respectively ).