3.5.8 Disappearing deck and pieces

Using the module here drive.google.com/file/d/19WD0mF … sp=sharing

Log here: drive.google.com/file/d/17Y4_FC … sp=sharing

Very short log, player right-clicks and selects a menu option that sends a bunch of pieces to set positions on main map, reverses a deck, sends 3 cards from the deck to his private window, reverses the deck again.

What happens is that the bunch of pieces get sent, but the deck disappears, along with 3 cards the previous player placed on the Main map.

Very serious bug, cause unknown, not always replicable, but it has come up more than once.

Note that undo-ing the step in the log and viewing it again results in the cards in decks reappearing, but not the card above Hans’ name. Don’t know if this info helps pin down the bug.

EDIT: Further investigation clarifies that the 3 cards sent to Blue’s private window from the World deck are the same 3 cards Red (previous player) had been dealt and already placed on the Main Map in the previous log. This should be impossible, given that the gkc to send the cards targets 3 cards from the World deck. It does explain what happened to the card above Hans’ name, but not how or why.

What exactly are you expecting to happen next?

If you want me to investigate further, then the information you have provided is woefully inadequate. I am completely unfamiliar with the game or what is supposed to happen.

Which of the log steps is failing?

Exactly which ‘the deck’ and ‘the 3 cards’ is disappearing, I have no idea what is a Deck and what isn’t and which pieces are supposed to disappear and which aren’t. Please spell it out with annotated screen snaps.

Regards.

Fair.

OK, here are some screenshots, hope this works as the forums here don’t seem to host images:

Initial state, key decks and pieces labelled

(That’s boardgamegeek.com/image/6296903/benkyo)

The very first step of the log. What should happen: A) a bunch of Red pieces get sent from a different window to positions at the top right corner of the main map (this works fine), and B) the World deck gets reversed, 3 cards from the World deck get sent to a private hand window “Red”, and World deck gets reversed again. Instead of what should happen in (B), the World deck disappears, and the 3 cards the previous player (Blue: Hans) had been dealt in the previous log get picked up from 2 different locations (the Cradle deck and a stack next to the Blue player board, above the name Hans) and sent to the private hand window “Red”.

(That’s boardgamegeek.com/image/6296904/benkyo)
All the commands are sent from the “RedSeat” piece with Seans’ name text label (prototype “PlayerSeat”). Note that the gkc SendtoHand targeting the 3 cards has the Preselect target Specific Deck “World”, so I don’t know how or why it picks up the 3 cards that had already been moved out of that deck by the time the log starts. The world deck disappearing must have something to do with it, but what would cause the World deck to disappear I don’t know.

As another data point, if this single step is undone, the World deck reappears, the Red pieces get sent back where they started, but the 3 cards incorrectly sent to the Red private window do not return to the Main Map.

(That’s boardgamegeek.com/image/6296905/benkyo)

Also, please note that this does not happen in the majority of games played with this module. Normally everything works fine. The conditions needed for this bug to occur are unknown to me, but I can confirm it has also happened in one game I played where I did nothing different to usual when creating my log.

I would greatly appreciate this being looked into, thanks.

If there’s anything else I can provide, please let me know. These are really serious bugs, and I can’t really finalise the module until they are resolved - the bugs occur too often and can completely and irreversibly disrupt games.

I am working on this. Thanks for the extra info, I understand what is happening now.

Glad to hear it, thank you!

Another bug, which I mention only because it might be related, is when a gkc to a single card in a deck, supposed to send the card to the coordinates of another piece on the map, causes a card already elsewhere on the map to appear to be duplicated at the destination. The player taking the action often doesn’t notice the error if “both” cards are face down. To other players though, subsequent drag and drop of the “duplicate” card moves the “original” card.

This is harder to catch on logs, and has only been reported through screenshots and video capture, but it seems similar: card should be moved from deck, but instead a card previously taken from that deck is moved (duplicated) instead.

Still plugging away.

Could you please send me a log of the same process, but when it works? I can see it failing in the code, but it is deep down in the bowels of Deck and I need an equivalent example that works so I can see what is supposed to happen. The initial Deck reversal is failing in a strange way and it is not obvious why.

Thanks.

This is how it normally works:
drive.google.com/file/d/1z91DI1 … sp=sharing

And another example, but 3 times in succession:
drive.google.com/file/d/1pbnIP_ … sp=sharing

Ok, I think I have made some headway.

There appears to be a bug in the Vassal Deck handling that is caused in very specific circumstances.

The bug happens when you are replaying a log and there is a Step that says change the contents of a Deck from the set of cards X to the set of cards Y, but the Deck currently has a set if cards Z that does not match the supposed start state of X.

I am fairly sure this can only happen when you use the old ‘Load Continuation’ menu command to load and play a log file out of sequence that does not match the state of the game you currently have. If you are also recording a new log file at this point (for example, to copy the last players moves in a multi-player game), then the bad Command is copied into the new Log file.

I don’t believe this can happen in a normal load log situation, since loading the log should syncronize the Deck contents with any Commands that are generated. This is one of the reasons we have hidden away the old Load Continuation command and strongly recommend against its use.

