counter creation

The module I am working on has multiple sides (two minimum, but I want to set it up to allow for more as multi-faction fights can occur) all with identical counter sets. Having some programming experience I would like to reuse as much on the back end as I can, but from what I have been able to look up in the wiki and these forums I’m unclear on what the best approach for this would be.

I know one option is to just set up one side completely, then copy/paste it in however many times I need them to appear, changing them to be for different sides. I’m hoping there is a more … elegant … way of doing this.

Could you guys point me to either online reading or modules I can dissect to further my understanding on the issue?

Thank you!

On Sep 27, 2010, at 6:22 PM, krenshala wrote:

The module I am working on has multiple sides (two minimum, but I want
to set it up to allow for more as multi-faction fights can occur) all
with identical counter sets. Having some programming experience I
would
like to reuse as much on the back end as I can, but from what I have
been able to look up in the wiki and these forums I’m unclear on what
the best approach for this would be.

I know one option is to just set up one side completely, then copy/
paste
it in however many times I need them to appear, changing them to be
for
different sides. I’m hoping there is a more … elegant … way of
doing this.

Well, part of this depends on more details of what the counters look
like.

If there are only a few different types of otherwise identical
counters, then having a Game Piece Palette and drawing them as needed
works quite well. You only need to create one of each type of counter.

If the counters are standard Nato symbol counters, then there is a
tool for building the counters in the editor.

If your problem is more with the creation of lots of different
counters that only really differ in the background color, then there
may be a way to automate some of that counter creation. Scripting
your graphics program or using a command line tool like ImageMagick
would be one possibility.

With a bit more detail on what it is you want to reuse perhaps other
ideas will come up, or we could be more specific about how to go about
making this somewhat seamless.

Could you guys point me to either online reading or modules I can
dissect to further my understanding on the issue?

A more risky and radical solution would be to directly edit the build
file. This is not for the faint of heart, but since you have
programming experience, you might want to consider it. Make sure you
do this on a copy of the module, since messing up the build file can
destroy the ability to load and edit the module.

See vassalengine.org/wiki/Faq_mo … edit_it.3F

This is pretty much the situation I’m in. I’ve got about 30 counter types total, and each side has the same collection of counters to use with background color/side being the only difference between them (well, the only difference as far as Vassal is concerned, anyway).

Well, my original thinking, before I’d really done much in the way of figuring out how the counters work in Vassal, was to create a template that would pull the ship-class from the counter data and display it in the formatted manner, with the background selected based on the side that placed it – basically, so all sides pull from one counter list, but get individual counters. The more I look into it, the more unlikely that setup is looking without some serious effort (and probably Java programming). Since I’m more a graphics guy, whipping up a bunch of images in GIMP would be way faster for me despite it being what I was trying to avoid.

I remember looking at this briefly early this year, but didn’t really have time to read it. I’ll give it a shot now.

Thank you for the ideas. Feel free to throw more at me.

So, I’ve been thinking more on how I can have a single set of counters that when placed on the board indicate which side they belong to.

I thought at first that just using a Layer that displays a specific counter “background” image for each side would work … until I discovered that you can’t place the Layer trait higher on the list than Basic Peice. Thinking about it further, I decided to still try and use a Layer trait. Instead of a full background image, since it would hide the actual tile image, I thought I’d use an image that was mostly transparent instead.

Unfortunately, I’m not sure of the best way to tell the Layer trait which layer-image to use based on the owning player of the piece. Can the Property Name just use $playerSide$ = to have it display the desired layer for ?

No you can’t have a layer higher than a basic piece, but where does it say you need to have an image on the basic piece trait to create a counter? Why can’t you just create your counters out of layers only - its been done before, the basic piece just remains empty of image…

Nothing says I have to. Right now my Basic Piece image has a ship image and ship class designation on it, and the rest of the image is a transparency. I’m trying to have the piece show the correct “background” image for the side it belongs to, based on which side placed the piece onto the board (e.g., if the Red player puts it on the map I wanted the ship to have a red background, while it would show blue if the Blue team placed it). My goal is to not have one copy of each ship counter for each player side, but to instead have one copy of each ship counter shared by all sides, but marked to easily display which side it belongs to.

You missed what I was getting at, so I’ll try to explain differently, DON’T use the Basic Piece image for anything except for the Ship name. Move the ship images onto their own layer (all of them) - now you can control the background color layer and have it listed above the Ship Image layer in the trait tree thus making it appear to be behind your ship image. Allow the background color layer to be controlled by a dynamic property which changes on the fly based on who owns/places the ship (it will need to be set to a default color at first but thats ok - it will change as required when you pull it from the piece palette - how we handle that is a different story). This will fulfill your criteria in only needing one piece handling the bg color as opposed to duplicate pieces with different bg colors

While I caught some of what you were saying, it seems I did indeed miss some as well. This description helped out. I guess I’ll find out later this evening when I get home from work if my idea for how the layer tracks the player side will do what I want in addition to what I ask it to.

… Computers … a means of performing human error at inhuman speeds!

Well, as I expected, using playerSide as the value the Layer trait follows did not work as I wanted, but it does appear to be /very/ close.

