At Start Stacks

I do almost exactly what cattlesquat does with one difference. I usually pull all related pieces at once into a palette or at-start stack with the batch loader, and then cut/copy them from there to their final destination at-start stacks. That way I don’t have to be careful about naming them or their images.

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.

It was all very amusing but unworkable, so I rebuilt the at-start stacks so that only units from one map layer were and one stack, and the problem vanished. Lesson learned: don’t mix map layers in the same stack.

I’ve had that exact same behavior–doubled piece images (and on 2 different map windows)–stemming from an initial at-start stack containing pieces from different game piece layers. If I ever get around to another update of that module, I’ll have to split them into multiple stacks.

This issue makes sense. In the normal course of events, Vassal will never allow 2 pieces from different Game Piece Layers to reside in the same stack. The PieceMover code is making assumptions based on this fact. The At-Start stacks allow you to over-ride normal Vassal behaviour and force pieces from 2 different game layers into the same stack. The symptoms you describe do not surprise me and the workaround of creating 2 separate At-Start stacks in the same location to separate the layers is a good one.

I’ve open a bug report for this and will investigate, it is potentially quite easy to fix.

Cool, yeah, it should probably just create a separate formal stack (all at the same location) for every different layer.

Also… OP of this thread probably be like “WHAT HAVE I DONE!!!” :smiley:

I want to look into what the PieceMover is actually doing and fix it at that end. This could potentially also occur if the Game Piece Layer is depending on a Dynamic property that changes value and a piece suddenly finds itself in the wrong stack.

Let me note for the record that the implied (in the documentation) ability for a Game Piece Layer to be dynamic in the sense of being changeable, DOES NOT WORK!!! I mean yes, you can have it look at a Dynamic Property or Calculated Property, but if one was thinking one could have it change value and the piece would smoothly change layers back and forth, well, um, NO. Anecdotally it seems to “work” until it changes level towards the topmost, and then fixates at whatever its topmost level is.

I once went on a “peekaround”, thinking maybe I could custom-class that into existence for myself, but came away thinking “EEEESH” – there would be a LOT of places the code would have to learn to recalculate and deal with it on the fly.

Of course if Vassal 4 learned how to do that in the course of being implemented, then Wowza that would be super-useful!

Brian

Am I understanding that at present, the preferred method to create a module with multiple setups is to exclude almost everything from the At-Start Stack and just create Saved games by dragging and dropping pieces from the Piece Palette? What if your game has a fixed Force Pool and you don’t want players to ever add and remove pieces? A slightly related question - does every piece need to be in an At-Start Stack? i.e. if I have 155 non-stacking pieces, do they need 155 At-Start Stacks?

That is how I handle multiple scenario setups.

To support ‘Force Pool’ type play, you can create a second Game Piece palette that just contains the markers you need for on-going game play and click the 'Hidden? (requires restart) checkbox on the main Game Piece palette so it does not appear to players and they will only be ably to use the pieces supplied in the game setup.

You need one at-start stack for each different location where you want at-start pieces to be created.

Wow. I guess what I find troubling about that is you never know what’s going to happen to saved game files when you update a module…

Well actually, it’s pretty predictable under Vassal 3. Unless you make structural changes to the module itself, then a saved game from an earlier version of the module is guaranteed to execute exactly the same on the new version of the module as it would on the old.

At-start stacks have no effect, influence or relevance to saved games in any way.