There is a piece of code that is run to handle this case when it happens to a Stack, but when it happens to a Deck, the Deck runs the Stack version of the code and ‘Bad Things Happen’ ™.

Does this make sense? Can you confirm if this log file may have been created in this way? i.e. Do your players use the ‘Load Continuation’ feature to copy steps from log files?

I will look into fixing the bug and making Deck handle this correctly, but this will just prevent the current bizarre behavior, it can’t fix the wrong results you get if log files are loaded out of order via Load Continuation.

Regards,
Brent.

I am 100% sure the bug occurs when loading a log normally, and not only when using load continuation, because it has happened to me in a fresh game where I created and loaded every log myself.

I’m also pretty sure the bug has occurred in a completely new game, where no log was ever loaded, but I’m not 100% confident on that.

What I am seeing has got nothing to do with how you load the log. The issue is caused by the person who created the log, using ‘Load Continuation’ to load a log file that does not match the current state of the game they are playing, then making and recording a move.

I know. Apologies for the lack of clarity. I’m saying that I can guarantee the bug occurred for me in a new game in which load continuation had never been used.

I’m sure that’s the case for the games played by others too - everyone knows load continuation is off-limits, and once the initial setup is provided as a vsav or vlog, it’s a very short, very simple sequence of logs once around the table to finish setup. There is no motivation to view any log other than the one immediately prior, as there is nothing to see, let alone trying to string them together with load continuation.

Hmm, It’s hard to see how this would be possible, unless it is some sort of race condition where two players are trying to apply changes to the same Deck at the same time. However, your description seems to be implying a sequence of single-player PDEM actions.

Regardless, I have identified the bug that is causing the carnage when it does happen, so I will start working on fixing that.

Regards.

I have created a new build

VASSAL-3.6.0-SNAPSHOT-d6629a4-10381-Deck-Corruption-windows-x86_64.exe

Could you please give this a try replaying the log that corrupts the Deck. The Deck no longer disappears, but I can’t tell if it is doing all the other things it is supposed to do.

Thanks,
Brent.

Interesting. The deck doesn’t disappear, but cards are still being moved from the wrong places.

You can ignore all the movement of red pieces to the top right of the map.

It appears that the card next to the Blue player, Hans, and two cards from the 4 card small “Cradle” deck are still being sent to the private player hand “Red”. That’s the same bug as previously. Undo still fails to return those cards where they came from, but now seems to return them to the top of the big “World” deck (the one that previously disappeared).

A new bug seems to be that the reverse-draw3-reverse instructions for the main big “World” deck instead just reverses the deck once, and leaves it reversed even after an Undo.

So, what should happen: the World deck is reversed, 3 cards from it are sent to the player hand “Red”, the world deck is reversed again. That’s all that matters for this bug (other piece movement irrelevant).

What happened previously: World deck disappeared, 3 cards taken from the World deck in the previous log and placed on the map are sent to the player hand “Red”.

What happens now: World deck reversed only once, 3 cards taken from the World deck in the previous log and placed on the map are sent to the player hand “Red”.

Note that a very quick sanity check to see if the World deck is in the right order is to see if the top card is one with an “eye” symbol on it, different from all the other cards of the same type.

If you are curious, you can see the (only) two previous logs for this game too. They are equally short and very similar, but working as intended.

(There’s definitely some oddness with the 2nd log: it starts after the step of card draw. This looks like a typical start-logging-too-late thing, but maybe it is a source of the bugs for the problem 3rd log.)

I’ll have a look at those 3 cards next, but what I am seeing so far is that Vassal is trying to step through log commands that do not match the play state of the game in play.

That’s why undo doesn’t seem to work, because the undo is going back to a play state recorded in the log command that is different to the play state that was loaded with the log command.

Unfortunately, I can’t determine the cause of that from the supplied module and log file. The problem occurred when the log file was created, what we are seeing now is a natural consequence of the play state mismatch playing out.

Regards.

The play state for log 003 was created using log 002. My question is how the following occurred:
log 002 resulted in 3 cards moving from the deck to hand, and from there to another deck and single card stack.
log 003 starts with those 3 cards where they should be, but the command to move 3 more cards from the deck to another hand instead moves the 3 cards from the previous log to another hand.
Undo log 003 returns those 3 cards to deck.

Obviously, the cards are both in and out of the deck, which is causing problems. But the end of log 002 does match up to the beginning of log 003, so it’s hard to see how that’s possible.

I can say that setup appears to work normally using the snapshot version of Vassal, but that was the case previously too.

I am getting a new “Deck not found for return-to-deck trait” error on setting up a new game. That’s new. I now have the errorlog audit preference on, but can’t find the generated errorlog.

I am getting a new “Deck not found for return-to-deck trait” error on setting up a new game. That’s new. I now have the errorlog audit preference on, but can’t find the generated errorlog.

See 3.6.0beta1 is erasing deck names in some return-to-deck traits - #2 by Brent_Easton
There is a bug in 3.6 that is erasing some RTD target deck names. Working on it.

The play state for log 003 was created using log 002

Ok, so theoretically we have all the materials to try and reproduce this. Can you describe exactly what was involved in creating log 003? Presumably log 002 was loaded, stepped through to the end, then log 003 was started recording?