UnDo issue for "face down" deck where pieces don't have a Mask trait?

Came across an UnDo issue that seemed associated with pieces that had been in a deck that was “always face down”, “draw face-up” but the pieces had no Mask configured.

The deck was hidden and only used for composite actions, to randomly order the pieces.

After performing said composite action, an UnDo caused pieces that had been in the deck to permanently disappear. GPIW revealed that the pieces were in their expected positions, so it was just the image of the piece that had gone. The pieces themselves had no BasicPiece image but instead always displayed one of two Layer images.

Changing the deck to not be face-down resolved the issue (so far).

Demo -
Module → here.
Log file → here.
Load log file into the module and play to the end to see the issue manifest.

Logged as issue #11225

Update for anyone else who might encounter this issue in future; it was caused because UnDo trashed the map location of one or more pieces (ie made them null).

The issue arises in my example when an End Turn action is undone. Specifically, End Turn re-orders a set of Player rOrder Markers. It is one or more of these that UnDo relocates to a null map.

Workaround: I remove and replace the player order markers before they are re-ordered (Delete/Place Marker). So far the problem has not recurred but if it does, repeating the End Turn action should repair the game.

Vassal version: V3.6.5
Example Module: Liberté (development version, due for release shortly).

Is there an earlier Vassal version where this works differently?

It’s a fraught process as the module in question has been developed in parallel with v3.6 and I’ve had to disable some of the button controls that the module relies on (dependency on fixes in v3.6.3).

So far as I can tell, the problem does not occur in v3.6.0 or v3.6.1 but it does occur in v3.6.3.

When I try to test v3.6.2 the module does not progress beyond installing its process i.e. no map and an empty system toolbar apart from this:
image

The Vassal error log shows this:

2022-02-15 10:58:59,925 [16872-main] INFO  VASSAL.launch.StartUp - Starting
2022-02-15 10:58:59,932 [16872-main] INFO  VASSAL.launch.StartUp - OS Mac OS X 11.2 x86_64
2022-02-15 10:58:59,932 [16872-main] INFO  VASSAL.launch.StartUp - Java version 17.0.1
2022-02-15 10:58:59,932 [16872-main] INFO  VASSAL.launch.StartUp - Java home /Applications/VASSAL 3.6.2.app/Contents/MacOS/jre
2022-02-15 10:58:59,932 [16872-main] INFO  VASSAL.launch.StartUp - VASSAL version 3.6.2
2022-02-15 10:58:59,932 [16872-main] INFO  VASSAL.launch.Launcher - Editor
2022-02-15 10:59:01,481 [16872-AWT-EventQueue-0] ERROR VASSAL.build.Builder - Error building VASSAL.build.module.map.MassKeyCommand
2022-02-15 10:59:01,481 [16872-AWT-EventQueue-0] ERROR VASSAL.build.Builder - Error building VASSAL.build.module.Map

It you can point me to interim builds during v3.6.3, I will try those.

The 3.6.3 builds start here

https://vassalengine.org/builds/list?page=24

Mark,

Have you been able to reproduce this using a fresh setup using all current counter definitions? As opposed to a save game that might have help older counter definitions?

@Brent_Easton - yes; I was reproducing the problem using fresh setups.