I am using a layer to make all marker pieces of a certain type (planning markers) to disappear at the press of a button, that toggles invisibility for the layer off and on. For some reason, after updating to Vassal 3.4.3, this button now most of the times does not make all of these markers invisible. Some are almost always left visible. However, if I move one of the markers, it immediately becomes invisible.
It seems to me that somehow the layer trait is bound up with the Moved trait.
I may also have made a bug myself, so I thought that perhaps there is a simple demo module that I could fiddle with, and see if I can recreate the bug. If I am right, it will also be easier to demonstrate the bug.
Hi Brent, I found that another issue with the same module was caused by a module mismatch with the saved games, so I think I need to recreate all scenarios from scratch and see if this problem disappears. Thanks for your kind offer.
Hi Brent, unfortunately the bug was still there after I ensured that every single counter was created with the current module version. I thought it was only when there were lots of counters on the map, which is why it has taken me a long time to rebuild my current game with new counters, but now I know that the process of restoring a saved game is part of the problem, because there was no bug while I built the saved game, it was only when I loaded it afterwards.
I have also made a minimalistic saved game with the bug.
How can I pass the module and the saved game to you? I would rather not publish a link to an buggy module in my Dropbox in a public forum.
There’s some very weird stuff going on here. The Pieces do not seem to be inserted into the correct Layer on load from a save game. That’s why they seem to ‘dissappear’ after moving when you hide their layer.
What version of Vassal where you using prior to upgrading to 3.4.3?
Also, just want to be sure that you are aware that GamePiece Layers are completely local to each client? The state of layers that you choose to show does not affect what other players see and is not saved in a log or save file, it is reset each game. Or is supposed to be, but I this is not happening if you start a new game or load a game without leaving Vassal, the layers setting remain the same as for the last game you had open.
I used Vassal 3.4.2 before 3.4.3, but I am not sure when I saw the bug first. It may only be with 3.4.3 that I started saving the game and used the Hide button on a saved game. I am now using 3.4.6 and the bug is still there.
Thanks for looking into it.
Is there some minimal demo module where one could see if the bug is present?
Looking in your module, we noticed that in your “Planning” prototype for the pieces in question you have a “Trigger” trait, which accepts Ctrl+Shift+I as its command but then also issues Ctrl+Shift+I as its command – the same command that controls your “Invisible” trait.
We think that might be what is causing the Invisible trait to “go haywire” – when its command is coming through, it may be coming through several times (I haven’t fully wrapped my brain around what order a Ctrl+Shift+I is resolving itself in, and how many times it resolves – and in fact the results seem to suggest it may be resolving in a different way for different counters). We tried your module with that one trait removed, and all the counters seemed to properly hide themselves when the toolbar button was pressed, and then to unhide themselves when it was pressed again, etc.
Please let me know if we’ve misunderstood in some way, but that may be the cause of your problem. Note that if you change the prototype (to remove the Trigger trait) and want to test it on those same Save files, when you load the save files into the “new” version of the module you will first need to run the “Refresh Counters” function from the “Tools” menu of the main module window (Or if you create a new save file w/ the new version of the module, that will also work).
The trigger trait was implemented in order for the counters to stay invisible to the RAF side. Without it, the planning counters tend to pop up when least expected, for instance, when the Show/Hide button is pressed. It is a pity there is no way of commenting such design considerations, because then I could have explained it directly in the code.
But does it interfere with the Invisible trait, as you suggest? No. I zapped the Trigger trait, but could still reproduce the problem. I started from “New” scenario so that all counters are created new. Logged in as Luftwaffe, dragged a couple of planning counters to the map, and saved the game. When I reloaded the new saved game, the Show/Hide button still only hid the planning counters that were moved.
The trigger trait was gone, so that the moved counter was visible to the RAF side.
Oh - I hadn’t realized that making a new saved game was part of the repro steps - it does indeed create a problem when I make a new save file as you describe.
Was there ever a version of Vassal where this DID work right? (I can’t seem to get it to work under 3.2.17 either)
Side comment: I am sure I saw a thread from the distant past (build up to v3.2.17) where consideration was given to ignoring a “perform” Key Command in a trigger to prevent the loop that Brian refers too. I don’t recall what the outcome was, if any.
It looks like it’s a bug in the “save game” / “load game” sequence – it isn’t restoring the pieces to their proper layer, so they aren’t “in” the layer when the button to hide the layer gets clicked. And part of moving a piece turns out to be “putting it in the right layer”, so that’s why it “fixes itself”.
We will work on a fix, the main issue being “Not To Break Anything Else While Fixing This”, since as far as I can tell this bug has been in Vassal “Since Time Began”.
Mixed results. It certainly removes the problem in the test that I set up, but in the saved game from my running game, the situation is the same.
Possibly it is necessary to delete and recreate all the planning counters in order to fix it, but I do not have time for this right now (there are lots of planning counters in the real game). I’ll do it soon, though.