Hi, I can’t understand the functioning of the Place Marker trait.
If I choose to place one or more Markers (in this case small colored squares) ‘on top of stack’ or ‘above this piece’, they invariably appear in the bottom left corner of the piece. (Look to the green infantry) The horizontal or vertical offset values I set seem to make no difference at all.
If I choose ‘on bottom of stack’ or ‘below this piece’, then the Marker is positioned in the center of the hex and the piece appears right and above it, trespassing in the adjacent hex. Again the offset values don’t seem to make any difference:
There are multiple issues with Place Marker and offsets in the current version (and all previous versions) of VASSAL. Be patient; version 3.7.16 should have a fix. For details, see this issue: https://github.com/vassalengine/vassal/issues/13719, and the PR linked to it.
Offset won’t work - even after the fix - if the intention is that the small markers stack with the larger marker. Any offset within stacking range of the larger piece will be overridden by the “snap to grid” action.
You might consider putting the smaller markers into a different (higher) Game Piece Layer than the main counter and having them NOT snap to grid. I think this will work with the Place Marker offsets.
If you must still have those markers rotate with the main counter that will be more challenging.
If you want the Marker to rotate with the piece, there are 2 options: either make the marker a separate Layer within the piece, instead of a separate piece (the simpler option, and this will also solve the positioning problems); or make the piece a Mat and the Marker a Cargo.
Hi guys, great answers and lots of food for thought.
Unfortunately I can’t use layers since I am employing them to report step losses. I have a few questions:
Do you have any idea how I am to remove markers placed with the Place marker trait?
You might consider putting the smaller markers into a different (higher) than the main counter and having them NOT snap to grid — In order to have the smaller markers NOT snap to grid I should check the ‘Ignore grid when moving’ option in their ‘Does not stack’ trait. Is that correct?
or make the piece a Mat and the Marker a Cargo — In this option, each time I should place the smaller marker in the hex with the mat and then press the keystroke to attach it. Is that right?
Indeed, yes. Despite the name of this trait (a Vassal legacy), you will also find an option to allow the marker to retain Stacking ability, so select that as well if you want the markers stackable.
I’m not recommending or withdrawing my suggestion here, do consider the other possibilities suggested in the replies. Vassal provides a huge toolkit and there’s usually at least three ways to achieve an objective!
I was still thinking to the markers in ADC2 terms, as images appearing on the actual game pieces, rather than in terms of game pieces in their own right.
Whoa. Each unit has 8 steps and can have 10 markers stacked on it? That sounds ultra-fiddly and something I wouldn’t expect to see in a published game. My curiosity bursts. What game is this?
Hi Mark, I never thought of incorporating multiple layer traits. Actually, I can’t even envision how it might work. Can you direct me to a tutorial or any page of instructions?
I don’t know the game in question at all, but if a single piece is meant to have a bunch of visual indicators associated with it to reflect a variety of different statuses/effects, in my experience using Layers is dramatically simpler both from a design and user experience standpoint. Any time you’re using Place Markers to generate additional pieces you’re going to get into stacking and all the mess that entails–imagine a mouseover stack viewer going over 2 units stacked together each with 5 or 6 status “markers” implemented as standalone pieces. No thanks!
With multiple Layers you can arrange all the different indicators with XY offsets relative to the base piece exactly how you wish, control what draws above what, and get a tidy looking display in a mouseover zoom.
The manual states: “the Layer is drawn on top the traits that appear before it in the piece’s list of traits”.
If that is so, I might create a second layer above the one incorporating the images of the units and their strenght points. This second layer will include the visual indicators, which will automatically be positioned on top of the units drawn in the first (lower) layer.
I think what you are missing is that layer images, as long as they are PNGs or SVGs, can be transparent. Thus, you do not need to make all combinations of front/back and states as full images. A transparent image can be rendered on top of a base image.
In the above game, the counters are double-sided. The back-side seems to be an undisclosed state, while the front is the disclosed state
All these images, except undisclosed.png and disclosed.png should be have transparent background. Also, layers Entrenched to Strength should probably be defined in a Prototype.
But, perhaps a better option for some of these would be to attach a LabelTrait that will put a small “tab” next to the counter. For example, the Ammo state could be reflected by
LabelTrait
text="{Ammo}"
valign=bottom
halign=right
rotate=-90
...
DynamicPropertyTrait
command:
key: Ctrl-+
menu: Replenish ammo
expression: {Math.max(Ammo+1,2)}
command:
key: Cltr--
menu: Spend ammo
expression: {Math.min(Ammo-1,0)}
Property: Ammo
I know transparency, but your comprehensive post led me to realize how extensively it can be applied. Unfortunately, programming is a mystery to me. I will definitely experiment with the Vassal interface.
As a side thougth, I am overwhelmed by Vassal. I ask myself who needs such a convoluted tool to design game modules. I have an impression that its complexity becomes an end in itself, a gaming challenge to be mastered. Aide de Camp 2 allowed to craft excellent gamesets in such an unproblematic, straightforward fashion. Old good times…
Happily, no programming whatsoever is required to make a basic module. A learning curve definitely exists, though. Many recommend Joel Toppen’s YouTube series as a starting point.
As for the complexity being an end in itself, that’s just a silly allegation. The vast majority of modules are quite simple–just the maps and pieces and charts required to play and they leave it to the player to move stuff around. There is no strict need to dip into advanced things that VASSAL allows, but some choose to do it because they wish to give users a better experience.
If you wish to stick with authoring content for ADC2, there’s no harm in that. But the reality is that there’s an exceedingly small user community for it anymore. The market has basically decided its fate, and it’s no great surprise that whatever module creation benefits it has/had, very few people in the year 2025 are willing to pay actual money for Windows-only abandonware that looks terrible (because it doesn’t support any modern image file types), can’t do live real-time play, and has a host of other drawbacks.
There’s really no good reason to use a URL shortner when you can just make a link
Maybe I was unclear - what I meant to say is that transparency is what you can use to avoid the combinatorial problem. No one else seemed to have mentioned that, so I thought it was worth pointing out.
Sometimes, when people are deep in a tool, it is easy to forget how complicated it can seem for a beginner. That’s why I tried to be a tad more explicit.
It takes a bit to get used to for sure. Personally, I find the editor unmanagable and prefer to code things up instead.
VASSAL is by far more feature rich than any of the alternatives (CyberBoard, ZunTzu, Aide de Camp), with the possible exception of Tabletop Simulator. VASSAL also has the advantage that it is available for many platforms (again, with the exception of Tabletop Simulator).
Another thing that distinguished VASSAL from the competition is the ability to make modules reactive (again, with the exception of Tabletop Simulator - even though it seems it’s not much used). This comes down to the scripting engine of VASSAL (which uses Beanshell).
However, VASSAL does not mandate this, and one can easily make modules which are basically board’n’counters - as one would do in CyberBoard, ZunTzu, and Aide de Camp.
The first of these, BattleforMoscow.vmod has the board and counters, and simply allows you to move counters around on the board. Oh, and counters can be flipped to their reduced side and deleted from play. Pretty simple.
The second BattleForMoscow-ch-1.2.1.vmod does a lot more:
Keeps track of turns and phases through a turn interface
Battle markers
Automatic odds calculations, including terrain effects
Automatic battle results
Keeps track of replacement points used
…
This is possible by using the various functionality that VASSAL offers - such as piece traits, global commands, and of course, scripting. How much functionality a VASSAL module implements lies on a spectrum between (or even beyond) these two cases.
To my knowledge, most modules are closer to BattleforMoscow.vmod, and only a few are like BattleForMoscow-ch-1.2.1.vmod (most of the modules I’ve done are in the latter category).
The most “advanced” module is probably Advanced Squad Leader - so much so that it has it’s own web-site In that module, they put in even more functionality by adding custom code to augment or override existing VASSAL functionality as well as adding new functionality.
But, as I said above, VASSAL modules can be as simple as the author want. That said, I think there’s something to be said for modules that helps the user by implementing tedious calculations and bookkeeping and let them get straight to the action
