Independent, Non-linear UNDOs

[Charles McLellan]

There was a great deal of discussion on ConsimWorld's forum regarding making non-linear UNDOs. I have a module, imported from ADC2, which I wish to modify to accomplish this. Here is what I want to do:

I want VASSAL to remember the starting location of say 200 units on a map. I want be able to move all or some of the 200 pieces in any order to any ending location on that map.

The critical feature is that want to be able to go back and easily return say the 26th piece moved (called it "26") to its start location at any time during the move. (Don't worry about the legality or effect upon any other unit, just return 26 to its starting location.) Now I want to be able to move 26 again to a new location retaining 26's the memory of its original starting location but discarding any memory of 26's first move and the location to which it initially moved. I now want VASSAL to remember 26's new ending location.

I want to repeatedly do that to any other piece or all pieces that moved or may move during the turn. Maybe move one unit back and forth several times. In the end, I want VASSAL to remember just the starting and final ending location of all 200 pieces.

I would also like VASSAL NOT to put those lines and dots all over the map – no lines and no dots. And, I would like VASSAL to NOT make a log file thing that shows all moves and UNDOs, just notes and die rolls. It would be ideal if upon instruction, VASSAL would list, as the logfile, the beginning and ending of units, but nothing else. That could be done before adding any notes or die rolls.

That way we could move an impulse (there are two impulses per Player-Turn), list the starting and ending location of all units, add notes, roll dice, implement results (some small moves and removal of units), start a new impulse second move (again remembering only the new starting and ending location of units of this impulse), list these new starting and ending locations, add notes, roll dice, implement results, save the whole logfile and transmit it to an opponent for his turn.

Now, from playing VASSAL I can surmise that VASSAL currently remembers the starting location of all 200 pieces. I know this because whether I open a log file or a saved game, all the pieces are shown in their original locations. OK, VASSAL is part way there.

I asked for help from Joel Koepp and Tim McCarron couple of weeks ago but they have not been able to respond.

Can anyone here point me in the direction that I want to go.

I am not current in Java. I only knew it back in the mid-1990's (Java 1.0). I guess that I will need to catch up with almost 20 years of progress.

Thanks to any body who is willing to help.

[uckelman]

Thus spake Charles McLellan:
>
> I asked for help from Joel Koepp and Tim McCarron couple of weeks ago
> but they have not been able to respond.

Joel responded:

http://talk.consimworld.com/WebX?14@@.ee6f15c/7153

So did Tim:

http://talk.consimworld.com/WebX?14@@.ee6f15c/7154

Tim described a solution for you which you could use now in VASSAL 3.2
for everything except the special log file.

I described the sort of thing we'll do for VASSAL 4:

http://talk.consimworld.com/WebX?14@@.ee6f15c/7114
http://talk.consimworld.com/WebX?14@@.ee6f15c/7163
http://talk.consimworld.com/WebX?14@@.ee6f15c/7186

I have no intention to add a new file type to VASSAL 3.2 this late in
its lifetime. I do not want to sink more development time into
something we are already planing to replace.

--
J.

[Charles McLellan]

What I was referring to was an e-mail sent to Joel and Tim subsequent to that discussion on ConsimWorld. I created a module and was asking for more detailed guidance in modifying that module to accomplish what they indicated was possible. I was not asking to modify VASSAL anything; just the module.

What I was asking for was their guidance or direction into the areas that I must learn in order to make the changes that they were referring to in those posts. If you wish, I can forward to you that e-mail to both Joel and Tim.

[JoelCFC25]

I'm here and reading, but I'm up to my eyeballs in a major module project right now. When I get a chance I'll revisit these posts and upload a small proof-of-concept module for you to review.

EDIT: Sorry, I just now see that you sent me an email. The email address I have listed on Consimworld is not one I check often--I only use that one for websites that require me to supply an email address but where I don't want the site hassling me with "offers" at my primary email. Consimworld doesn't seem to do that, so I should probably change it.

[uckelman]

Thus spake Charles McLellan:
> What I was referring to was an e-mail sent to Joel and Tim subsequent to
> that discussion on ConsimWorld. I created a module and was asking for
> more detailed guidance in modifying that module to accomplish what they
> indicated was possible. I was not asking to modify VASSAL anything; just
> the module.

Ah, ok. I hadn't realized there had been more to the discussion. I
don't have anything I'd like to add w/r/t/ module design. Best of
luck with your module.

--
J.

[Tim M]

Charles,

Please see attached demo module inside the attached zip file. This does exactly what you want to do (within reason excluding all your logfile stuff - I dont control that). It takes approximately 2 minutes to create (or add into your module which will be the case for you)

How it works (simplified):
When the pieces move 2 commands become available: "Send back to start location" and "Finalize move".

You only use "Finalize move" when you know you are done moving the piece and will not be sending it back to its start position so it can reset the pieces' new start position for the "next movement turn" of the game as it where.

How to add to your module (in general):

examine the demo fully. The key things you want to do is make a prototype exactly like the one I have and add this new prototype to all your pieces you wish to have this functionality. Also add the autostart GKC at the bottom of the tree like I have and make sure in the map dialog you have the last field set to the same as mine

Thats all there is to it

[Charles McLellan]

Tim, that demo is doing exactly what we have been asking for. Thank you. Now I'll try to copy that into the module that I have for The Russian Campaign.

I have some instructions from Joel. I don't know if it is the same thing that Tim's demo does, but I'll find out as I edit the module.

I further know now that when we say we want VASSAL to do something, you understand we want to change the big VASSAL. We don't want to change the big VASSAL, we just want VASSAL to be able to do something different in the module or modules that we are concerned with.

Thanks to all three of you guys.

[Charles McLellan]

Not sure what "autostart GKC" means. Let me stumble around for a few days to see if I can copy all the right stuff over to my module. I just try to make a few pieces work at first until I am sure that I am on the right track. Then I am going to redo the ADC2 module a bit and import that as the final work.

I''ll get back to you all when I am totally frustrated!

[dsdhornet]

Not 100% on this, but regarding the logfile.

I believe that Vassal doesn't just remember the starting position in the game save or logfile. It also relists the states of any affected piece or variable after every action. Hence by hitting the UNDO action, it doesn't have to work things in reverse (which would be buggy), it just moves affected pieces back to the previous state. When logging, it simply adds the new states. By hitting UNDO, you are not 'UNDOing' the log action, but adding a new state or action corresponding to the post UNDO of an action. This is vital because otherwise someone could sit there and undo and redo dice rolls until they got a favorable result, and their opponent in a play-by-email game would be none the wiser.

One thing you might be able to do:

a. Add a trigger which moves every piece back to the "starting location" while storing final location, clearing move trails, etc.
b. Add a second trigger which moves every piece to final location (and possibly clears starting location) while enabling move trails.

1. When the impulse starts, move all your pieces.
2. When done, trigger the move back to "starting location" (all pieces should be as they were at beginning)
3. Start logging.
4. Trigger move to end location. All pieces will jump to end location.
5. Roll dice, etc.
6. End log.
7. Repeat.

The only issue is that you would need 2 log files per move (one for each impulse) so that you can skip logging the move part. I would strongly recommend using move trails, as trying to figure out and verify 200 simultaneous piece moves based on just beginning and end position sounds incredibly difficult. Alternatively, you could just start the log after moving your pieces (and skip the back and forth thing), so that when the log is opened, the pieces will already be in post-move position.

Remember also, if you actually played a board game in person, your opponent would be watching you make each of 200 moves (and moving them back if you changed your mind, if that was even allowed...in many games once you let go of the piece and start moving another, you can't take something back). If in-person you would use a screen, that's the same as only sending the final layout.

[Charles McLellan]

What Tim McCarron's Demo does works fine. There is NO Logfile and NO movement trail. Any of the pieces move, and when directed, move back to start. That is exactly what we want. I am still trying to figure out how that works.

The only thing that would be better is a single command that finalizes ALL pieces at the same time rather than requiring each piece's move to be finalized independently.

The movements trails are NOT useful and only obscure movement of other pieces. For example, take say 50 pieces and move them back and forth over the same relatively small region. You end with a massive web that hides everything. So, NO movement trails please.

The Logfile itself is NOT wanted. We just want to be able to move the pieces back and forth in any random order. We are only interested in the start and final ending locations of the piece. We do not care what has happen to any individual piece between the time it starts and ends its move.

So, your procedure is fine providing that in "1," the undo moves can be made in a non-linear manner and no movement trails or Logfiles are produced.

Logging beginning with "3" and movement trails in "4" are acceptable.

Actually, each side has only about 100 pieces and with losses, that total number is rarely reached. With relatively low movement factors, it is generally not difficult to keep tabs on all units just by knowing their beginning and ending positions. There is a game engine that does this now for us, but it is 20 years old and showing aging signs. The hard thing to understand is why no system today can emulate its performance.

This is an old game from the 70s. Game rules at that time rarely stated anything regarding once you removed your hand, you could not go back and redo a move. Further, much play was conducted in Play By Mail -- real stamped mail. In those plays, forms were exchanged which only listed beginning and ending locations. You were not shown the path of movement or any reconsiderations of a move before the final position. Maybe you are not that old -- I am. (Although I was not a Play By Mail player.)

[Tim M]

A single command to finalize pieces can be done too Charles.

I didn't do it that way for a reason though. If the reset to finalize is only doing say 10 to 30 pieces it would be fine. However from what I understand you are talking about handling 200 pieces and having a single (what we call a global key command) key to reset all those pieces at once would bring your module to a virtual standstill and you might even think it has stopped working and crashed because it will take so long to process every single piece and reset them all at the same time

I hope that makes sense?

[Charles McLellan]

Tim, I use 200 pieces to represent about the total number of pieces in the game. Usually there is less than 50 pieces moving at an impulse. So, the single finalize would work perfectly.

Of course, I even been able to duplicate what you did. I cannot seem to find out how to add something to the left side of those windows. Every thing that I do errors. When I try to Import to the Available Traits in the ReturnToStart [Definition] in the Game Piece Prototype Definitions, all I seem to be able to do is get a Custom Class Error. The Help list doesn't show those Current Traits that your Demo has and I can't seem to find a way to get them added. I am missing something!

[JoelCFC25]

I cannot seem to find out how to add something to the left side of those windows. Every thing that I do errors. When I try to Import to the Available Traits in the ReturnToStart [Definition] in the Game Piece Prototype Definitions, all I seem to be able to do is get a Custom Class Error. The Help list doesn't show those Current Traits that your Demo has and I can't seem to find a way to get them added. I am missing something!

This sounds like a misunderstanding of how to edit a game piece. When editing a Prototype or an individual game piece, the "Available Traits" pane on the left shows you the list of traits that can be added to your Prototype or piece--you aren't meant to be adding things to the list on the left. You want to be choosing from the list of items on the left and then clicking the "Add ->" button in the middle area that separates the two panes to add it to "Current Traits" in the righthand pane. The "Import" button you tried to use is for very advanced users who are programming their own custom abilities in Java.

Think of the lefthand pane as the menu at a restaurant. The righthand pane is your dinner plate, where everything you've chosen from the menu ends up. Once you've added an item from the lefthand pane to the righthand pane, you can double-click this item in the righthand pane to access its properties and settings.

I recommend opening Tim's example module in the Editor at the same time as you have your module also open in the Editor, so you can position their respective windows side-by-side. For example, in the single Prototype definition he made, double-click "Dynamic Property - HasMoved" to see its details. In your module, try to add a new blank Dynamic Property to your piece (or Prototype, whichever you're trying to do). Mimic Tim's exactly. Do this for each of the 6 traits found in Tim's Prototype definition.

Does that start to make sense? You can watch the addition of traits to a piece demonstrated visually in Joel Toppen's Youtube video here at approximately the 3 minute 45 second mark: http://www.youtube.com/watch?v=NXmUDTMJzM0

[Charles McLellan]

Naturally, that is what I did -- opened side by side demo and actual modules in the edit mode. However, the left pane of my module does not contain the same items as the right side of Tim's demo module. Therefore, I cannot change the right pane of my module to echo Tim's.

I concluded that there needed to be some imported Java files to my module's left pane in order for me to transfer to my module's right pane the same data as contained in Tim's demo.

[JoelCFC25]

However, the left pane of my module does not contain the same items as the right side of Tim's demo module. Therefore, I cannot change the right pane of my module to echo Tim's.

It does, and you can. Perhaps you are expecting to see a 100% character-for-character match of Tim's traits available on the left to be selected: e.g., "Dynamic Property - StartXLocation".

When viewing the traits in Tim's prototype definition, ignore all the text including and to the right of the dash. So in the example above, the key information is simply "Dynamic Property". That is the name of the trait to scroll down and find in the lefthand pane's list and add to the righthand pane. Only after you subsequently double-click on it to edit its properties will it acquire the extra text (which is simply read from each trait's Description box).

There are only 4 traits required to be added from the lefthand pane (one of them is used 3 times):

Send to Location
Dynamic Property (this one will be added 3 times)
Trigger Action
Restrict Commands

Only after you add these and then double-click each one to edit their properties and descriptions will you have an exact replica of Tim's prototype.