The 3 logs are the result of following the actions I described.
In order to experience the bug you need to have a module with a ‘send to’/discard function, which is easy enough. You also need 2 log files generated by people with different names/passwords. Then you need to load both of those logfiles in succession and attempt a send to/discard action with a 3rd name/password. If you follow those steps the bug is readily apparent.
Simply viewing 3.vlog will show the bug effect (piece gets sent to 0,0 instead of 100,100), but it is probably better to follow the steps and experience the bug yourself.
Just so we get this straight, are you exactly following this procedure when creating the continuation logs:
- Player 1 creates a new log, does some moves, closes the log and sends it to player 2
- Player 2 opens the log, steps through to the very end, opens a new log, does some moves, closes the log and sends it to player 3.
- Player 3 repeats the player 2 process.
Thanks,
Brent.
Not quite.
Player 3 views both logs in succession after starting the Vassal program, so he is not repeating the Player 2 process.
It is viewing 2 logs in succession that triggers the bug.
Player 3 can avoid the bug by viewing Player 1’s log, closing the game, then re-starting the game to view Player 2’s log.
The erratic nature of the bug, and the reason some players experience it and others don’t, is because some players view all the logs between their previous turn and their current one in succession, while other players view each log as they arrive and thus only view one log immediately before starting their own.
Ah, ‘creating a continuation log’. That’s not something that the players here are aiming to do.
The goal is simply to view each log that was made between a given player’s turn, then create a log for that player’s turn.
Perhaps I (and the other 20+ players I have played with) misunderstand the purpose of ‘load log as a continuation’? I understood it to not only be used for creating continuous logs, but also to allow the viewing of several consecutive logs before creating the next log in sequence.
Player 3 opens the log from Player 1, steps through to the very end, opens the log from Player 2 ‘as a continuation’, steps through to the very end, opens a new log, tries to perform some actions but the bug occurs. Closes the log.
Well, that pretty much explains your problem.
When you are playing a PBEM game, you have to think of it like the children’s game of ‘chasings’. Some is ‘it’, they make changes to the game and save them to a log file. They then pass that log on to someone else who now becomes ‘it’ and it is their change to make changes. They do the same, make some changes and save them in a log file (or save file) and pass it to the next player.
The player who is ‘it’ is the only player in the whole group who has the complete and current game state, everyone else is out of date. What you are doing is trying to merge multiple out of date games into a single game, it just won’t work.
In a 6 player PBEM game, player 1 must do his turn and send it to player 2. Player 2 does his turn and sends it to player 3. And so on (the actual order does not matter). You CANNOT have player 6 send a save file to the other 5, have each of the 5 do their turn and send them back to 6 and have 6 then merge them all in. Unless the module has been VERY carefully crafted with exactly this in mind, each of the 5 log files will be overwriting parts of the game state that other players have changed and you will get bizarre and erratic behaviour (sound familiar?)
Yes, as long each log was created by a player who first loaded up the log (or save) from the previous player, maintaining the continuous chain of the games current state.
So you are saying that the end of player 1’s log is not the same game state as the beginning of player 2’s log. Two logs cannot be viewed back-to-back.
The only way a player can view all the intervening turns and make their own log without bugs is to load the first log, view it, close the game, load the next log, view it, close the game etc. until they load the most recent log, view it, then start their own log.
This seems very counter-intuitive, and really something that should be emblazoned somewhere very obvious for all to see. Every single person who has played my module with 3 or more players has encountered this bug, intermittently because of player behaviour, and been baffled by it. I have taken to prefacing all games with strict instructions to only view the most recent log before starting your own, and added such instructions to all tutorial logs and instructions… it just isn’t something any user I know of has thought of on their own, and only through extensive trial and error did we discover the ‘bug’ and the work-around.
Thanks for the responses though, and thanks for clarifying that this isn’t technically a bug, but is working as intended (however mystifying that may seem to us laymen).
It is if at the end of creating his log, player 1 sends it to player 2. Then player 2 opens the log just sent to him and plays through to the end. Now player 2 is in the same state as player 1 was when he finished creating his log. Player 2 can now open a log file and start recording his moves.
There should be no need to close the game and load the next log. That is what Load Continuation is for, but it requires that logs have been correctly created.
I am still unsure of the exact sequence and which moves you want to see. If you want each player to seethe last 6 moves, then here is one way:
Turn 1, Player 1 - creates a log file, makes moves, closes log file and sends to player 2
Turn 1, Player 2 - loads log file from P1, opens a new log file, replays moves from player 1, makes moves, closes log file and sends to player 3.
Turn 1, Player 3 - loads log file from P2, opens a new log file, replays moves from player 1 and player 2, makes moves, closes log file and sends to player 4.
Turn 1, Player 4 - loads log file from P3, opens a new log file, replays moves from players 1, 2 and 3, makes moves, closes log file and sends to player 4.
Turn 1, Player 5 - loads log file from P4, opens a new log file, replays moves from players 1-4, makes moves, closes log file and sends to player 6.
Turn 1, Player 6 - loads log file from P5, opens a new log file, replays moves from players 1-5, makes moves, closes log file and sends to player 1.
Turn 2, Player 1 - loads log file from P6, replays own moves from turn 1, opens a new log file, replays moves from players 2-6, closes log file and sends to player 2
and so on.
Here’s another way, keeping each players logs separate.
Turn 1 Player 1 - creates a log file, makes moves, closes log file and sends to player 2
Turn 1 Player 2 - Opens log file from P1, play to end. Open new log file, make moves, close log file and send own log and log from P1 to P3.
Turn 1 Player 3 -
If player 3 want to see all moves, then
- Open Log from P1 and play to end
- Load continuation Log from P2 and play to end
- Open new log file, make moves, close log file and send all 3 logs to player 4
If player 3 isn’t interested in old moves then
- Just open Log from P2 and play to end, then do own moves.
and so on.
I am still not quite sure of exactly what you are doing, but unless you play follow-the-leader with logs in order, it should seem obvious that players will be overwriting and corrupting each others moves.
I have not heard of a game being played PBEM with more than 2 players before, so you are a pathfinder.
This is the sequence that causes the bug and the default way that most new players assume things work. So it is a bug. If you try this for yourself you should see that any piece Player 3 tries to send to a deck or similar gets sent to coordinates 0,0 instead. The test module I uploaded is a perfect example as there is simply nothing in it except a pile of pieces and a ‘send to’ function.
Let’s go back to here:
Where you said
I may have misunderstood you there, I realise now I am not actually sure what you are doing exactly.
Let’s back up to there and try again.
Can you please describe EXACTLY the sequence of steps, menu commands etc, that players 1,2 and 3 do in the course of a turn. Who sends which log files to who and when?
Thx,
Brent.
I know it seems strange, and I can think of no reason why it would cause a bug, but the exact same process that you yourself described always reproduces the bug. I am in no doubt that the very same steps you described here describe perfectly the steps that I and many other PBEM players have made:
This is the exact sequence I tried to describe myself and this will reproduce the bug, I guarantee it. You can even do it on one computer if you load up Vassal and change your name and password 2 times in between those steps to simulate 3 players playing in succession.
I know you are asking for further clarification and there has been a lot of misunderstandings in this thread, but the only way you’ll see the bug is to act out those exact steps with any module you care to try it with (as before, I suggest the test module I linked near the beginning of the thread).
Ok, thanks. Just wanted to make sure that nothing simple had been missed. I will try and look into this over the weekend.
Regards.
There are tons and tons of 3+ player games being played PBEM with VASSAL, this isn’t a new phenomenon by any stretch! 
Which makes me wonder why this bug isn’t seen all the time 
Perhaps it is, or perhaps only in recent Vassal updates. I think the bug has been present since I started working on my module near the beginning of this year, though I can’t say with any certainty, and it seems other people have encountered it with other modules: https://forum.vassalengine.org/t/return-to-deck-bug/5844/1
Have reproduced the problem and added It as
Bug 10249 - Deck loses position over loading multiple player logs
The Return to Deck is fine, it is a problem with the Deck internally losing track of it’s location. Working on it.
It is not just sending pieces to decks. IIRC it also occurs when sending a piece to any given coordinate… but it is possible I’m mistaken.
Found the problem. As I suspected, it is a problem with the Deck having it’s position overwritten with 0,0 when loading a continuation file.
Fix committed to svn 8755
This would not affect Send to Location in anyway.
Excellent, thanks for taking the time to hear me out and get it fixed.
Now if only there were a way to get that fix in 3.2.5. I suppose I’ll just have to hope the problems I’ve had with 3.2.6 go away in versions 3.2.7 onwards…
Thus spake Brent Easton:
Found the problem. As I suspected, it is a problem with the Deck having
it’s position overwritten with 0,0 when loading a continuation file.Fix committed to svn 8755
This would not affect Send to Location in anyway.
Merged to trunk@8756.
Try 3.2.7-svn8757 or later:
vassalengine.sourceforge.net/builds/
–
J.
Thus spake Benkyo:
Excellent, thanks for taking the time to hear me out and get it fixed.
Now if only there were a way to get that fix in 3.2.5. I suppose I’ll
just have to hope the problems I’ve had with 3.2.6 go away in versions
3.2.7 onwards…
We don’t make changes to released versions, as that defeats the purpose
of versioning. If you’re still having problems with 3.2.7 dev builds,
please let us know what those problems are.
–
J.