Placing counters on counters

I am designing a game and accompanying Vassal module. The game is played on a plain game board with a hexagonal grid overlay. To represent a terrain over which the counters (representing military units) move, I wish to place hexagonal terrain tiles. When the units battle, they require the placement of small circular markers on their surface to indicate morale level, etc.

I have created the map board, designed the military units in GIMP and inserted them into the module. The circular markers were likewise produced in GIMP and inserted in the module. Now comes my problem. I can place the terrain tiles and military unit counters on to the mapboard but, when I try to place a circular counter on to a military unit, it snaps to a point just to the bottom left of the counter - I assume on a part of the counter’s background. This background seems to be part of the canvas on which the counter was designed in GIMP. I have made this background transparent in GIMP but this has no effect - the map board shows through but the circular counter still snaps to an apparent hotspot. The hexagonal counters stack on one another without a problem and can be moved over the map board. This circular counters

Can anybody tell me how to resolve this issue - either by appropriate steps within the Vassal module or by taking some action in GIMP whilst creating the counters? Or is there something at work here that requires a completely different approach?


If you want these circular status indicators on your units, I would advise against making them pieces of their own–this is going to cause a lot of potential headache and fussiness with stacking/unstacking.

Rather, make each one a Layer trait that can be toggled on or off. Then you can use the X/Y adjustments to position them where you want with respect to the unit’s counter.

Thanks, Joel. I’ll dive into the module editor and see if I can work out how to do that. Or is it covered on one of your tutorials - I find those very easy to understand?

I’ve sent you a BGG Geekmail about the same subject so, if you come across it, please ignore it. I appreciate your help.


I am not Joel Toppen, just FYI. The documentation of the Layer trait has all that you need.

Hi Joel:
Sorry about the name confusion and thanks for the response. I’ve been through JT’s Lesson 10 where he talks about Layer Traits and I’ve come away totally confused. So I then went to the link you provided and am even more confused. I guess it’s me but the subject seems to offer a wider range of facilities than I need and I’m having trouble identifying which facility I actually need. Normally when I have this difficulty with instructions, I try to find someone who already understands the subject and can take me through it step by step. But that is awkward when I’m in the UK and the experts are in the USA, so my question is are you willing to persevere with me? Maybe I shouldn’t take up time & space on the forum for this purpose so please tell me if that’s the case.

I’ll persevere and try to untangle my brain but, if your brief doesn’t include personal tuition, is there anyone else I could approach for a clarification if I need one - after making the effort, of course?


I’ve been looking at the manual and am now wondering if I have misunderstood a basic concept. The circular status indicators are, in the board game (about Napoleonic manoeuvre & combat), chits that are placed beside a brigade to indicate how many Command Points its brigadier can dispose of. They are used to adjust dice rolls that affect morale, disorder, etc., and, at the start of each turn, a commander receives a set number of CPs which are stacked beside his brigade. Each time he uses one during a turn, the chit is deleted (returned to stock). I wish to represent these actions in the module and I have tried to replicate what happens in the board game by creating small circular chits to represent the real chits.

I suspect this may be an error and that I have to put an image on the brigade counter (representing the circular “chit”) which is a layer trait of that counter and not a physical component. Does that sound right?


I wouldn’t say it’s an error, but consider some side effects of making these indicators full pieces in their own right (bear in mind I know nothing about the game in question, some of the following may not be pertinent at all):

If your game has stacking, and you are going to be using the mouse-over stack viewer, each of these status indicators will appear in that viewer as a standalone piece, rather than “locked” with the piece to which they belong. If you need to unstack a piece with one of these indicators from other pieces and move it somewhere, you get double the work–you have to unstack and move both the unit and its indicator. But maybe that’s not a big deal.

Admittedly there is a lot going on in the Layer trait configuration. An extremely minimal Layer employs just 3 parts–the Name of the Layer at the top (leave all the tickboxes below empty), then a name and keystroke assigned to “Activate Layer”, and finally an image assigned. Let’s say you chose “Toggle” and “CTRL T” for your Activation settings. The effect is to give your piece a right-click command “Toggle” that turns on the layer (displaying the image) and then turns it back off. You can use positive/negative numbers in the Offset box to control where in relation to the base piece this layer image displays.

Is this CP value fixed at a certain amount? Or can it vary depending on the turn? And does the number disappear all at once or is it “spent down” one by one until gone?

I guess not knowing the game must make it very difficult to follow my ramblings. The concept I have in mind is very simple but I am very much learning the Vassal language. Back in my youth, I did a little Basic programming but Vassal is way beyond anything I played with.

The game derives from a miniatures wargame. A block of soldiers (a rectangular brigade counter in the Vassal module) has a theoretical commander (brigadier). His abilities are represented by a small stack of Command Pts (CPs) which are tiddlywinks placed beside his miniature and which he spends to influence dice rolls when appropriate. Each game turn, he receives a fresh batch of tiddlywinks for that turn.

The game map (representing the wargame table) has a hex grid superimposed to regulate movement and combat. Terrain is represented by hexagonal tiles placed where required and the brigade pieces move across these tiles which can affect their movement and combat.

I want to replicate these effects in my Vassal module. The terrain tiles must be placeable on the module map and remain in place throughout the game. The brigade counters must be moveable across the entire map (including the terrain tiles) and engage in combat with enemy brigades. During the ensuing combat, I need to be able to delete CP counters one at a time and occasionally move them between brigadiers to represent support.

The concept of “Layer Traits” is something I am finding it hard to get my head around although I’m getting a glimmer from your description. I play a number of Vassal modules (e.g. Crown of Roses & Commands & Colors) so am familiar with the mouse-over stack viewer which I don’t think I’ll need in my game.

