I never used many saved scenarios, but recently I started work on a module that’s going to require LOTS of them.
To prepare myself for the inevitable module updates, I tried using the game save updater. But, its not exactly making sense to me.
Here’s my simplified situation:
I have a Prototype called “Blue”
I have a Deck called “Cards”
“Cards” contains 10 pieces
All pieces are named “Blue Card”
All pieces only have the Prototype “Blue”
OK, now a game save or saved scenario is created (which from what I understands actually replaces the prototypes on the peices with the resolved traits).
Next, I create an update to the module, which adds a Text Label to the Prototype “Blue”. Now none of the “Blue Cards” in saved games, or saved scenarios have the text label.
I tried using the game save updater. First I exported the game piece data from the original module. Then I opened the new module (the one with the text label), imported the previously saved piece data, and selected my defunct saved game.
What happened next was it loaded the saved game, and prompted me to pick a side.
Is it supposed to start the game? I was hoping I could use this to update scenarios in batch (as I will likely have over 100 of them).
It didn’t seem to effect the saved game.
It didn’t seem to effect the game that was loaded (that is, the text label was not on any of the blue cards).
All I can say about using the updater is I had to read the documentation several times and run it a few times till it finally clicked in my head what to do and now I dont remember offhand. For me, I decided to just can using it altogether and do it the old fashion way manually because I didn’t find it very intuitive. Not the answer you were hoping for
It would make life so much easier if saved games were able to read off of the currently used build file and auto update on loading instead of going through these ‘recreation processes’ each time a module is updated
The updater is not presently one of the bright spots in VASSAL. I’ll
eventually work on that because it annoys me—but don’t let that
stop anyone who wants to take a crack at it first.
Crap! I’m desperately hoping someone will chime in with a fantastic
way this stuff can be handled. If I need to manually retouch over 100
saved scenarios every time I want to update a prototype for a new
feature, well… I just won’t.
I understand the reason that save files are not editable, but I wish
saved scenarios could be handled differently. If they were at least
as editable as the buildFile that would be a major improvement
(Although better readability and editability of the buildFile itself
needs some attention too).
I’d take a crack at the update, but I’m swamped with promised module
work at the moment.
This is interesting. What about pieces that don’t exists on the Game
Piece palette? As I understand the current save updater, it also only
works on pieces named in the Game Piece palette.
No, my routine works by searching all Game Piece Palettes for a matching piece. It does this by name, or if the name is blank, it makes an attempt to identify by the name of the image in the first level of the first Layer.
If a piece isn’t in a palette, where would I find a definition to use to update it?
Lets say a Deck is defined on a Board. That deck might have a Card
defined in it. I would hope an updater could look at the deck in the
new module to get updates for the card. But in this example, there
would not be a duplicate of the card in the piece palette.
The other case that I think is missing would be at-start-stacks. I
have several pieces acting as labels on maps, which all use a
prototype to define their look (only the text is different). But
updating this prototype won’t change all the labels in saved scenarios.
I think using piece palette, decks, and at-start-stacks would probably
cover most everything. Can that be added. And of course, can you
share your tool?
Yeah, this is probably the single biggest hole in module design right now; I’m glad somebody brought it up.
My question is, does the piece updater in Vassal 3.0.x work at all? I’ve tried it many times without success, I’m curious to know if anyone has managed to use it successfully… ever.
I have used it successfully quite a bit - my problem was because of its idiosyncrisy in looking for matching names in palette or next best thing etc… I had to go back and check everything it had done in my new saved game files to make sure everything was right because I take a rather long time updating things and can’t remember every little thing I changed, be it name, piece location etc… - hence why I stopped using it
Allow me to propose something which would make updating setups far, far
simpler in the future: Each piece type in palette should receive an ID
number (unique among all pieces in the palette), and when a piece of that
type is created, it should also receive that ID number. That information
would be sufficient to update setups and saves correctly EVERY TIME, and
it would make the updater a near trivial piece of code. All the updater
would need to do is iterate over the pieces in the saved game and chech
whether they match the piece in the palette with the same ID. If so,
they’re current; if not, they need to be replaced by a new piece.
This doesn’t help with the current state of things, but it will save
designers a lot of pain in the future if we implement it.
Go just a bit further. Every piece (regardless if it is defined in
the piece palette or not) gets and ID. This ID number is used for
update purposes. In addition, you should be able to edit/override the
assigned ID (for those times that it might make sense).
I don’t see how a per-piece ID would help with updating—how would you
be able to tell what to match it with if every piece had a unique id?
Am I misunderstanding what you’re proposing?
Most discussion about a scenario updater keeps the notion of using the
piece palette as the master list of pieces. A module can also define
pieces inside of decks, and at-start stacks. So I’m proposing that
those are included as well.
I could have a deck which has 15 identical cards, and they should all
be able to have the same “scenario update id” (SUI). I could also
have a piece defined in the piece palette with its own SUI. Then I
could have an at-start stack with 5 different pieces, each with their
own SUI.
The updater could work by querying every piece palette, deck, and
at-start stack in the original module, building a hash of SUI =>
piece definitions. This is used to determine the “old state” of the
pieces.
Then the updater could query every piece palette, deck, and at-start
stack in the updated module, building a hash of SUI => piece
definitions. Then it could loop over pieces found in a game save and
compare the original SUI definition with the one in the game save. If
it is the same (that is, it hasn’t been modified in some other way) it
gets replaced by the updated SUI definition. If it has changed in
some way it would be output in some type of exception report along
with other problems like SUIs that were not previously defined etc.
Any module designer would need to be aware of the caveat that only one
of the found definitions of a given SUI will be used (probably only
the first or last however its easiest to program). So in the case of
my 15 identical cards above, the module designer would need to ensure
that those 15 definitions are in fact identical because any one of
them might be used as replacements during scenario updates.
I was ingoring those for simplicity. Pieces defined elsewhere should
also be given IDs.
In this case, you’d need some way to set the ID. I guess that could
be done by adding a field to the BasicPiece trait. I’m unsure whether
the IDs should be exposed through the editor though—that might be
asking for trouble. I can imagine some terribly confusing behavior
if two different piece types end up with the same ID.
Yes, that’s what I was imagining.
What’s the point of building a second hash? I’d check whether they match
on the first pass.
Can you elaborate on why you want to have pieces with identical IDs
defined in the module? I can see why you’d want pieces with identical
IDs in a scenario or saved game, because there might be multiple
instances of some marker or something.
Yes, the way to introduce it to the editor interface needs to be
worked out, but I think a lot of module developers would like this
exposed.
I guess what I was trying to explain was building one hash of SUI =>
old definitions, and one hash of SUI => new definitions. Then going
over all SUIs within a game save, comparing the game save definition
with the old definition (looked up in the first hash). If they are
equivalent, replace it with the new definition (looked up in the
second hash). If not, it should report that it matched a SUI, but
that it didn’t match the old definition. I’m thinking this could
happen if a scenario modified the active layer, or change a text label
or something else which wouldn’t be captured by simply replacing the
piece with the new definition. Perhaps the error report could even
list out the differences between the old definition, and the one in
the game save.
Lets say I have a deck defined on the main map with 10 tokens. Lets
say the game only allows for 10 tokens, so I don’t want to define a
token in the piece palette so someone can generate more than 10
tokens. This would be an example of multiple identical definitions
within a module.
I guess if they all had different IDs the update still could work.
But someone it seems confusing to me because they are all supposed to
be identical.
As I’m thinking about it, it would be nice to have an ability to
create “soft links” of pieces within the module editor (not copies).
One “master” piece, similar to a prototype. Pieces which are linked
to the master piece couldn’t be edited separately, but were a separate
independent instance during a game. Changes to the master piece would
be reflected in all the links.
Could you give me some idea of what use it would be to expose IDs in
the editor? That I can’t think of any might be due to my limited
experience with module design.
Hmm. I’ll have think about this.
I wonder if it wouldn’t be better to handle this situation by having
a hidden piece palette, which you can see in the editor but not when
playing? Then you could just define one token and pull 10 copies out
of the hidden palette.
That’s basically what I’m proposing with IDs, I think.
