Updating saved scenarios

[tbyrne]

On 1/23/08, Joel Uckelman wrote:

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.

I think it would be good exposed, so you could be sure of which piece
you were editing (as far as an updater would go). If there’s going to
be something other than the name that really identifies a piece, I
think module developers will want to know it. I would. I could
quickly find it in the buildFile for example.

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.

The reason I would shy away from a hidden piece palette is that it
makes more sense to organize the pieces in the module where they will
eventually go. I think I’d go nuts if I needed to define the traits
of a label in one place, and then define the location of the label in
a second place. If it doesn’t have that restriction, I can create an
at-start stack, and then define the piece directly there. Same with
defining cards in a deck.

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.

This would be a welcome direction, I think.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[rk1]

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.

Preserving those IDs in the palette is going to be difficult if people are copy/pasting pieces from drop-down menus into tabs, etc. Even a simple copy/paste into the same container raises a problem of what to do with the global ID of the original slot.

I personally feel that the updater has to be interactive to really be effective. It can only make a best guess of which piece should replace a given piece in the saved game, and will have to prompt the user to confirm. Fortunately, the updater can remember the user’s selection and always map those piece types to one another after the original prompt.

rk

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Here’s my take on a new updater.

Preserving those IDs in the palette is going to be difficult if people are copy/pasting pieces from drop-down menus into tabs, etc. Even a simple copy/paste into the same container raises a problem of what to do with the global ID of the original slot.

I like the idea of PieceSlot ID’s a lot. I don’t think this will really be a problem. I don’t think PieceSlots should share ID’s. If you create a new PieceSlot, then it gets a new ID. End of Story.

A Cut followed by a Paste would copy the ID, but a Paste not preceded by a Cut would copy the Piece, but generate a new ID.

I agree with displaying the PieceSlot ID’s in the PieceDefiner and perhaps exposing it with a $PieceId$ property, but I don’t see any reason at all to allow PieceSlot ID’s to be manually changed. If there are 15 identical pieces in a Deck, and they have 15 different PieceSlot ID’s, it really doesn’t matter - an updater will still work perfectly.

BTW, as well as PieceSlot’s in GamePiece Palettes and At-Start Stacks and CardSlots’s in Decks, pieces can also be created from the Piece Definitions stored in Place Marker and Replace counter traits. The updater needs to these as well.

The big problem with ID’s I see is how do you ensure ID’s in extensions are unique? Include the Internal Extension name in the ID? Change the internal name of the extension and the updater is blown.

The online updater I wrote is conceptually pretty straight-forward:

Process each GamePiece in play in turn:

a) Locate the Definition in the current module that was probably used to create it. This may not be possible if the module has changed enough.

b) Create a new GamePiece from the Definition

c) Process each trait in the new GamePiece and try and find a matching trait in the old Gamepiece based on getType (i.e. with all the same properties). If a match is found, then copy the State from the old piece to the new piece (This handles updating which layer is currently showing etc.)

d) Replace the old piece with the new piece.[/list]

Item B is the what we are discussing. Given a GamePiece on a Map, we need to find the ‘best’ definition that can be used to recreate it. I think Unique Id’s for PieceSlots saved into BasicPiece at piece creation time will work most of the time for most people for most modules.

For compatibility, we can include a backup scheme where if a GamePiece does not have an ID, then we use a scheme similiar to that which I use now:

• Find all candidate PieceSlots where the Name in the BasicPiece is the same as that in the BasicPiece of our target piece. Hopefully there will be only one

• Rank each candidate on similiarity to our target by comparing trait’s between the two.

• Choose one to use to update.

Ultimately, there will be GamePieces that cannot be updated because the module has changed too much. Basically, that’s tough. If a Module is going to be seriously hacked about, then there has to be an understanding that the ability to update saved games will be limited. Even so, I think PieceSlot ID’s (maintained accross cut/paste) will still work most of the time.

I would see this Update available as an option on the main VASSAL menu to update the current game, or on an Editor menu to update a Batch of games in a directory.

[Brent_Easton]

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.

I don’t see that it is necessary to look at the old original module at all. That just makes life difficult. What if we are a player who does not have the old module? We know what the “old state” of the pieces is, we just look at the pieces on the board - they are our “old state”.

The Updater I wrote works extremely well for the 10 modules I have built just by looking at the current pieces and the current module.

But then, I am careful to give every GamePiece a unique BasicPiece name which makes it easy.

[uckelman]

Thus spake “Brent Easton”:

I don’t see that it is necessary to look at the old original module at all. T
hat just makes life difficult. What if we are a player who does not have the
old module? We know what the “old state” of the pieces is, we just look at th
e pieces on the board - they are our “old state”.

Hmm. Yes, on reflection, I agree. All you should need is the ID in the
old setup to match with IDs in the new module.

So:

for (GamePiece gp : the old setup/save) {
look up gp.id in the new module
replace gp with GamePiece having that id in the new module
otherwise complain if no such id exists in new module
}

