Game Piece Activate CTRL-A

I’m not sure if this is a bug or not, but it can be very confusing for sure. So I figured I’d report it and let you all decide whether it’s a genuine bug or just a brain-dead user.

In the game piece palette, for a game piece Layer property, if you check “Level follows Property Value?”, the default ActKey (CTRL-A) is greyed out (and not editable), but still live. (See image below.)

Per chance, I am using CTRL-A otherwise in the module and it took me several hours this morning to discover what was triggering an inexplicable behavior for the game piece. It turned out that a CTRL-A key stroke was also kicking off an Activate for the piece and putting it into an unknown state (from my perspective), even though CTRL-A is greyed out (so I thought not enabled). I had to uncheck the “Level follows…” box, clear the CTRL-A from Activate, and re-check “Level follows…” and then my piece behaved as expected.


That is pretty silly! I vote bug. This is not the only configurer with this kind of behavior, though - apparently Send To Location obeys its ‘Advanced Options’ even if it is unchecked. In that case, the relevant fields are even hidden!


Afaik, advanced options are always followed, in any trait I know of. At least in Vassal 3.1.x.

The checkbox is just to show/hide display in trait editor. The default is hide, so if you check advanced options, enter some number, save, open the trait again, you see advanced options unchecked but the numbers are still there, and they will be followed. Again, this in any trait I can think of, not only send to location.

I’ve had exactly the same experience, and it took a while to get used to this since it seems counterintuitive. Now I constantly feel compelled to open those hidden panes to make sure there isn’t a value lurking in there that’s going to give me the wrong behavior. I would recommend that checkboxes not be used as open/close handles for hidden panes, since the user expectation would likely be that the checkbox means active/inactive. Or, what I really should say is, it’s fine if the checkbox opens/closes the panel, but it should remember its state (not always default to unchecked/closed), and that state should be used to determine if the values contained therein are used by the engine or ignored. (Of course this will probably confuse veteran module designers since it would be a behavior change.)

Of course, one could also ask why this stuff is in a hidden pane in the first place.