Enabling movement trail shown for me and my opponent by default

Vassal neophyte here.

I played some PBEM games using the PanzerBlitz/Panzer leader module and they worked wonder.

I am now trying to play “Rostov 41” and noticed that the movement trail is not enabled by default for the counters.
The most unfortunate thing though is, that if I manually enable it counter-by-counter, then when I send the log file to my opponent, he won’t see the trail anyways.

I tried to edit the mod by adding the “Movement Trail” feature to one counter and I had it working by also setting these options:

Doing that for each counter would be a bloody pain though.
Is there a simple, fast way to tell Vassal to enable the movement trail for all pieces, for both players?
I tried editing the buildFile.xml but failed.

Thanks for any help!

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:

Screenshot 2023-04-13 at 4.50.47 PM

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.

Jim Hunter.

1 Like

Wow… Jim, thank you very much for your insightful response. It is exceptionally detailed and clear!

The only issue I keep having unfortunately is… should I repeat those steps above for each one single counter, is that true? I mean, disconnecting the toggle key and configuring the three commands.

If that is the case, that definitely sounds as a tremendous chore lol

The only issue I keep having unfortunately is… should I repeat those steps above for each one single counter, is that true? I mean, disconnecting the toggle key and configuring the three commands.

The steps that I described are the complete solution. Nothing needs to be repeated for each counter, since all combat unit game piece counters already reference the “unit” Prototype in their definitions. For example:

Referencing a Prototype in a game piece definition is functionally identical to having all of the traits defined in that prototype included within the game piece definition, in the same order as they are defined in the prototype. Since every game piece apparently references the “unit” prototype, and since you modified the Movement Trail trait defined within that prototype, your changes will affect every game piece. That is the purpose of the Prototype trait - it allows you to define in one place a common set of traits which can be replicated in many places by simply referencing that prototype. If that common set of traits ever needs to be modified, the change need only be made to the prototype definition but the effect will apply to all units referencing that prototype.

I have since discovered that all German game pieces seem to reference the “Ger-Unit” prototype in addition to the “unit” prototype. Similarly, all Russian pieces reference the “Rus-Unit” prototype. I suspect (but haven’t verified) that if you moved the Movement Trail trait out of the common “unit” prototype into the two side-specific prototypes, and then modified each of those traits to use different colored lines, this would result in each side’s movement trails being of a different color.

One more thing - I forgot to confirm that you should probably check the Trails visibility synchronized for all players checkbox in the Movement Trail trait definition.

Jim Hunter.

Oh! Thanks. I definitely missed that detail. I can’t thank you enough!

I finally found the time to get back into this, and I unfortunately still need help.
Before digging into the commands, I just wanted to check if my modifications were applied. Like, changing the color of the trail, or the Menu command string name.

The odd thing is, those don’t get apply.

I checked everywhere in the mod to see if for some reason Movement Trail is overridden in other prototypes, but I couldn’t. So I really am puzzled. What could the reason of this behavour be?

Shifting the trait up did indeed solved the loading warning, fwiw, and I also checked that I did saved correctly my modifications (I unzipped the .vmod file I generated in Vassal, and I could find my modified string in it).

Thank you again for your outstanding help.

Wait, I think I got it! It is not working for the units already on the map, but it does for the counters that I drag from their space!!

It is not working for the units already on the map, but it does for the counters that I drag from their space!!

Hmm, the changes I described worked in the module that I saved. Specifically, when I start Scenario 1, move a piece which started on the map, then pressed “Show Trails”, the movement trail appeared as expected. Did you perhaps forget to “Refresh Predefined Setups”?

I don’t know what you mean by “it does (work) for the counters that I drag from their space”. Do you mean counters that you drag onto the map from the “Counters” Game Piece Palette?


1 Like

Yes, Jim, I meant that, and yes as well, I did not refresh the setups or the vlog I loaded, hence the reason why. I apologize for having not read that carefully enough as well - the fact is, that it all looked overwhelming at a glance.

Now the modifications are done - some of them, I actually, at least temporarily, left the CTRL-T default and I am trying to publish the updated mod.

Many thanks!