Bugzilla – Bug 12850
At-Start Stacks may contain pieces from different layers. Strange problems when you try and move them.
Last modified: 2020-07-12 21:28:17 CEST
By the way and a little off topic, I've found I must be careful with at-start stacks. I've been redesigning Merchant of Venus (2nd ed), and I created at-start stacks with units from different map layers. Doing this causes Vassal to temporarily stack those units, but once moved, they break down into stacks by layer. Fine. But this form of an at-start stack (units from different map layers) introduces some bizarre behavior that is hard to reproduce at will (the dreaded race condition). The problems happens inconsistently, sort of randomly and at differently times.
For example, I might hover over a stack of goods, which started in the bottom layer of an at-stack stack, and suddenly duplicate images appear. I will pull out the offending pieces (it may not happen to all units), and the mouse-over stack viewer will show a double image of the same piece.
Then I drag it from the main window to a player window, and the double-image disappears, but now a second copy of the piece appeared on its original map at the same relative (x,y) position as the first. I can move the doppelganger, but it then hops back to its original spot. Sometimes though if I try to click on it, it hops away as if I were reaching out to grab a frog!
So I then saved the game and reloaded it later to find that all the infected goods pieces have disappeared as if they were aliens masquerading as humans and that they had loaded onto their ships and left. Fortunately I had built an inventory window, and when I looked there, there they were! Nut they were in a non-existent null-named map window. I was able to send them to a discard pile, and I fetched them from there.
This suggests to me that Vassal may be getting confused about which map window a piece resides in. Perhaps its map location is stored in multiple locations, and those references say different things. It would explain the null map window. Just a guess though, but that's what I would look for.
When Game Piece Layers are not defined, all pieces and all Stacks are stored in a single List in a SimplePieceCollection.
When Game Piece Layers are defined, the SimplePieceCollection is replaced by a CompoundPieceCollection which maintains a separate SimplePieceCollection for each defined Layer.
A GamePiece belongs to a single Layer and is supposed to exist in a Stack that is stored in the correct SimplePieceCollection for that Layer.
There are at least 2 situations where pieces can end up in an incorrect SimplePieceCollection:
1. They are created in an At-Start stack that mixes pieces from different GamePieceLayers. Note that since GPL is dependent on a property value, it may not be possible during module editing to tell what the correct GPL for a piece is.
2. Since the GPL for a unit is dependent on a property, that property value may change over time, leaving a piece stranded in an oncorrect level Stack.
There are 2 issues resulting from this:
1. Movement. Something is going on with stacking/PieceCollection membership when moving units in incorrect GPL stacks, or moving stacks with mixed GPL units.
2. Some components (Counter Detail Viewer) do not cope with stacks of mixed GPL units.
One approach to fix this may be fix the components like the CounterDetailViewer to correctly handle pieces in the wrong layer and fix the layering as part of the next Move command.
This doesn't solve the problem for pieces that don't move though.Do we need to transmit a Command to clean it up? Or can each client clean up mis-layering as it finds it? GamePiece Layers are ephemeral, they have no individual 'state' stored within the Counter, so me might be right with each client just fixing the Stacking 'behind the scenes'.
Piece Movement works for stacks where all pieces are in the same layer, the problem seems to be only mixed Stacks.
Very interesting problem. Enyoy!
Created attachment 12089 [details]
Simple module with several layers
*** Bug 4105 has been marked as a duplicate of this bug. ***