Independent, Non-linear UNDOs

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.

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.)

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?

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!

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: youtube.com/watch?v=NXmUDTMJzM0

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.

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.

Yes, your are correct in that I was looking for an exact duplication. I will try what you are suggesting.

I think that I got the duplication done correctly. There were a few errors in my initial attempts, but now all the script seems to duplicate Tim’s.

Still, I have run into a problem. When I clicked a unit to return to start, it disappears.

Here is a sequence of screen shots showing what happens. I am not sure, but I think that the first entries in the Logfile were from a Save earlier in the process when I was tracking down errors in the copying. This test begins with test. Only two pieces are set to return to start at this time – the German 1st and 2nd Infantry Divisions at 0924.

In image 1, shows the initial positions of the divisions. In image 2, I move the 1st Division (remove due to attachment limit). Image 3 shows the right click of the 1st division. Image 4 shows the location after the “Return to start” is left clicked.

The unit still shows in the Search window and when that line in clicked, map shifts with the upper left corner of the map at the upper right of the monitor. Perhaps the unit is at 0,0 coordinate and unseen under that white portion of the screen where the Logfile scrolls.

The only difference I see in what I have and Tim’s demo is the grid labels. The demo module’s hexes are all numeric while the TRC’s modules all begin with “TRC4” followed by the numeric hex number.

What do you guys think? Should I redo the board so that all hexes are numeric?

By the way, I asked Tom Gregorio to look at Tim’s Demo. Tom said that on his system, Tim’s demo was exhibiting the same results as my changes to the TRC module. I do not know what computer or operating system Tom uses. Tim’s Demo works just fine on my system – Dell Inspiration computer using Windows 7 pro 32 bit with Java 7 Update 51 (build 1.7.0_51-b13).[attachment=1]Image4.png[/attachment]

The grid labeling doesn’t matter. The script does not depend on that - it works on internal absolute x,y positions.

What is happening is it is indeed returning the piece to the 0,0 position because these are the initial values you entered into the dynamic properties. What this means is you missed adding the autoexec gkc. Look at the bottom of my module tree. You need to add this feature too. Also this is not going to work on a previously saved game logfile. It must be a new game. the autoexec only runs on initial startup of a game/ created save file

sorry its called in the tree "Initialize pieces[Startup Global Key Command]

btw I will make an alternate version for you here shortly with a Global key to reset start positions so you dont have to do it individually on each piece

Ok,

Here’s the modified demo which instead of having to reset the new start position on each piece individually it is done from the toolbar instead. This is in line with your earlier wish. Keep in mind you only want to push the end movement button when you are absolutely sure you dont want to do anymore “move back to start” moves and are completely finished moving pieces until next turn

Tim

Actually, I did add that thing at the bottom of the tree. I’ll go back and check. I probably made a copying error.

There may be a bit of a delay. My computer is beset with problems just now – not of VASSAL’s origin. May take some time to straighten out. I am NOT leaving until this whole module is fixed.

I will have to import a new module. Not a major problem, but coping the Demo data again might take a little time.

Hi, Still have some printer problems, but I want to go on here.

I downloaded Demo2 and implemented the changes. A “End Movement” button shows on the top icon menu row. However, the units no longer carry the Return to Start with the right click. Something is wrong. I have checked and rechecked the settings. I believe everything is in order except it doesn’t work. I did notice that the " Change Value Control V" went from the top to the bottom.

Is there a limit to the number of traits that a piece can have? Maybe the trait list is too long.

Can’t remember how to load an image. download/file.php?mode=view&id=2341&sid=5b3eb89fb8ad34ec2b7[attachment=0]Image1.png[/attachment]72256899dde2c

Thus spake Charles McLellan:

Is there a limit to the number of traits that a piece can have? Maybe
the trait list is too long.

The GUI element which displays traits uses an array interally. Java
arrays are indexed using signed 4-byte integers, which means that you
cannot have an array in Java with more than 2^31 elements.

So, yes, there is a limit, but it’s almost certain that you are not
hitting it.


J.

OK, so I am no where near reaching the limit. I’ll do some more guessing.

If you still can’t find the problem, send me your mod as is and I’ll fix it up for you

In the process of writing all. Started well before this post. Will be done shortly. Missed some of the Java error information.

