The whole structure of Key Commands in Vassal 3 is cumbersome, confusing and unnecessarily complex.
Again, it had arisen organically over time as Vassal has developed.
The structure for how Commands are passed around inside Vassal is likely to change significantly, however, there are few things that really need to be done as part of this.
What we have now
Originally, all Command in Vassal where tied directly to keyboard key sequences (Control-A, Alt-Shift-D, etc.).
The addition of Named Key Strokes allow Commands to be tied to a name (string of characters) instead of a keyboard sequence.
Global Key Commands allowed a Key Stroke to be sent to all Game Pieces.
Global Hot Keys allow a Key Stroke to be sent to Game Components other than Game Pieces
Global Key Commands are arbitrarily divided into Global key Commands’ that
Some proposed changes.
1. Get rid of Key Strokes altogether as a basis for any sort of Commands.
All Commands should be based on a name, essentially what we have now with Named Strokes.
Key Strokes (Like Ctrl-A, Alt-Shift-D) should be able to be added to menu commands, toolbar buttons etc as Accelerators/Shortcuts, like every other piece of software ever written. An Accelerator key then initiates a Named Command.
2. Remove the distinction between Global Keys and Hot Keys
They are basically the same thing, except one gets directed to Game pieces and one gets directed to non Game Pieces.
This is just unnecessarily confusing.
Roll them into one type of Global Key Command. When you generate one, tick a couple of check boxes select whether to send it to just Game pieces, just non game pieces, or both.
3. Add a payload to Global Key Commands
You can send a Global Key Command from one Game Piece to another, but you cannot directly communicate any information between the two pieces.
This requires you to set up complex communication schemes using Global Variables, Trigger Actions and Dynamic Property commands to make useful things happen.
When you initiate a Global Key Command, it is not clear as to what part of the GKC is executed against the source piece, and what part is executed against the target piece, or how to compare values between the two.
I suggest we enhance Global Key Commands to be able to add a series of parameters that go out with the command.
Each parameter would have a checkbox to choose whether it is be evaluated against the source Game Piece before initiating the global command process, or against the target Game Piece.
The Property Match Expression (which is executed against the target Game Piece), would use a Lua function to access the Parameters.
The Command the gets executed on the target piece can also reference the parameters using the function.
NOTE: I am assuming the same {} functionality we use now for Beanshell to access Lua expressions.
Example mock up:
A Global Key Command that is sent to all Game Pieces to change the Dynamic Property named Division to the value of the NewDivision property on the source Game Piece. The Game Pieces to be selected must have a Formation property with the same value as the MyFormation property on the Source Piece.
Global Key Command setup:
Command Name: ChangeDivision
Parameter 1: {MyFormation} [Tick box to evaluate on source piece]
Parameter 2: {NewDivision} [Tick box to evaluate on source piece]
Property Match Expression: {Formation== GetParam(1)}
The Command that responds to this command will be a ‘Set Property’ Command. (The new equivalent to our current Dynamic Property Key Commands)
Receiving Command Setup:
CommandName: ChangeDivision
Property Name to Change: “Division”
Value to change to: {GetParam(2)}