GKCs firing on the same piece twice in one call?

How are pieces affected by a GKC prioritized?

I mean, if a GKC issues a command that activates on 10 pieces scattered around the board, are pieces prioritized randomly, following some specific pattern (piece id? location?) or anything else?

More to the point: is each piece guaranteed to activate just once or could it respond twice to the same call, perhaps because it changed location?

I am at a loss understanding why some pieces sometimes, but not always, seem to be activating twice on the one GKC call, while other identical pieces on the same call just activate once (as they should). With no apparent pattern.

This GKC just tells these pieces to move around the map (those in board A to board B, those in B to C etc). It looks that some piece sometimes is reacting to the GCK so fast, moving where it should, that the GKC thinks there is a new piece there to activate and the piece moves again.

This is with Vassal 3.5.5.

I have a similar problem that I recently re-discovered. It harks back several months when the developers were investigating an undo problem. I discovered that the undo problem probably was a side effect of a stacking problem, and I think you might be seeing the same thing. (My current problem disappears if I disable stacking in the window.) It looks like to me the problem was never fixed, or it it reappeared in the latest Vassal versions.

Here’s what happens. All stacking (pieces and maps) is enabled. I have a bunch of zones with regions numbered 1, 2, 3, etc occupied by pieces. When I press a button, all pieces go to the next region in sequence. Pieces in the last zone (“6” in my case) go back to region 1. Or at least they are supposed to. Instead they leap ahead to region 2 joining the pieces that moved to 2. It APPEARS that they double moved, but I don’t think that’s what happened.

I think when they moved to region 1, they stacked with the pieces in region 1, who had not moved yet. When the region 1 pieces moved, they incorrectly dragged along the pieces who had just arrived in region 1. It’s a matter of move order and an stacking error. I’m guessing you are seeing a variation of the same problem. Pieces are stacking and being whisked away by pieces that moved after them.

You can try a quick fix as a test. In the map window, locate the stacking options element and disable stacking. (It’s possible disabling stacking at the piece level may work too. I haven’t tried it just yet.) If your problem goes away, then you are almost certainly bumping into the same problem I have.

You nailed it!

Or part of the issue for me, at least: disabling stacking solves the problem for single pieces.

However, It seems that the problem persists for decks, though. I have identical decks configured in the A, B, C, D boards and the GKC is set to trigger on all pieces in a Deck, so that all cards in the board A deck should move to the board B deck, the ones in the board B deck to the board C one etc. However, again some of these decks take multiple jumps (all of them in a deck, not a random number of cards), in a random pattern. Sometimes a double jump, sometimes even a triple pole vault.

Hopefully some developer will chime in on both fronts, this seems a legit bug report.

If this is actually a bug, and not just a natural result of the way GKCs work (which I’m not sure about), it could be very difficult to fix. I think the correct way to avoid it, anyway, is to have a duplicate set of “staging” areas, and do the move in 2 parts–first, move all the pieces that need to move from their original location to the appropriate staging area, then, move them from the staging areas to the new permanent location. That should prevent any pieces from accidentally being moved a second time because they stacked with a piece that hadn’t moved yet.

That, or I was thinking of just moving everything in area A to B first, while flagging everything HasMoved==1, or something, then moving everything from B to C with HasMoved==0 etc.

Still, something does appear to be buggy here. Why would GKCs sometimes drag along stacked/decked pieces - which already reacted to the GKC - while sometimes not? It doesn’t sound that natural.

No, no, no. The GKC has nothing to do with this. It’s just the mailman who delivered the mail. The crime is committed AFTER the mail arrives, and the criminals are send-to-location and stacking. I don’t think you are not going to fix anything by adding another property because only the GKC uses it, and it is innocent.

To restate what I said earlier, we are issuing a GKC to all pieces on the map to go someplace. When your pieces in A go to B, they join pieces in B who have yet to move. Then those B pieces move to C. The problem is they are not separating themselves from the other B pieces who just got there. They are all stacked together, and so all of them (kicking and screaming) are dragged off to C. To observers, it looks like the original pieces double moved.

The only thing here that involves GKCs is the order that they are delivered, and I don’t think we can control that. Note that this is my theory of what’s happening, but the fact that enabling non-stacking fixes it supports my case. By the way, setting each piece to “does not stack” fixes the problem too.

Perhaps I didn’t explain myself clearly.

What I said is that I will have a GKC to move pieces from A to B, only. Those already in B, C and D will not be moved at this stage. And flag those pieces HasMoved==1.

Then I have another GKC move all pieces from B to C, but only those which have HasMoved==0. Stacked or not, decked or not, the pieces which moved before should not move again, should they?

They are separated by the HasMoved attribute now.

Well, I am happy to report that that workaround I just mentioned did the trick. Stacks and decks all move as planned, with no multiple moves.

Since I didn’t touch the STLs but only worked on making sure the GKCs didn’t trigger on the same pieces more than once, I suspect the GKCs are the culprits. Not the STLs. But I might be mistaken.

It’s a workaround for what seems like a bug, though. There should be no need to fire GKCs on things one bunch at a time to make sure they are not activated multiple times when stacking or in decks, shouldn’t it?

I am very surprised this worked. I am also thankful I didn’t claim I knew what was wrong and made sure I said it was my theory. It appears the logic is more complex than I thought. New theory: When a GKC is delivered to a piece in a stack, it gets sent automatically to all stack pieces. So with this new theory, all the pieces are actually getting more than 1 GKC, and so perhaps they are really moving twice. I would have thought a GKC would not know about stacks in an OO world.

I’ll have to remember your solution. (And I haven’t experienced deck problems like you.) Fortunately I don’t need stacking, so I can get around it by adding does-not-stack to my pieces.

You’re absolutely correct. GKC starts out by making a list of all the pieces and stacks on each map. Then it runs through them and attempts to process the command (on things that match). But because it processes stacking pieces based on the stack rather than a list of the individual pieces, there is the possibility that a piece can get moved to a different stack which has not yet been processed yet, and end up receiving the GKC command twice (or more than twice!).

And you’re also right that it can seem “kind of random” which stacks/pieces get processed first.

I certainly agree this is “not ideal behavior”. On the other hand fixing it could make GKC’s slower than they already are, so there’s that.

Sounds like you’ve figured out one of the workarounds – setting a dynamic property when the command is processed which then makes the piece get rejected by the filter on any attempt to process it a second time.

Brian

Why are GKCs being sent to stacks? Sending one GKC to a piece more than once is a big headache.

I have no explanation beyond “it was designed that way back in the mists of time” - and I’m sure when it went in the many exotic uses that would eventually be found for GKC’s were barely predicted or considered. (This is often the theme of VASSAL’s long and organic development history).

Brian