Design for Examining Supply Lines

I’m working on a module where I want to evaluate supply lines between units during certain events.
The map is constant and doesn’t change in terms of terrain. Supply lines are defined by roads or railroads that are connected between cities/towns.

This game has two sides and each side has to maintain supply to their side of the map (east/west basically).

A supply is good if a unit can trace a path through friendly (not enemy occupied) roads, rails, and cities or towns from itself to any nearby friendly city.

I can use “invisible” terrain markers to put something on the hexes where supply can be good.
I can use layers to show “supply good” in a color that is appropriate for the side that is checking supply.

I’m not sure where to go with it exactly and was wondering if anyone had any thoughts or recommendations. Thanks!

How are your map board “spaces” defined - hex grid, irregular grid, zones. Etc?

I just noticed you said hexes. Sorry for typing too soon.

What you are wanting to do is a difficult problem.

I have done some similar things by writing 1000’s of lines of custom Java code to record Terrain and then provide visuals based on that.

It was difficult to do in custom code and I think you will really struggle to implement something usable in base Vassal.

sobering. fair enough. let me run an idea past you to see if this might work.

the game uses a fairly simple concept for “in supply” e.g. a contiguous path of Road/Rail/City hexes from itself to a Supply Source and NO enemy units on that path

what I am thinking of doing is:

  1. use small or invisible terrain pieces on the map that have a layer trait where the terrain they occupy shows visually green highlight for road/rail/city and red highlight for anything else.
  2. depending on which side invokes “check supply”, have the terrain trigger on that GKC and look at their hex and if another unit is there and if so, ensure the layer trait becomes red if it is “not my side” or green if it “is my side”.
  3. at this point (for the side in question) the supply paths should all be visually green or red based on occupation by friendlies or not.
  4. highlight all “my side” units with a yellow border or badge
  5. the user can then visually check paths to see if any units have hexes between them and a supply source that are “not green”.
  6. each unit already has an “OoS” badge that can be toggled by a right click to indicate it’s status - not fully automated, but visually helpful i think…

Ok, providing a visual display based on hex ownership to make it easier for you to manually check supply should definitely be achievable.

I was thinking you are after some sort of checking that did the actual supply determination and reported it.

Your idea of the invisible/highlighting pieces is a good one.

I would drive it via toolbar buttons/multiaction buttons/menus etc, that send the appropriate GKC’s to your terrain pieces. Options might be. Allied/German/Off.

There are some new Sum and Count functions in the 3.7 beta, that allow a piece to find out close by pieces. Assuming you have a hex grid numbering set up that is reporting a unique LocationName for each hex, then the Terrain pieces can do something like

CountLocation("{Army==\"Russian\"}") to count the number of russian units in the same hex. Use this to set a Dynamic Property with a value that a Layer is following to set the appropriate colour.

1 Like

TL;DR: Automatic tracing of supply lines is not really possible, or at least highly impractical, with current VASSAL

Let’s assume a traditional hex’n’counter wargame.

To trace supply lines, the module and VASSAL must be aware of

  • all terrain and features of all hexes
  • all locations of all counters (units, installations, etc.)
  • “ownership” of all hexes - e.g., which factions unit last passed through or occupied a hex
  • possibly roads, railways, rivers, and such
  • possibly the movement factors (MF) of all units

Then, the module must be able to calculate a route from any given unit to a supply source (board edge, rail road leading to board edge, city, town, supply installation, and so on). This could involve tracing such a line that does not pass through enemy ZOC or similar. The most effective way to trace such a route would be to use an A* algorithm where the cost of of moving from one hex to another would depend on

  • Terrain and features, including roads, railways, etc.
  • Presence of enemy or friendly units or ZOC
  • The units MFs

Currently, VASSAL does not track a counters location - the only way to get the location of a counter is to ask it - that is, the module will have to query all counters where it is (LocationName) to check if a counter is in a given hex. One could possibly use the Board attribute Key Command to apply to all units ending movement on this map to record unit locations in some GlobalPropery

Also, VASSAL has no notion of the terrain or features of a hex. The module designer would have to encode that somehow. This is doable. For example, one can have a GlobalProperty called Woods which contains a list - say :A1:C5:F6:...:Z3: and CalculatedProperty InWoods as


Furthermore, when a faction moves a unit, VASSAL only records from which hex to which hex that unit moves, and does not record any intermittent hexes passed through. That means that control of a hex is not easily recorded by VASSAL, since VASSAL has no idea about which hexes a unit passed through.

Looking a head, how could VASSAL possibly accommodate this. Well, to me, the best option seems to be to create a number of call backs and better tracking of counter positions. For example.

  • A user selects a counter. This triggers VASSAL to try to calculate possible moves by that counter using an A* algorithm.
    • VASSAL asks the module for the MF cost of a counter to move from one hex to another. The request sent to the module will contain
      • which unit is moving so that the module can differentiate between for example mechanised or infantry movement
      • which hex is the unit moving from (not the original hex, but the current hex in the path traced),
        or possibly the full current candidate path
      • which other units are present in the candidate hex
    • It is up to the module to look up
      • terrain and features of the candidate and source hexes
      • MF of the moved unit
      • possible enemy ZOC in candidate hex
    • The module then reports back a “cost”, which could be the real MF cost or possibly just a 0 if the module can track the MFs spend (this part requires a bit of thinking)
    • The A* star algorithm then either accepts of rejects the current path
  • The A* start algorithm maps all possible paths until there is no more viable paths as determined by te module call-back
  • Once the paths are determined then they are displayed by VASSAL to the user which then can select between these paths (again, requires a bit of thought).
  • The selected path is then sent to the module which can then record ownership of the hexes the unit moves through.