In the case of there being no matching id, I think the only thing
we can do is warn the user and leave that piece as-is. I have little
faith in our ability to figure out what the behavior the user desires
in such situations.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

In the case of there being no matching id, I think the only thing
we can do is warn the user and leave that piece as-is. I have little
faith in our ability to figure out what the behavior the user desires
in such situations.

I agree for default behaviour, but I would like to see an option to turn on a ‘best guess’ option (with suitable warnings) that uses a similiar (improved!) algorithm to my current refresh process. It will allow us to convert pre gp.id saved games - It really works quite well in most situations.

When the first gp.id version of VASSAL is released, every module on being edited for the first time will automatically get gp.id’s generated. We can then use this module to update a non-gp.id saved game and add the gp.id’s to all of the pieces.

[uckelman]

Thus spake “Brent Easton”:

I like the idea of PieceSlot ID’s a lot. I don’t think this will really be a
problem. I don’t think PieceSlots should share ID’s. If you create a new Piec
eSlot, then it gets a new ID. End of Story.

A Cut followed by a Paste would copy the ID, but a Paste not preceded by a Cu
t would copy the Piece, but generate a new ID.

Yes.

The big problem with ID’s I see is how do you ensure ID’s in extensions are u
nique? Include the Internal Extension name in the ID? Change the internal nam
e of the extension and the updater is blown.

Same idea as with IDs, but applied to extensions. The purpose of assigning
IDs to anything is that they decouple identity information from any other
(potentially changeable) attribute. E.g., the problem of matching pieces
based on their names is that maybe the whole purpose the update was to
fix piece names. With an ID—one that serves no purpose other than as
an ID—you never face this problem. (This is, not incidentally, why I
don’t like the idea of exposing IDs, because that introduces the danger
that someone will rely on them for something beyond conveying type
identity. We’ve all seen how module designers tend to find ways of using
things which we’d never considered… I don’t want to be experiencing this
problem all over again when that happens sometime down the road.)

To answer your question: Give extensions IDs too, and let them act as
namespaces for the piece IDs. So, you have “42”, and “BoffoExtensionID:42”
or whatever, which distinguishes them.

It’s not hard to generate UUIDs in such a way that the probability of
two extensions being assigned the same one during the expected life of
the universe is vanishingly near to zero, so we could use something
like that to create extension namespace IDs.

For compatibility, we can include a backup scheme where if a GamePiece does n
ot have an ID, then we use a scheme similiar to that which I use now:

• Find all candidate PieceSlots where the Name in the BasicPiece is the same
  as that in the BasicPiece of our target piece. Hopefully there will be only
  one

• Rank each candidate on similiarity to our target by comparing trait’s betw
  een the two.

• Choose one to use to update.

This makes me nervous. I’d rather have it make me a list of what it couldn’t
match by ID and let me handle those—or at least give me the option to do
so.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[tbyrne]

I’m very happy this discussion is taking place. Good call on Place Marker and Replace defined pieces.

Brent, your design sounds good to me. And particularly not needing to bring the old version of the module into play is certainly preferred. I tend to agree with Joel on leaving pieces alone rather than making guesses when IDs do not find a match. But I think as long as it is a option that can be switched on or off everyone will be happy.

In addition to converting a single game save, or batch of selected game saves, I think it would be useful to have an option to update all referenced predefined scenarios inside a module. If possible, it would save the trouble of extracting all the saved games, converting them, and adding them back in.

[rk1]

The Updater I wrote works extremely well for the 10 modules I have built just by looking at the current pieces and the current module.

But then, I am careful to give every GamePiece a unique BasicPiece name which makes it easy.

If your Updater works well, could we just swap it in as is?

rk

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

*********** REPLY SEPARATOR ***********

On 24/01/2008 at 4:40 PM Rodney Kinney wrote:

The Updater I wrote works extremely well for the 10 modules I have built
just by looking at the current pieces and the current module.

But then, I am careful to give every GamePiece a unique BasicPiece name
which makes it easy.

If your Updater works well, could we just swap it in as is?

No, I don’t consider it ready yet. It works great on some modules, it really suck on others where the module designer has not worried about unique BasicPiece names, or where the BasicPiece names have been ‘fixed’.

This is exactly where the Global PieceSlot ID would make it a no-brainer, and I really don’t think it is that difficult to implement.

With improvement, I would consider my current code as suitable as the backup for converting saved games that do not include gpid’s.

I am going to have a play with this. If I can get something happening quick, I would like to get the generation and storage of gpid’s into 3.1.

Joel, I don’t really have time to play with flexdock for some time - would you be interested in taking that over?

Brent.

---

Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

I am going to have a play with this. If I can get something happening quick,
I would like to get the generation and storage of gpid’s into 3.1.

Hooray!

Joel, I don’t really have time to play with flexdock for some time - would yo
u be interested in taking that over?

I’m interested, but what I’m interested in doing far outstrips the time
I have to do it in. Maybe a more important question is what people want
me to work on next.

What I had queued up was this (not including bug fixes, which I don’t
really schedule):

