Question for J Uckelman

Hi J,

I’m wondering if you could take a brief peek at a situation I’m experiencing involving Move Trails.

Here is the situation briefly:

  1. I have units (pieces) whose At-Start stacks are on a “Reinforcements” window separate from the main map.
  2. I have cards that can be played to cause these units to be deployed to the map via Send-To-Location. (Obviously the player could also just go to the window and manually drag the reinforcements onto the map)

BUT, when one of the event cards gets played to deploy a unit to the map, the new unit is (spuriously) appearing with Move Trails set to visible, even though I have them defaulted to not visible.

EXCEPT, that if I go “peek at” the Reinforcements window (i.e. open it at least one time and look at the units), THEN the spurious move trail does not appear. (And in fact, if I only peek at the German units on their window, and don’t peek at the British units on theirs – then only the ones I didn’t peek at gain the unwanted movement trails).

This is presently 100% repro rate for me. I have a Report function set on the Ctrl+T to let me know if anybody’s getting an illicit Ctrl+T to turn their trails on, and I’m not seeing anything like that.

I’m wondering if there could be parts of units/pieces that could be getting “uninitialized data” before the unit is “seen” for the first time, such that when a unit appears on the map for the first time (via send-to-location) w/o ever having been “looked at” by opening its starting window, it might have odd data in some fields.

Having spent 4-5 hours isolating this down, I seem to have come to the limit of what I can do without a Vassal Engine expert, so I’m hoping you’d be willing to take a look. Happy to upload the present version of my module if that would be useful.



As a slight update-- after further tracing I have narrowed down the repro situation. When the piece first arrives on the map, it is receiving (from me) an Alt+M, which is the key I currently have assigned to clear its movement history (i.e. assigned to its Mark When Moved trait).

Somehow it is this Alt+M that is turning ON the piece’s movement trails, even though I have movement trails defaulted to “not visible”. And of course if I go “peek at” the window where the piece sits before it is Send-To-Location’ed the map, then I have no problems – somehow after that sending an Alt+M to the piece does what I expect it to do (which is at least to not turn ON the movement trails that were off).

I can go into the reasons I normally need to send an Alt+M to a piece when it arrives on a new screen (so it doesn’t leave weird trails left over from being on the other screen), but anyway this is where I have so far narrowed the repro.

Looking at, I see that “localVisibility” is not definitively initialized the way globallyVisible and initiallyVisible are. Is it conceivable that I’ve found some repro path where that’s getting read from before it ever gets set?

It loooooks like the only place localVisibility would get set to false (that is, assigned the value of “initiallyVisible”) is if the method clearTrail() is called. And one of the places for clearTrail to be called is in the piece’s draw method. Which certainly rings true to the “if I peek at the piece at least once” part of the repro steps.

Possibly this would clear up if localVisibility was initialized to “false” in the class? Or do at-start stacks need to initialize movement trails for pieces they create?

Please let me know if there are any workarounds for me - or if I can be of any assistance.

Submitted a bug for this - happy to provide a module that reproduces the situation if desired. … i?id=12551