I am sorry that I insulted you. I was trying to seriously discuss the shortcomings of the saved game files, and I thought you were just trying to be funny at my expense. I seriously wanted you to list some benefits of the current design in hopes that you too would come to the same conclusions as I did: that it really doesn’t work that well.
The behavior of Vassal’s saved game files have troubled me and no doubt numerous other designers for years now. I have wasted a good deal of time trying to circumvent their restrictions, and I am pretty happy when I can avoid using them in module design. If it were not for at-start stacks, I doubt I would continue doing this.
When this topic appeared, most of us who rely on at-start stacks were quite alarmed, and I added a note that life would be much better if saved game files worked right. I don’t think the way save files work now benefits anyone.
For anyone who has followed along and is unclear still about what I am complaining about, I relate a real-life current story. I give up on the general discussion because I don’t think anything will change. This is for the players out there.
A couple weeks ago, I uploaded version 1 of a new module for Decision’s RAF Lion game. This is a solitaire game covering the battle of Britain. The campaign game can be rather long, so one can expect players to play a while, save, and come back to it later. It could last weeks or months. I am aware of several players who are doing just that.
A couple days ago, I discovered that I blundered with a single German ME109 fighter, which is on the reinforcements track. I misspelled a prototype reference. This means that the fighter is missing a large portion of its right-click menu, and it won’t respond to a global key command that returns it to base.
It was easy to fix. Change the spelling and create version 2. Upload it and announce that v2 corrects an error with an ME109 fighter. I believe the players would download v2 in expectation that they could continue their campaigns with the correction. They would be wrong.
The trouble is that Vassal stores too much information about pieces in the save game file, information that you would expect to be taken from the module. In my case, the save game file contains the bad prototype information for the fighter, and there is no way that the player or I can tell Vassal to use the right prototype. In fact, if he does the v2 download, then he is playing with v1 pieces in a v2 module. This means that the player who downloaded v2 for the fix is not fixing anything. My change was minor, but imagine if I changed the name of the dead pool map. What would happen when he right-clicked a v1 piece to the now non-existent dead pool? So my downloading v2 RAF had 2 effects for the player: (1) he did not get the fix and (2) he exposed his game to strange behavior, perhaps crashes.
There are ways that he can get around this, but I would have to explain it in a help file. His choices:
- Abandon his saved game and start over.
- Write down the location and states of all cards in the game. Abandon the game, start over, and move all cards and pieces to locations/states as he recorded. (I have done this.)
- I build a special module version with an exposed piece palette that contains the single corrected ME109. The player grabs a replacement off the palette and hides the bad one. (I’ve done this one too.) This is the odd instance where v1 and v2 pieces coexist in the same game.
- Try to use the updater tool to create a new save game file. Be aware that it is not intuitive, you might accidentally overwrite your original, and I have never had it create a correct file in all the times (years) that I’ve tried using it, so you need to meticulously double-check its work.
- Explain to the player WHY they have to do this at all.
Currently I have not uploaded v2, but when I do, I’ll tell them not to use it unless they start a new game.
You would expect the default behavior would be that vassal would attempt to update v1 pieces so they could live in the v2 world as it loaded the file, but this is not how it works. It believes that it is better for everyone that it keeps v1 pieces as-is no matter where it puts them.
If you have a module that allows you to choose a scenario, you should realize that each scenario is actually a save game file that is embedded inside the module. Considering what I’ve said, it should be apparent to you that we module makers end up re-creating those files seemingly countless times because each time we change a piece, we have to rebuild the files all over again. (When I was working on Liberty, I had the setup memorized.) This is why this discussion of at-start stacks is so important to us. We can build a scenario without having to use a file.
So in the future, think twice before you download that module update. You may not be getting what you think.
to remain