# Updating saved scenarios **URL:** \ **Category:** Module Design\ **Created:** [January 22, 2008, 7:26pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164 "2008-01-22T19:26:46Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 22, 2008, 7:26pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/1 "2008-01-22T19:26:46Z")
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. 1. 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). 2. It didn’t seem to effect the saved game. 3. It didn’t seem to effect the game that was loaded (that is, the text label was not on any of the blue cards). Confused… Does someone know how to do this? ---
**Author:** ![Tim\_M](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tim_m/32/2_2.png) [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)\ **Post date:** [January 22, 2008, 8:08pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/2 "2008-01-22T20:08:57Z")
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 tbyrne [messages@forums.vassalengine.org](mailto:messages@forums.vassalengine.org) wrote: > [@](#): > > 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. > > 1. 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). > 2. It didn’t seem to effect the saved game. > 3. It didn’t seem to effect the game that was loaded (that is, the text label was not on any of the blue cards). > > Confused… Does someone know how to do this? > > * * * > > Messages mailing list > [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) > [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 22, 2008, 8:15pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/3 "2008-01-22T20:15:07Z")
Thus spake Timothy Mccarron: > [@](#): > > All I can say about using the updater is I had to read the documentation seve > ral times and run it a few times till it finally clicked in my head what to d > o and now I dont remember offhand. For me, I decided to just can using it alt > ogether and do it the old fashion way manually because I didn’t find it very > intuitive. Not the answer you were hoping for 🙂 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. – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 22, 2008, 8:21pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/4 "2008-01-22T20:21:13Z")
On 1/22/08, Timothy Mccarron [timothy.mccarron@sbcglobal.net](mailto:timothy.mccarron@sbcglobal.net) wrote: > [@](#): > > 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 🙂 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. On 1/22/08, Joel Uckelman [uckelman@nomic.net](mailto:uckelman@nomic.net) wrote: > [@](#): > > 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. 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. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Brent\_Easton](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/brent_easton/32/10_2.png) [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)\ **Post date:** [January 22, 2008, 9:19pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/5 "2008-01-22T21:19:22Z")
I do have a stand-alone saved game updater that I use in all my modules. It adds a hideable ‘Refresh’ button to the toolbar. Basically, you click it and it refreshes every counter currently on the board with a new version from the Game Piece palette with the same name. It works pretty well, but is not perfect. If my plugin code goes in, I might release it as a Global Extension. Brent. ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 22, 2008, 9:24pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/6 "2008-01-22T21:24:50Z")
On 1/22/08, Brent Easton [messages@forums.vassalengine.org](mailto:messages@forums.vassalengine.org) wrote: > [@](#): > > I do have a stand-alone saved game updater that I use in all my modules. It adds a hideable ‘Refresh’ button to the toolbar. > > Basically, you click it and it refreshes every counter currently on the board with a new version from the Game Piece palette with the same name. > > It works pretty well, but is not perfect. If my plugin code goes in, I might release it as a Global Extension. > > Brent. 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. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Brent\_Easton](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/brent_easton/32/10_2.png) [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)\ **Post date:** [January 22, 2008, 9:57pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/7 "2008-01-22T21:57:04Z")
> [@](#): > > What about pieces that don’t exists on 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? Brent. ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 22, 2008, 10:10pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/8 "2008-01-22T22:10:08Z")
On 1/22/08, Brent Easton [messages@forums.vassalengine.org](mailto:messages@forums.vassalengine.org) wrote: > [@](#): > > 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. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Brent\_Easton](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/brent_easton/32/10_2.png) [@Brent\_Easton](https://forum.vassalengine.org/u/Brent_Easton)\ **Post date:** [January 22, 2008, 10:49pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/9 "2008-01-22T22:49:32Z")
> [@](#): > > 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. Good point. I will amend to search Decks also if the piece cannot be found on a palette. ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 23, 2008, 12:51pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/10 "2008-01-23T12:51:23Z")
On Jan 22, 2008, at 4:49 PM, “Brent Easton” \<[messages@forums.vassalengine.org](mailto:messages@forums.vassalengine.org) > [@](#): > > wrote: > [@](#): > > > [@](#): > > > > 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. > > Good point. I will amend to search Decks also if the piece cannot be > found on a 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? * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![bsmith](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/bsmith/32/1_2.png) [@bsmith](https://forum.vassalengine.org/u/bsmith)\ **Post date:** [January 23, 2008, 2:54pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/11 "2008-01-23T14:54:59Z")
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. ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 23, 2008, 3:30pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/12 "2008-01-23T15:30:40Z")
Thus spake “bsmith”: > [@](#): > > 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 t > ried it many times without success, I’m curious to know if anyone has managed > to use it successfully… ever. I think I used it successfully once. The problem was that I wasn’t certain it worked, and so I ended up redoing it all in a text editor anyway. – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![Tim\_M](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tim_m/32/2_2.png) [@Tim\_M](https://forum.vassalengine.org/u/Tim_M)\ **Post date:** [January 23, 2008, 3:51pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/13 "2008-01-23T15:51:58Z")
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 Joel Uckelman [uckelman@nomic.net](mailto:uckelman@nomic.net) wrote: > [@](#): > > Thus spake “bsmith”: > > > [@](#): > > > > 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 t > > ried it many times without success, I’m curious to know if anyone has managed > > to use it successfully… ever. > > I think I used it successfully once. The problem was that I wasn’t > certain it worked, and so I ended up redoing it all in a text editor > anyway. > > – > J. > > * * * > > Messages mailing list > [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) > [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 23, 2008, 4:09pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/14 "2008-01-23T16:09:52Z")
Thus spake Timothy Mccarron: > [@](#): > > I have used it successfully quite a bit - my problem was because of its idios > yncrisy in looking for matching names in palette or next best thing etc… I h > ad 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 thi > ngs and can’t remember every little thing I changed, be it name, piece locati > on 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. – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 23, 2008, 6:44pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/15 "2008-01-23T18:44:04Z")
On 1/23/08, Joel Uckelman [uckelman@nomic.net](mailto:uckelman@nomic.net) wrote: > [@](#): > > 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. > > – > J. 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). * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 23, 2008, 7:14pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/16 "2008-01-23T19:14:59Z")
Thus spake “Tim Byrne”: > [@](#): > > 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? – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 23, 2008, 7:58pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/17 "2008-01-23T19:58:33Z")
On 1/23/08, Joel Uckelman [uckelman@nomic.net](mailto:uckelman@nomic.net) wrote: > [@](#): > > Thus spake “Tim Byrne”: > > > [@](#): > > > > 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. OK, I’m sure that probably wasn’t very clear… * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 23, 2008, 8:30pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/18 "2008-01-23T20:30:18Z")
Thus spake “Tim Byrne”: > [@](#): > > 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 was ingoring those for simplicity. Pieces defined elsewhere should also be given IDs. > [@](#): > > 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. 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. > [@](#): > > 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. Yes, that’s what I was imagining. > [@](#): > > 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. What’s the point of building a second hash? I’d check whether they match on the first pass. > [@](#): > > 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. 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. – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![tbyrne](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/tbyrne/32/4_2.png) [@tbyrne](https://forum.vassalengine.org/u/tbyrne)\ **Post date:** [January 23, 2008, 9:07pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/19 "2008-01-23T21:07:28Z")
On 1/23/08, Joel Uckelman wrote: > [@](#): > > Thus spake “Tim Byrne”: > > > [@](#): > > > > 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 was ingoring those for simplicity. Pieces defined elsewhere should > also be given IDs. Gotcha > [@](#): > > > [@](#): > > > > 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. > > 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, 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. > [@](#): > > > [@](#): > > > > 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. > > Yes, that’s what I was imagining. > > > [@](#): > > > > 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. > > What’s the point of building a second hash? I’d check whether they match > on the first pass. 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. > [@](#): > > > [@](#): > > > > 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. > > 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. 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. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) ---
**Author:** ![uckelman](https://forum.vassalengine.org/user_avatar/forum.vassalengine.org/uckelman/32/10020_2.png) [@uckelman](https://forum.vassalengine.org/u/uckelman)\ **Post date:** [January 23, 2008, 9:39pm UTC](https://forum.vassalengine.org/t/updating-saved-scenarios/164/20 "2008-01-23T21:39:36Z")
Thus spake “Tim Byrne”: > [@](#): > > 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. 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. > [@](#): > > > [@](#): > > > > What’s the point of building a second hash? I’d check whether they match > > on the first pass. > > 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. Hmm. I’ll have think about this. > [@](#): > > 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 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. > [@](#): > > 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. That’s basically what I’m proposing with IDs, I think. – J. * * * Messages mailing list [Messages@forums.vassalengine.org](mailto:Messages@forums.vassalengine.org) [forums.vassalengine.org/mailman/ … engine.org](http://forums.vassalengine.org/mailman/listinfo/messages_forums.vassalengine.org) Post generated using Mail2Forum ([mail2forum.com](http://www.mail2forum.com)) [Next page](https://forum.vassalengine.org/t/updating-saved-scenarios/164.md?page=2)