While adding some automation enhancements to the Normandy 44 module, I found a weird but reproducible issue which smells to me like a bug in the Vassal engine itself.
I have created a stripped down demo module called TestCase_JGH with a single Test case scenario which demonstrates the issue. It can be downloaded from my DropBox using this link.
This demo was created using the Normandy 44 map board with a Multi-zoned Grid in which each space of the General Records Track (GRT) is defined as a separate zone (named “General Records Track 0” through “General Records Track 9”). The scenario instantiates just 3 game pieces - the Fortress Cherbourg Marker and GE 7 Army Marker each start in the GRT 0 space, and the Weather Marker starts on the Weather Track space 2.
The functional guts of this demo are found within the TestCaseCtlr prototype (referenced in the Weather Marker) and the TestCaseMarker prototype (referenced in the two HQ markers).
The desired functionality is that the Weather Marker can automatically advance the two HQ markers along the GRT. The number of spaces that they are to advance will ultimately be determined from the Weather Table, but in the demo are user-specified for debug purposes.
The steps to demonstrate the issue are:
- Open the Testcase_JGH module using Vassal version 3.7.12.
- Start the Test case scenario.
- Right-click the Run testcase menu item on the Weather Marker.
The module will first prompt the user (twice) to specify the number of “Supply Points” to be allocated to each of the two HQ markers on the GRT. It will then advance those markers along the GRT the number of spaces equal to their respective Supply Points (SPs).
This mechanism works as expected in most cases. For example, if you run it while specifying 1 SP for Cherbourg and 2 SPs for 7 Army, those two Markers are advanced along the GRT to spaces 1 and 2 respectively, and the following lines are emitted to the Chat Log:
- STARTING TEST
- CherbourgSupply=1, 7ArmySupply=2
- Fortress Cherbourg Marker received AdjustMarker command with GRT_Adjust=1
- Fortress Cherbourg Marker moved from General Records Track 0 to General Records Track 1
- GE 7 Army Marker received AdjustMarker command with GRT_Adjust=2
- GE 7 Army Marker moved from General Records Track 0 to General Records Track 2
Note that the two lines above shown in bold (and which really appear in green) are from the two HQ markers, indicating when they receive the AdjustMarker Global Key Command which is sent by the Weather marker. Each of those two HQ markers received exactly one such GKC, as intended.
To demonstrate the issue, run the test while specifying an equal number of SPs to be sent to each HQ. For example, press the UNDO button to roll back the previous test and return the markers to the 0 space on the GRT, then rerun the test while specifying 1 SP for each HQ. The Chat Log will report the following:
- STARTING TEST
- CherbourgSupply=1, 7ArmySupply=1
- Fortress Cherbourg Marker received AdjustMarker command with GRT_Adjust=1
- Fortress Cherbourg Marker moved from General Records Track 0 to General Records Track 1
- GE 7 Army Marker received AdjustMarker command with GRT_Adjust=1
- GE 7 Army Marker moved from General Records Track 0 to General Records Track 1
- GE 7 Army Marker received AdjustMarker command with GRT_Adjust=1
- GE 7 Army Marker moved from General Records Track 1 to General Records Track 2
Note that there are now three bold lines in the log, implying that the GE 7 Army Marker received the AdjustMarker GKC twice. The 7 Army marker was accordingly advanced two spaces instead of one. That is the unexpected behavior I am reporting.
My experimentation suggests the following pattern:
-
The issue always occurs whenever each HQ is allocated the same number of SPs, and in each case it is the 7 Army HQ which receives the extra GKC (and advanced along the track) twice.
-
If the TestCaseCtlr prototype is hacked to reverse the order in which the two HQs are sent their GKCs, then it is the Cherbourg HQ which receives the extra GKC (it is always the last HQ which receives the extra GKC).
-
If the TestCaseMarker prototype is hacked to disable the Send To Location command which actually advances the marker, then the issue with the extra GKC does not occur. This seems important, but I don’t know what to conclude from it.
Some implementation notes about this demo:
To remove unnecessary complications and allow inspection (using /prop show commands), the demo relies on Global Properties to store the user specified supply allocations and to pass those supply values from the Weather Marker to the HQ markers. I had originally passed the supply values directly into Dynamic Variables in the HQ markers using the “Set Dynamic Properties in target pieces” feature of the GKC trait, then tried using the Set Piece Property trait. The same issue occurred with those implementations also.
To pass the supply value to an HQ Marker the TestCaseCtlr prototype stores that value into the GRT_Adjust Global Parameter, then uses the Global Key Command trait to send the AdjustMarker command to the HQ, targeting the HQ by specifying its BasicName in the Additional matching expression field. That GKC originally used the Pre-select (Fast Match) field for that purpose; the issue occurred with either variation.
Any advice on how to proceed would be appreciated. I am available to conduct additional experiments if needed.
Cheers,
Jim Hunter.