I don’t want to monopolise your time but, if it would be helpful, I could send a copy of my wargame rules and an example of how a turn of combat plays out. I’m sure, once I’ve cracked it, the programming will be clear but, right now, I’m somewhat in the dark. I do appreciate your help so far and would really like to overcome the problems. Thanks.


I had a sudden thought. If you could tell me where I set up the component to apply the Layer Traits to, I might be able to work out the logic of the process and save you a bit of time???


I’m attaching an extremely minimal module demonstrating some (but not all) of what you can do with Layer traits.

The green unit on the right shows the most basic “on/off” layer that activates and deactivates with the same command. All it’s doing is showing another image on top of the base unit image.

The orange unit on the left is more in line with what I personally would implement based on the description you provided. The Layer has multiple levels in it, each with its own image (varying number of CP). Instead of controlling the Layer directly, you actually have the user (unwittingly) manipulate a Dynamic Property to adjust the numerical value. The Layer is configured to essentially “listen” to the value of that property to know which image to display on top of the base unit image (or no image at all in the case where CP = 0, i.e. they are all gone).

Note that we’re jetting off to France for a week’s vacation tomorrow, so I will be unavailable until I return. I’ll try to remember to check back and see if any of this has helped.

Thank you, Joel, I’ve downloaded the file and will proceed to examine it as soon as I’ve finished this. I suspect I won’t have finished by the time you fly out but let’s hope it does the business. I do appreciate the trouble you are taking.

Which part of France are you visiting and is it your first time there? I have worked for two French companies in the perfume and toiletries industry (Rochas and L’Oreal) and was a frequent visitor back in the 70’s & 80’s. Have a great time and I hope the weather is kind.



Hope you did/are enjoy/ing your European trip. Your help has paid dividends - thank you! The suggestions you made have given me the ability to do what I want and taught me a number of related techniques to use for other effects.

I have progressed to being almost able to call the module ready for testing. To get to that point, however, there is one key issue I can’t crack. The first action in the game is for a player to place terrain hexagons on to the hexagonal map grid. I can do this and, once placed, can have them remain in position to allow counters to move over them without stacking with them. However, ideally, I would like to be able to snap the terrain tile to the centre of a grid position so that it doesn’t have to be painstakingly placed to coincide. After that, I don’t want any other game counters to snap to the grid - I want these to be locatable anywhere within a grid hex regardless of any terrain already there. Can you advise, please?

Finally (for now) is there some way of positioning text labels or Layers so that, when the counter to which they refer is rotated, they occupy the same position on the rotated counter as on the original?
Thanks again for all your trouble.


Regarding the hexes and game counters, if the game counters do not need to stack, add the Does not stack trait to them and check “ignore map grid when moving”.

I don’t have a good answer for your rotation question, but I have used cycling through layers as an alternative to Can Rotate. Each layer can be designed exactly how you want it, which gives you a bit more flexibility than simple rotation. No difference is apparent to the user when the layer up/down commands are “rotate left” “rotate right” etc., and for more complex rotation the layers can follow a Dynamic Property modified by Trigger Actions.

If you do need stacking for your game counters there is also a horrendously complex way to get the hex grid to snap to place using zones, global properties, triggers, and sendto traits, but hopefully you won’t need to resort to that.

Thanks for the response. I’ve been waiting for Joel to return from his holiday and have only been visiting the forum occasionally. The terrain markers do not need to stack but need to snap to the grid whilst the game pieces don’t need to stack and MUST NOT snap to the grid. I haven’t yet ventured into Layers and I’m trying to avoid opening up new cans of worms until I’ve exhausted other possibilities. I’m hoping I’ll hear from Joel soon.

I discovered the “Do Not Stack” property but it is not really of use in my case.

As mentioned above, the “Does not stack” trait with Select piece: normally, Move piece: normally, and the box ticked for ignoring the grid is the only way I know to do what you intend. You might use this in combination with the map-level feature called Game Piece Layers–not to be confused with the piece-level trait named Layer.

This regulates entire classes of pieces so that they all draw above/below other classes en masse. The documentation spells this out–seemed like it might be good if you have terrain and units entirely separate. But I don’t know if “terrain is always below units” is true for your game.

Having Text Labels that rotate with the piece seems like something that should be possible, but trait ordering will be vital here. I can’t remember offhand which way it has to be, but the Rotate trait might have to be above everything or below everything else–one way it should work, the other it won’t. Trial and error should sort it out.

I don’t understand why you think Do Not Stack won’t work. Just add it to your game pieces, check ignore map grid, and you have your solution, according to what you have told us.

If there is some reason you can’t do this that you haven’t mentioned, the other solution is this:
Add a Send To trait with a destination $CurrentZone$
Add a Trigger that triggers on the Map keystroke, and activates the Send To trait.

This is much simpler than the other method I had in mind when I wrote my earlier reply.

For the Module 'Age of Bismarck by FoW games.

When the Sardinian player controls most of Italy the “Kingdom of Italy” is formed. this makes the controlled provinces home country for the Sardinian player. I copied the map areas and colored the Green (Sardinian home area) color. I used ‘Does not stack’ and alt-Click to select & only move when selected. Also a 'Send to Location command to put it in the correct place. You could have a menu to go to each possible location.
I had to allow the piece to be removed, if the province was captured by another major power. otherwise I would have the piece selected to never be able to move.

I had to lower the resolution to get the picture to fit on the forum post.


If you do need stacking for your game counters there is also a horrendously complex way to get the hex grid to snap to place using zones, global properties, triggers, and sendto traits, but hopefully you won’t need to resort to that.