A similar approach can be used for tracing supply lines or lines of sight, although there one would start from the target hex (or hexes) and work ones way backward toward the source counter.

Ideally, VASSAL would allow a module to record units on the map and which hex they are in and “user defined” properties - e.g.,

class Board 
    Hex getHex(column,row)
    List<Hex> getNeighbors(Hex)

class Hex
     List<Piece> getPieces()
     List<Property> getProperties()
     List<Property> getEdgeProperties(Edge)

User properties could then record ownership, terrain, features, roads (edges), etc.

With this in place, it would be possible to define modules that enforce game rules much easier than it currently is. For example, one could

  • query if pieces are really adjacent and thus can conduct combat
  • query offensive and defensive terrain and possible intermittent terrain
  • restrict movements to what the game allows
  • record owner ship
  • … and much more

To a large extent it hinges on VASSAL doing in far more call-backs to the module, using A* to present “movement” (or trace) options, and allowing for more module defined recording so that queries can be optimised.

Anyway, my 2¢


1 Like

i’m looking into a less costly way to give a visual outlook on supply, not an absolute one. I’m trying both Layer effects and AoEs. It’s pretty close and the game is fairly low complexity as supply goes - basically roads/rail between cities and it is blocked with enemy units on those hexes.

Appreciate the depth of your response. I’m thinking over how I can max out what the vassal base functionality will provide for now.

So far, having “terrain markers” on spaces that are supply capable (roads/rails) and then tracking (loosely) when units are sitting on those spaces (what side, what ID, how many, etc) is allowing me to show visually “red” for blocked and “green” for not blocked as well as highlighting the supply sources so that each side can do a “check supply” from their perspective. It’s kinda working, but I have some more stuff to investigate with regard to keeping better track of terrain that has multiple units on it so that I know when they ALL move off, not just the top one or a few.

I would not attempt to have the Terrain tiles ‘track’ the movements of the other pieces in real time. That’s just really hard, complex and prone to error.

Much easier is to have the Supply check always done fresh from a clean start each time. Then you just need two functions that will be the same for every tile:

  1. Reset
  2. Calculate and show my supply status now based on what units are sitting on me.

Then players can initiate a new supply check as needed which will reset all terrain pieces, then tell each one to check and show it’s own status.

Hi Brent - thanks for the advice. I have a set of buttons that let each “side” look at supply from their perspective. If Allies are looking at supply, the other buttons aren’t active. Same for Axis. and one reset to put things back in order and make sure the hexes are shaded correctly.

I was wondering what people’s thoughts were on examining stacks. Right now I am just using some props to track what pieces occupy a terrain (stacking is limited to 2, so it’s not too cumbersome), but is there something that let’s me look at a location to see what is there so I don’t have to maintain any record?

I have terrain pieces on the map simply register when a unit is on them and unregister when it leaves, but I agree it would be much simpler to look in the moment since I already have the mechanics for that at the UI level.


In v3.6, you can use the Sum and Count functions along with an expression that includes the condition && CurrentLocation == “CurrentLocation$” but I would not recommend using these, they are innefficient.

In v3.7, we are adding a new suite of very efficient functions to do the same thing, but better. In particular, the SumLocation and CountLocation functions will Sum a property or Count pieces that are have the same LocationName as the source piece and meet any conditions you need to check. So the Terrain piece will be able to do something like


to count the number if Russian pieces in the same hex.

I am currently in the process of final testing of these functions and a substantial update to the reference manual. Realistically, the release of v3.7 is a couple of months off, but if you are not in a hurry, you can start developing your module using the current 3.7 beta4 release which has some of the new functions (Many more to come plus some name changes in beta 5).

Your module will not be usable with v3.6, but will be usable as long as every one is using 3.7 beta or better.


1 Like

where I landed on this is something like this:

  1. terrain pieces (not many BTW) are notified when a unit moves ON to it - these are pre-populated in startup with the correct terrain type - i don’t really need this since I can just put terrain where supply can go, but I am thinking about also doing some movement stuff later

  2. the terrain then stores the side and type (only need side really, but just in case) and increments a stack counter (in this game enemy and friendly units are not supposed to occupy the same hex

  3. terrain pieces are notified when a unit moves OFF of it as well and then decrement the counter, etc

  4. I have ONE terrain piece (hidden) that listens for GKCs and sets a couple of GPs for reset

  5. menu has three buttons - one for axis, one for soviet, one for “reset”. When the user pokes either axis or soviet, it greys out itself and the other side button (axis/soviet) and only leave reset available. if axis, the terrain piece lights up red if a soviet piece(s) is sitting on it if soviet, vice versa. if a friendly unit is on terrain or terrain is empty, it lights up green (using AOEs).

It’s kinda brute force, but it does visually help identify collisions so you can see where supply might be in peril. I will also add Supply Source terrain markers and highlight those slightly differently so you can see where they exist more easily

looking forward to 3.7 :slight_smile:

I’ll be interested to see if this actually stays in sync. It depends on tracking every movement of every counter in every circumstance from every type of move including different trait movement types, undo, replace traits etc.