In a prototype, I have an “Out of Supply” layer. I want the Out of Supply marker to float over the ground unit that it is marking (so that if I mouse over the hex the ground unit is in, I see both the ground unit and the Out of Supply marker). All attempts I have tried so far, have the Out of Supply marker effectively replacing the ground unit the marker is sitting on.
now, I could just have an Out of Supply marker not as a prototype, and simply add the marker to the counter manually. however, it seems like a prototype would be much more efficient for this.
No, my Out of Supply (OOS) marker is not transparent. I realize that the OOS is sitting right on top of the ground unit, making it look like the OOS marker has replaced the ground unit. I want the OOS marker to be treated like any other ground unit or marker - so I can see both the groud unit and the OOS marker when I mouse over the stack.
The underneath when highlighted flag comes close, but I want it to float over the ground unit.
Then you don’t want it to be a layer but its own unique piece.
You can have the other counter call the OOS piece by using the Place Marker
trait to put it on top
Alternatively, if the OOS must be on a layer, and you want to see it and the
piece it belongs to with the MOS viewer, you can offset the layer by the
piece width or height
Place Marker looks like it would work, but I cant seem to add one in a prototype. I hit the “add” button but nothing happens.
When you say offset the layer, do you mean through the “underneath when highlighted” flag ? I tried that and it sort of works although it still gets placed under the ground unit.
Place marker is definitely what you want to do here. However, there appears to be a bug in VASSAL that does not permit you to add that trait to prototype definitions. We’ll see if we can work that out.
I can add a “place Marker” to a prototype to the 3.0.15 VASSAL release, but not using the 3282 build. Maybe its something that just crept into this build.
That would be correct. I haven’t tested it, but my guess would be that if you loaded a gamed saved with 3.0.15 in 3282, everything would be fine. Brent left a message on the developers list that he would look into it.
I think the immediate fix would be to add the prototype in 3.0.15, save the module, and then edit it again in the latest version. That might work. The other possibility is that if you do that, the developer release may not let you add any more traits to the prototype. I’m not sure what it would do, but it’s worth a shot if you’re really stuck on using the developers’ release.
However, the simplest thing you could do is use 3.0.15 entirely until the bug is fixed.
The problem with using layers, is that the layers are images drawn on top of the image used for the counter – they’re not separate counters, so unless the layer has transparency, you will not see what is underneath. Some modules use nice non-rectangular layers that obscure only part of the counter. But if your layer really is the size of a counter, what you need is an “add marker” attribute which simply puts a separate marker on top of the target.
Use the latest test builds to make your mod and help developers bug hunting
at a cost of suffering possible setbacks and function issues to ideal module
development or
Use the latest stable release 3.0.17 and not worry about bug / function
issues or
Use a stable build for your one issue then jump to a test build and hope you
don’t encounter any other problems.
I for one prefer the first option as I don’t mind rearranging modules over
and over again as things change. YMMV
What I was going to suggest was to edit the buildFile in the archive directly. Not the easiest solution. Or he could wait a couple of days as you suggest