Flipped counter takes on different prototypes?

Posted similar on a different thread, but think this is a better place…

Anyone know how to do this…:

I want a counter to know when it has been flipped to a reverse side, so it can then behave differently - i.e. use different prototypes to when it was on its unflipped side…

This is for a module where the counters are uniquely labelled units, and the flipping is done via layers (and changing the image displayed), so I don’t think it’s possible to solve this by using a ‘replace’ type instruction to change the unit to its reverse side when flipped - it has to be the same counter, just on its reverse side.

Hope this makes sense - thanks in advance for any help :slight_smile:

You can’t change what prototypes are “active” on a piece dynamically if multiple prototypes are assigned. But prototypes are really just collections of traits, so if you have a set of traits you don’t want to be viewable or functional when a piece is in a certain state, use the Restrict Commands trait to hide/disable them as needed. Look closely at the documentation of the Layer trait to see how you can employ properties of layers (e.g. level number, level name) in your property match expressions for hiding/disabling commands.

Thanks Joel, I’ll delve into the Restrict Commands stuff - not looked at that before

One related trick: if you’re displaying the art for your counter with a “Layer” trait that’s part of a prototype, you should consider checking the “Level follows expression value” box. This will allow you to have the “Flip” state for your counter be tied to either a Dynamic Property (e.g. “FlipState”) or Global Property (e.g. “EmancipationProclamation == 1”). You can then use the expression & properties to also check whether & which traits to restrict/hide.

ALSO – not that I really recommend it, but it IS possible to do what you were describing above – you can actually “Replace With Other” a counter with a different one that represents its “flipped” state, if you want to. And then your Flip functionality no longer references two different Layers of a single counter, but in fact two entirely different counters (as far as Vassal is concerned), that just happen to represent the flipped sides of a single counter (as far as the player can see). I guess if the two different sides of a large class of counters were RADICALLY DIFFERENT in their abilities, and I wanted to keep the functionality of each side simple/small/tight then I suppose this could be a strategy. But I’d explore the other ideas above first.

And I happened to see your note in the other forum describing how that, after a unit “takes damage and splits into multiple parts”, you want the new sub-parts to be able to respond appropriately depending on their new states. This CAN all be done without needing to have the prototypes actually change for the units – it will just take some good “matching expressions” in e.g. Triggers in your prototype to check for the appropriate situations.

If you’d like to look at some example code that does some closely related stuff, pull down the latest For The People module.
(1) The “SP Base” defines the underlying properties for an infantry “Strength Point” in the game, generic to either Union or Confederate. Counter has effectively SIX “sides” representing strength values from 1 to 6.
(2) The “SP Dropoff” prototype goes hand in hand with it, and allows any SP counter to “drop off” and “pick up” other SP counters in the same space, and any resulting tokens then respond according to their respective values.
(3) The “Army” prototype ALSO uses the “SP Dropoff” prototype to allow a big Army to drop off and pick up strength points into the whole army. The individual army prototypes (e.g. “Army of the Potomac” inherit all this and have the additional ability to pick up and drop off weirder units like Cavalry).
(4) “Army Maker” allows a General token and a bunch of strength points to be “merged” to create a brand new army.
(5) “Cavalry Brigade Maker” allows a General token to merge with an SP to become a Cavalry Brigade token.
(6) And the “Cavalry” prototypes have functionality for if the Cavalry Brigade is damaged or its commander killed to re-split into separate General and SP tokens and go to separate/appropriate places on the turn track, etc.

Somewhere in there are probably examples which were help.

Brian

p.s. great screen name ;)