I’ve got a problem with vsav files in v3.5.7. The vsav file seems to remember what player roles were in use when the vsav file was created. Players are then not able to select those roles when the game is reloaded. (I found a similar question from back in June '08.)
Is there any way to prevent the active roles from being stored in the vsav? Is there any way to unlock the roles that are not available when the vsav is reloaded?
Does the problem still occur in 3.6.8?
Sadly, we are stuck with playing 3.5.7, due to the code changes we made to support a strict requirement for a private server. I have not had time (or funding) to roll my code changes into the 3.6.x version.
However, I will test against the 3.6.7 release that I have on my Mac and see if I can recreate the problem.
Are your changes available somewhere? I might be willing to help get you updated so you’re current, while V3 is still fresh in my mind. We’re very near to the end of V3 development, so the window for that is closing rapidly.
Yes, I see the same behavior in v3.6.7.
Open module in v3.6.7
Start new game off-line
Choose user name: White1
Choose password: white1
Start logging to file on desktop: test.log
Add a couple tokens to the board
Save game as: Desktop/test.vsav
Save log file
Exit game module
Relaunch game module
When Welcome splash screen appears, open the Preferences dialog and change Personal/User name and password to white2
Load saved game, select the Desktop/test.vsav
At the “join game as which side” prompt, the pulldown does not show White1 as an option. Choose White2
When map window opens, click the retire button
The Choose Side window says, “Your current side is White2”. Neither White1 nor White2 are available for selection.
My fork of the 3.5.7 branch is on GitHub. I’d actually submitted a merge request sometime last year. I’ll find it again for you.
I sent you a message on GitHub from the pull request (#16) to uckelman/vassal-old that was issued in Jan 2021 and subsequently closed.
I am confused. This sounds like the normal, correct behavior for VASSAL. You’ve claimed side “White1” with password “white1” and side “White2” with password “white2”. Your password is still “white2”. Why would expect to be able to switch back to “White1” without changing your password back to “white1”?
I agree. It looks like normal correct behavior to me too.
It might be normal, but it doesn’t feel correct to me. We have a number of different people participating in the game at different times. If they fail to “retire” properly when they leave the game their roles are forever blocked from reuse by other players. I’d be extremely grateful if someone can tell me how to recover those lost roles.
It’s normal and as best I can tell VASSAL has never not worked this way, but that’s different from saying it’s brilliantly designed and that everyone’s pleased with it–it’s widely misunderstood and has caused countless issues for users down the years. There is no feature in the user space to recover passwords embedded in saves/logs, but there is a process for extracting them that isn’t advertised for obvious reasons.
If it’s a team game and you have people cycling in and out, one idea could be to require a joining player to share their personal module password with all other members of the team so if they subsequently disappear without warning you would have a way of freeing up the side.
Surely the simplest solution is to require all players to use a blank password for this particular game?
I don’t think the OP understands how players are linked to sides or what role user names and passwords play in this.
OP: If your friend Charlie with password “codfish” chooses “Greece” as his player side, then Vassal links “codfish” to “Greece.” If Charlie exits without resigning, then you can recover if he tells you his password. In fact, you could resign for him by becoming “codfish” yourself, joining the game, resigning on his behalf, and saving.
I would not encourage blank passwords because that opens up a whole new can of worms. If we collected all the reported problems with people sharing the same password, we’d have enough material to fill an encyclopedia.
I think this is our solution. When we have a problem with a player+side (and we know the player’s password) I can use that password to log into the game and then I should see that I have assumed that player’s side. Then I retire from his side, which frees up the side for reuse.
Also, if you have a group of “regulars”, not all of which are playing in a given game, you might enlist one of them who is not in a given game as a password keeper. This person would keep the passwords from all players participating in a given game in which they themselves are not playing.
It would have to be a trustworthy person, of course, that every player agrees on.
The problem of players abandoning games and taking their passwords with them is an issue that has existed ever since games have been played by computer.