Forget about editing buildFile.xml; I think only brave experts attempt that, and rarely.
You can implement Movement Trails using the normal editing process. I took a quick look at the Rostov 41 module. The first thing I noticed is this error message that is emitted when you open the editor:
- Bad Data in Module: Source: Prototype Error: Movement Trail trait found above/inside a Can Rotate trait which could rotate it, and will probably not work properly… See the errorlog for more details.
This is an unrelated issue that can be easily fixed. The “unit” prototype contains a Movement Trail trait and a Can Rotate trait, but in a likely incorrect order.
I suggest moving the Can Rotate trait to be immediately above the Movement Trail trait. I confirmed this eliminates the error message, but I didn’t bother to test the rotate functionality. Again, this was an unrelated issue; now to get Movement Trails working…
It appears to me that the Movement Trail trait was added without being connected to anything much useful:
This trait allows you to define up to 4 key commands which will control trails on the game piece(s) that contain this trait (e.g. - all units with the “unit” prototype). The only command which is currently defined is the one simply called “Key command”, which is “connected to” the Ctrl+T “hot key”. As described in the Reference Manual, this command is used to toggle the current state of the movement trail for that unit. This used to be the only command that existed; this trait was later enhanced to include the TURN ON, TURN OFF and CLEAR TRAIL commands, which allow a much finer level of control.
I highly recommend leaving the toggle command unconnected (don’t define any command for it); it has been obsoleted by the three new commands. You should instead define a named command for each of those three commands, such as shown below:
Now that we’ve defined commands to Show, Hide and Clear movement trails, we need to define some way to send those commands to the game pieces. The usual way to do this is to define a module level Global Key Command (GKC) trait for each of those three commands (see Reference Manual).
This GKC trait is commonly used to define a toolbar button to send a command to game pieces. You need to define three buttons - one to send each of the newly defined commands (ShowTrails, HideTrails and ClearTrails). To add a module level GKC, right click the “Module” node at the very top of the editor “tree”, and select “Add Global Key Command”. At minimum, you need to define these two fields:
- The text to be displayed on the toolbar button is defined in the “Button text” box.
- The command to be sent to the pieces is entered in the “Named Command” box in the “Global Key Command” section.
I recommend that you also define these optional fields:
- The “Tooltip text” box specifies an explanatory description which will be displayed when the user hovers the mouse over the button.
- The “Report format” box specifies a log message to be emitted to the Chat Window.
As an example, here is the GKC to send the ShowTrails command:
As you define each new GKC, its corresponding button should appear on the toolbar, eventually looking like this:
You’ve now completed the minimum set of changes, but since the four scenarios of this module are implemented as “Predefined Setups”, you need to “freshen” those setups with your updated design before saving the module. Recent versions of vassal made this easy, by defining a “Refresh Predefined Setups” button as a “Tools” menu option. Selecting that option will pop up a window with checkboxes to allow you to fine tune that operation; leave those checkboxes unchanged and just press the “Run” button. After several seconds, you should see output like this in the Chat Window for each of your four setups:
- Updating Predefined Setup: Scen 2.1: Fritz on the Don ( Rostov Scenario 2-1.vsav)
- Loading Rostov Scenario 2-1.vsav …
- Loaded Rostov Scenario 2-1.vsav
- Collecting Counters
- 202 Counters found in game
- - 202 Counters collected
- - 0 Counters not collected - Not owned
- - 0 Counters not collected - Not visible
- -
- Refreshing Counters with Module version 1.30a
- - 202 Counters refreshed
- - 0 Counters could not be refreshed - Not found
- - 0 Counters could not be refreshed - Not on a map
- ----------
- - 0 Refreshed counters had no parent stack
- ----------
- ----------
Dismiss the popup window with the “Cancel” button.
Before saving your module, you should assign it a new version number, to avoid confusion with the released version. That version number is defined by double-clicking the [Module] node at the top of the tree, and entering it in the “Version number” box. I updated my version number to 1.30a, as shown below:
You can now save the module, but you should save it to a different file name than the original version. I saved mine as Rostov-41-1-30a.vmod. After saving your updated module, you can quit the editor.
To test these changes, open your new module and select a scenario. Movement trails are initially Off (or hidden). Move a couple of units around; you won’t see their trails until you press the newly defined Show Trails button. Trails will appear for the units you just moved, and for any other units that you then move. When you press Hide Trails, those trails will no longer be shown, but are still “remembered” by the module and will reappear again when you press Show Trails. To “erase” all existing movement trails (e.g. - at the end of a turn), press Clear Trails. All existing trails are forgotten and will disappear. Since trails are still turned On however, any newly moved units will have their trails shown.
Note that trails can also be cleared by pressing the “Mark all pieces on this map as not moved” toolbar button, which looks like this:
Since this button also clears the “Moved” label on all pieces, this is a more useful way to do end of turn cleanups.
This is a “bare bones” implementation of Movement Trails. There are several improvements which could be made. For example:
Most modules implement a separate Movement Trail trait for each side in the game, so that each side’s trails can be of a different color. To retro-fit that into Rostov '41 however would require breaking the “unit” prototype into two different prototypes (one for each side) and updating the prototype reference for each unit in the game.
Another enhancement is to define a module level Global Parameter to record the current state of movement trails (Showing or Hiding), for use by pieces which enter the map from another map window (e.g. a reinforcement chart). This is a bit more complicated, but I would direct anyone who is interested to refer to the Empire of the Sun module as an example.
The toolbar buttons can be made “prettier” by providing a graphical icon. Those buttons can also be easily bundled into a separate sub menu, to take up less space on the toolbar. Empire of the Sun is an example of how that is done.
Cheers,
Jim Hunter.
