VERY odd GCK behavior, can anyone help?

Short version of summary:

  • I have a counter on the map that refuses to respond to a particular GCK (Report trait doesn’t even fire), that every other counter is responding to.
  • Even if I completely remove the “Matching” filter on the GCK.
  • If I first manually move the counter to a different space, it will then respond.
  • But if I first move it manually and then put it back in the original space, it will not respond.
  • It will respond to OTHER GCK’s, just not that one.

Here is a more detailed description:
(1) Big ole GCK intended to set up all my pieces “for the 1862 scenario”. Takes like a full minute to run, but I only need it for scenario setup.
(2) It all works fine, except I have one single general counter (J. Johnston) who does not move, just remains in his 1861 spot. He’s supposed to be moved to the Army of Northern Virginia: Commanding General spot. But he doesn’t.
(3) Compare this to the token for Lee, who (when I run the 1863 version of the GCK) is supposed to take command of the ANV (move to same spot as above). He moves just fine! I have compared J Johnston prototype to Lee’s with a fine toothed comb. I even copy/pasted the Traits over from Lee just in case I had misspelled or misconfigured anything.
(4) I have COMPLETELY REMOVED the “Matching Filter” on the GCK as a sanity check – literally sending it to every counter in the game. Every counter in the game responds… except J Johnston! (The jerk)
(5) I added a “Report” function to J Johnston to see if he was even receiving the GCK. It does not fire either.
(6) But IF I manually move J Johnston to a different nearby space (his 1861 at-start stack is in Winchester, VA) THEN he receives the GCK and moves appropriately.
(7) But IF I manually move him to another space and THEN move him back to Winchester and THEN fire the GCK, now he once again does NOT respond to the GCK.
(8) OTHER generals whose setup positions involve moving to/from the Winchester, VA space are receiving GCK’s just fine.
(9) Other maddening behavior… J Johnston receives and responds to the 1863 and 1864 GCK’s just fine!
(10) And if I run the 1862 command after running either of the others, he responds just fine to the 1862 one at that point (I mean really this is like just manually moving him to another space as in step 6 above)
(11) Not that it should matter, but I checked Winchester, VA’s zone & location mapping in the map grid itself – there is nothing unusual, it is fully inside its Zone (Virginia), I can find no other overlapping Zones (MD, PA, WV, and DC zones are all safely away).
(12) J Johnston is not part of e.g. “the very first At-Start Stack on my map” or anything, he’s just in the middle range.

Can anyone think of any reason that a single seemingly random counter would be completely refusing to acknowledge a GCK that’s sent with a null matching filter?



The problem occurs if, during the processing of a GCK, an earlier piece in the queue (while processing its own copy of the same GCK), happens to issue a GCK which moves another piece. The piece it moves, depending on where it gets moved, may lose its place in line entirely, and never receive the GCK.

So in other words, when the great big 1862 command went out, one of the earlier pieces to process a GCK ended up MOVING the J. Johnston piece with a GCK of its own. And this took J. Johnston out of the queue of pieces to recognize the first GCK, and so he never received it. And if I moved him to a different space first, he didn’t end up receiving the unwanted extra move command, so he stayed in the queue and got the GCK on schedule.

Just took me a few minutes to rewrite my (admittedly sloppy-ass) 1862 GCK to make sure nobody else was going to be issuing any unwanted side-effect GCK’s during it, and now it all works fine.

I mean obviously I would consider that “unexpected/undesirable Vassal behavior”, but I can certainly see how it’s edge-case enough that I might be the Very First Human Being Ever To Notice It. The pitfalls of being an unreconstructed automator!

LET THIS BE A LESSON TO YOU!!! :smiley: :smiley: :smiley:


And it’s specifically if the piece was in a Stack and is removed from the stack by the intervening GCK, since the internal “Visitor” logic process stacks as a single batch.

Yay troubleshooting ;)