In game with counters that enter the game on set turns, I wanted to put those counters onto the appropriate space in the turn track and have the action of progressing the Turn Marker, automatically bring the counters into the game.
This is to work when a player drags the Turn Marker into place and also via a “Next Turn” toolbar button that moves the Turn Marker automatically.
Having set a Zone around the turn track, overlaid with a rectangular grid, I defined a “next turn” GKC button to send a command to the Turn Marker moving it a number of pixels to the right, sufficient to snap to grid on the next space.
Additionally, the Turn Marker piece has a trigger defined such that this movement will action a Global Key Command to signal the counters in its stack to move to their starting positions. Therefore, whether the Turn Marker is moved manually or by the Next Turn button, any counters in the next turn space should be brought into the game.
When the Turn Marker is moved manually, the effect is as expected. In this example, the Turn Marker has progressed from space 2 into space 3 and the counters there have gone:
However, this is not the case with the toolbar button.
The Double-Action Problem
When the toolbar button was used, the Turn Marker was actioned twice. So, in the example, the Turn Marker as progressed again into space 4, displacing a second stack of counters.
In the example, a subsequent press would again do a double action but the behaviour would often not reproduce after an undo. If the next turn space is empty, only a single move occurs, as expected.
After eliminating the obvious likely configuration errors and investigating whether the grid definition was causing the problem, I decided that what may be happening is that the action of relocating the stack of counters causes the Turn Marker to “wobble” into the next space, causing a repeat of the “next turn” actions. Perhaps this is more likely to happen with the automated method. I was unable to fix the problem by reducing the movement distance of the marker.
I decided to try delaying the automated Turn Marker move until after any stack of counters was out of the way. This is done using a variant of the GKC that moves the counters. When the Turn Marker receives the “Next Turn” key command, it first executes this GKC which operates on all relevant counters within a range of one space (in this case there is no danger of triggering counters in other adjacent spaces). Only then does the Turn Marker move itself. The original stack-based GKC is still used when the Turn Marker is moved manually. Now the “Next Turn” button works reliably.