At this point, I’m ignoring the fact that my layer images hide the content I want visible (the ship icon) and working on getting it to display the correct layer image based on which side placed it. So, to this end I created a Layer, told it to follow the value of “playerSide” and that it is always on, adding one layer for each player side (SpaceMaster => no image, Red, Blue and Gold with appropriate colored blank tiles (because I haven’t gotten around to making new graphics for this yet )).

I started the module, selected a side (Red) and placed a ship (an EX) on the map in hex 0503. I got the following error message:

[code]- bad Data in Module: EX [Layer - Side] - Number field contains a non-number followProperty[playerSide]=Red

• Red placed EX at 0503[/code]
  So, it recognizes the value I want it to track, but doesn’t display the correct image. Apparently Layers can only follow numeric values? So, does this mean I need to set something up that defines a dynamic property for each player side that assigns it a unique number, and then have the Layer trait check that property value? Seems a bit excessive to have to do that just to track a value the game already knows about …

An odd thing I noticed was that if I “Retire” and select a different side without removing the EX from the board, the module immediately throws the same error (- bad Data in Module … followProperty[playerSide]=Blue) but this time for the side I just joined. I’m not sure if it is trying to change the piece to a different side or something else happened. It kind of looks like playerSide is tracking what side /I/ am connected as, and not the side of the piece itself.

On a side note, the BasicPiece page of the wiki lists “PlayerSide” as the var storing the owning side for the piece, however, my module only lists the correct information if I use the var “playerSide” (no leading capital on “player”). I’d change it, but with my luck the capitalization would have changed in 3.1.15 to match what is in the wiki page now …

your getting close - you do have to translate to a numeric value. As I said previously this is another story Fortunately though I have a simple demo mod inside the attached zip file showing exactly how everything is done. Easy to follow - it assumes a module where there are 3 player sides named red, green, blue. Has one test piece. If you need more sides you just add a key control to the Owner Control DP, a level to the Owner Layer and an extra Trigger for each added side etc…

Just retire to test out each side and you will see it is tied to the playerSide

Forgot to add the correct variable is “playerSide”, the wiki is in error, the P should not be a capital

Thank you for this. I’ll play around with it and see what I can learn from it. I’m sure it will be more than just how to have the piece tied to the side that placed it.

Tim, that is an ingenious way to handle it. Thank you very much for your assistance on this, as it would have taken me quite a while to puzzle that out on my own, I think.

Am I correct that with the way you have it configured pressing CTRL+D followed by CTRL+2 would cause the selected piece to change to the currently selected side after it has been placed on the map? That wasn’t something I was needing, but could end up being a useful function for someone else (though if I understand how it works correctly, a Restrict Commands trait could avoid that ).

… this even allows the SM (DM/GM) to place a unit and then set its side if you press the correct control keys! That was something I wasn’t going to bother attempting until later. That does it … yer name is going into the credits info for my module, Tim!

OK, Tim, I have a question for you. Unfortunately for you, I’m the type that likes to understand /why/ something works, not just that it does what its supposed to. Especially when it comes to programming. Your module obviously works the way I want things to but I’m slightly confused by one aspect of how you have things set up.

Looking over the traits you used:

• the Dynamic Property - OwnerColor defines the numeric sides used by the Layer, based on playerSide, and gives a key command to set a specific side (clear as crystal)
• the Dynamic Property - FromTray is equally clear – defaults to TRUE (its a new unit) and gives commands to switch that boolean value
• the Trigger Action - Match if makes just as much sense – if playerSide = call the command defined in OwnerColor to set OwnerColor to the correct numeric value, then change FromTray to FALSE so it doesn’t trigger again later
• the Trigger Action - Begin Matching Sequence (lets call it BMS) is where things start to break down for me

I understand that if FromTray is TRUE, BMS calls the key command that triggers Match if . What I don’t understand is where the command BMS is “watching” for, CTRL 1, is getting called/activated. Its obviously not done my the player (me) since you just drag a counter to the map as normal and it works. I didn’t see it in the Single Piece definition that uses the Ownership Control prototype either.

So, what did I miss?

Yes it could work that way provided you remove the Delete trait which also functions on CTRL D from the piece and you want it to work that way

The CTRL 1 from BMS is linked if you look in the Map properties dialog box to the last field entry there - “Keystroke to apply to all pieces that end movement on this map” (or something like that). This is what starts everything off. In essence the sequence is working every single time you move the piece, but fails after the first time you have moved the piece because we change the FromTray property to false to prevent the rest of the trigger sequence from performing. FromTray acts like an internal switch to disable the subsequent changing of the bg layer color

I just knew it was going to be something simple! Well, this means I’ve got that worked out, and now when a piece is placed on the map it shows up with the appropriate color to show which side it belongs to!

That is the same ship, loaded once from each team – red, blue, gold and green. The other counter is for a Warp Point, the method of travel between star systems in the game Starfire. Now I just need to get the rest of the needed counters created and put into the game.

BTW, I noticed that on your version you used a blank.png image for the “no team” layer. Is that something you recommend, or just a habit of yours?