1. splashless/wizardless VASSAL (30% done, might finish over weekend)
2. logging improvement RFEs (0% done, a few weeks work)
3. dice server RFEs (70% done, a week’s work?)
4. investigate JOGL and build a demo (0% done, who knows how long)

I’d like #1-#3 to be ready for 3.2.0. It’s possible that #1 would be ready
for 3.1.0 if I don’t run into any problems and people approve of it.

I want to finish #1 before starting anything new, but work with Flexdock
work could cut in line if there’s stronger desire for it than for #2 or
#3.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

I am going to have a play with this. If I can get something happening quick, I would like to get the generation and storage of gpid’s into 3.1.

And it is happening. I made a lot of progress today and basically have gpid’s being created, saved in the module and in generated pieces. Still need to do Place Marker, Replace and handle Extensions, hope to finish it off over the next few days. Will then target an improved updater for 3.2.

[Brent_Easton]

Joel, Rodney,

A couple of commits in swampwallaby-latest:

2926: Generate and save GamePieceId’s (gpids)
2927: Refactor Map.getAllMaps() to return Collection instead of Iterator (FIXME)

I’m hoping to get an initial version of the new updater working before the 3.1 cutoff that will use the gpid’s to do an update.

Brent.

[tbyrne]

@Brent Easton

I’m hoping to get an initial version of the new updater working before the 3.1 cutoff that will use the gpid’s to do an update.

Brent,

Will your implementation of the new updater preserve state information about pieces. Specifically, I’m referring to the scenario outlined in this thread:

vassalengine.org/forums/viewtopic.php?t=266

If a piece has a Mask trait, and in a saved game is masked by a specific side. If that piece gets updated in the module, will an update to the save preserve its masked state?

Which also prompts me to ask. If the sides are edited in a module (perhaps fixing a typo), will the game save updater be able to make those changes throughout a saved game?

[Brent_Easton]

Tim,

Will your implementation of the new updater preserve state information about pieces.

Given that it is able to determine that an old trait matches a new one, it is my intent that it copy over as much state information as possible.

I will need a lot of assistance to test this one!

Cheers,
Brent.

[Tim_M]

A question on the updater - forgive me if I missed answer to this. It sounds very promising

What happens if the update is performed on an old module that does not have the UID’s assigned? Will the updater assign them automatically as it encounters components that should have a UID?

[Brent_Easton]

Hi Tim,

*********** REPLY SEPARATOR ***********

On 30/01/2008 at 3:02 PM Tim M wrote:

A question on the updater - forgive me if I missed answer to this. It
sounds very promising

What happens if the update is performed on an old module that does not
have the UID’s assigned? Will the updater assign them automatically as it
encounters components that should have a UID?

Yes, that is the idea.

---

Brent Easton
Analyst/Programmer
University of Western Sydney
Email: b.easton@uws.edu.au

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[uckelman]

Thus spake “Brent Easton”:

Joel, Rodney,

A couple of commits in swampwallaby-latest:

2926: Generate and save GamePieceId’s (gpids)

I’ve merged this one.

Do you think GPIDSupport would be a better name for TopLevelComponent?
It would never occur to me to look there for that, with a name like
TopLevelComponent.

2927: Refactor Map.getAllMaps() to return Collection instead of Iterator
(FIXME)

Is changing the return type a good way to fix this? Doing so ensures
that any custom code which called Map.getAllMaps() is broken now.
The FIXME (which I put there) was intended to remind me to create a
different function which returns a Collection (or a List?) and then
deprecate getAllMaps()—probably I should have been more explicit about
that in the FIXME. I would have done it at the time instead of putting
a FIXME in, but I couldn’t think of a good name for the new function.

–
J.

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)

[Brent_Easton]

Hi Joel,

Do you think GPIDSupport would be a better name for TopLevelComponent?

Sure, feel free to change things like that. I guess I was thinking Form rather than Function. Potentially, there may one day be other not-gpid stuff that will be shared between GameModule and ModuleExension. If they both has the same parent class, I would have added a new parent instead.

Is changing the return type a good way to fix this? Doing so ensures
that any custom code which called Map.getAllMaps() is broken now.

Yes, of course, I should have thought of that of all people. Don’t worry about those fixes

[tar]

On Jan 31, 2008, at 3:01 PM, Joel Uckelman wrote:

2927: Refactor Map.getAllMaps() to return Collection instead
of Iterator
(FIXME)

Is changing the return type a good way to fix this? Doing so ensures
that any custom code which called Map.getAllMaps() is broken now.
The FIXME (which I put there) was intended to remind me to create a
different function which returns a Collection (or a List?) and then
deprecate getAllMaps()—probably I should have been more explicit
about
that in the FIXME. I would have done it at the time instead of putting
a FIXME in, but I couldn’t think of a good name for the new function.

Not a great name, but

getMapCollection()

---

Messages mailing list
Messages@forums.vassalengine.org
forums.vassalengine.org/mailman/ … engine.org

Post generated using Mail2Forum (mail2forum.com)