how to define movement limitation from specific terrain

Hi there

for my traditional WG’s module… (héroic fantasy)
I dont find solutions to implement an easy way to get information about some terrain limitation. 'I Used Hexagonal Grid
EX Forest Half movement speed, cavalerie unable to charge , reducing range for missile to 1 Hexa range etc…
I need only a way to dysplay those informations, not interact with pieces !
and if possible a simple way (please not to manualy implement all data for each Hex !
Something (perhaps) like a unique color layers for each kinf of limitation ?

Thanks a lot
Sorry for my English poor writing, French Guy !

I’m not an expert on hex-grid games, but the basic idea is…

  • You can create pieces that are hex-shaped using the irregular shape trait.
  • You can have these pieces be “invisible” or “mostly invisible” (by filling the image with transparent color or mostly transparent color). By “mostly invisible” I mean if you wanted to have a little tiny symbol or something so that you could see it is there.
  • Add a “does not stack” trait to the piece, and set it to not move, but allow it to be selected.
  • Hopefully you gave your map a “Game Piece Layers” property list. Give these types of pieces a Marker named “Layer” and set to the very lowest level of priority (e.g. “Map”).
  • Now you have an “invisible piece” that goes on a hex, but it is selectable, so if it is clicked on it will highlight and can have a “right click menu” of commands.
  • Define all these properties of your pieces in the “Global Prototypes”, so e.g. you’d have a “Forest” terrain type. Then you can use At-Start stacks to place “Forest” in every hex that is supposed to have it (slightly a pain… yeah I know, we’ve all been there).

I remember one module that has invisible-but-selectable Hex Grid pieces – Empire of the Sun. It uses them for some of the objective/control hexes. It’s a big complicated module, but it’s one I can think of off the top of my head where you could find an example of something that works.

Hope that gets you started…


If you want to get more complicated, I do have a custom java module that replaces the Vassal HexGrid with a TerrainHexGrid. It allows 4 types of Terrain to be defined on the map using a paint and click visual interface:-

  • Hex Terrain defines the primary terrain allocated to the hex. e.g. clear, forest, mountains
  • Edge Terrain allows hex edges to be allocated a single terrain type. e.g. crest, stream, river, riverBridge
  • ‘Tag’ Terrain allows arbitrary tagged values to be associated with a hex. e.g. isFort=true/false, elevation=1/2/3/4, vehiclesAllowed=yes/no
  • Line terrain allows you define a terrain type connecting the hex center to the center of a hex edge. eg. track, road, highway, railway.

Edge and Line terrain can only be referenced and used by custom Java code. However, Hex and Tag terrain expose their values as pseudo Global Properties within the specific hex. So any unit can reference {CurrentTerrain} (or $CurrentTerrain$ in the old money) to find the name of the terrain it is currently in, or {elevation} to find the value of the elevation tag defined within that hex.

This code has limitations and idiosyncrasies, primarily that you can only define one TerrainHexGrid per map that covers the whole map, you cannot define TerrainHexGrids within zones that are smaller than the map. It also does not deal well if you change the map image and try and stretch/move the terrain to fit the new image. The terrain painter is also a little finicky and I can offer no documentation and little support :slight_smile: However, I could be convinced to publish this and write a few notes on how to install it in a module.

Other than that, I have used it in all my modules with very few problems, it is very stable and I do actively maintain it.

BUT your module is then forever linked to this custom, non standard, non VASSAL code. Think long and hard before going down this rabbit hole! I am happy to provide the source, but it is provided as-is and I do not have the time to maintain modules that use this code other than my own.



Thanks a lot for your answer !
I will try the solution of brent first cause the idea to put as many “unit” as different type of terain fears me a bit !

I will answer you when I’ve tried the two solution !
best reggard,


Hello Brent,

Thanks for this answer !

Looks Great, Those two functions are cool enough !!

Not a problem for now, my code is very very simple ! I dont use Zone (i didnt understand well how to use it :astonished: )

What does it look like I’s a java class that you have to import in the module ? I can try as it comes, it’s still better than nothing, but of course with some explanatin it’s beter… Ltes talk about this

Great !


Why !

Of course !

Can we talk about this a bit more deeper ?
I’m confined in Paris and have some time for such test and explration/

Thanks a lot
Hope everything fine For you (and you too Brian)
take care