Problem: I have tried a number of times to reproduce the results achieved by Tim McCarron but have not been successful. I am attaching the module with which I have been working. I only set the Return to Start trait on two units, the 1st and 2nd German Infantry in hex TRC 0924.

The Return to Start option was not included on the list of traits displayed on the right click menu. Moving the units also did not bring the Return to Start option into the trait list.

Current Differences Between Models: The only intentional difference that I made in coping Tim’s work was substituting “TRC4a” for Tim’s “Map” in Game Piece Photo Definitions \ Return to Start \ Send to Location \ Return me back to where I came from \ Board.

Problems Encountered During Copying: On the first attempt to duplicate Tim’s work, I mistyped A “#” in the first position of “$CurrentlyY$” in the Game Piece Photo Definitions \ Return to Start \ Dynamic Property \ StartYLocation \ SetupInitialLocation \ New Value. A note identifying the error was displayed upon opening the module. I corrected the character in an edit of the module.

When first coping the "Reset the location [Global Key Command], the “Button Icon:” was “white” where Tim’s was “gray.” Selecting the default brought what appeared to be a small unit icon not from this module. Going then to “Select” brought an icon page off of my computer. I selected an icon, but nothing appeared. When I open the module, a report that the icon I had selected was not recognized by the module. I subsequently changed the image from “.ico” to “.png,” substituted the new image in the module image file and changed the “.ico” to “.png” in the module build file. That seemed to satisfy the module. On subsequent edits, the “white” reset button had changed to “gray” without any action on my part.

When saving the edit, the Save would not process. A “Java” window opened in the upper left of the monitor. I did not capture the information as to why. On a retry, a Save As… was forbidden in the location where the module was located (C:\ Program Files \ VASSAL \ mods) but allowed in a location under “C: \ Users \ Charles.” I saved there with a “TRC5” title. A VASSAL module with the edit changes was located at and subsequently loaded from that location.

After re-edits, I had problems saving and had to again Save As… This time as TRC6.vmod. This will be the attached module.

Attempts to Correct Results: I tried a couple of things in an attempt to duplicate Tim’s results:

I moved the “Initialize pieces” group up the tree to duplicate the position in Tim’s Demo2 module. Still didn’t bring “Return to Start” trait into menu. Returned the group back to the end position on the tree.

I changed the “TRC4a” “Board” to just “TRC” because the grid identification of a hex is for example “TRC4 0924”. It didn’t alter anything. I changed back.

Differences Between Modules: Differences that I note between the Deme2 and TRC4 modules that I didn’t change:

  1. Of course, the map is different and there are many more units with different images and more traits.
  2. Tim’s module does not produce a log file. Moving units in the TRC4v2 module does.
  3. Tim’s units do not show a movement path. Moving units in the TRC4v2 module do.
  4. Tim’s works; mine doesn’t.

Possible Problems Between Models: In the TRC6 module there is a extra line preceding Game Piece Photo Definitions \ Return to Start \ Dynamic Property in both the StartXLocation and StartYLocation properties. This line is “CTRL V” trait and it does appear on the trait list. I have not tired to remove or shift the trait yet.

Data: My computer is a Dell Inspiron with a Windows 7, SP1 32 bit operating system with an AMD Semprus Processor LE-1300 2.30 GHz and 3.0GB RAM, C: of 596 GB with 262 GB free. Java is 7 Up-date 55 (build 1.7.0_55-b14). VASSAL is 3.2.8. Internet is Internet Explorer 11.0.9600.17105, Update Version 11.0.7 (KB2964358).

Other Concerns: When I went to attach the TRC6.vmod from C: \ Users \ Charles it was not there. There was a TRC5.vmod which was an earlier module that required the use of TRC6.vmod as a Save As… as the TRC5.vmod caused some Java conflict when Save was attempted. I also notice that there are three “temxxx.zip” files two of which seem to be VASSAL modules in disguise and one a VASSAL build file. So, I am going to attach just the TRC4v2 module from C: \ Program Files \ VASSAL \ Modules here, then the other four files from C: \ Users \ Charles in subsequent attachments.

Let me know if you need any more information.

The file is too big, maximum allowed size is 256 KiB.

Guess I try some other ways to add the attachments.

Email the files to me direct to get around the file size. We’ll get this taken care of for you. You’ve got my email from before :slight_smile: