I have some questions about piece properties. I experimented a little, but I don’t want to create modules based on undocumented behavior for fear it will break in a subsequent release.
If I define a property in a piece via the marker trait (horse=white), and subsequently add another marker further down the list (horse=black), does the redefinition of the property replace the earlier one? Is horse black, white, or somehow both?
If I define a dynamic property in a piece, what happens if I subsequently (a) create a marker trait that redefines the property? Do I lose the dynamic trait? For example, the dynamic property horse (=white) can be set by key commands to black or white. What happens if I subsequently add a marker trait where horse is black? (b) What happens if I define a dynamic property for horse and subsequently define it again later in the list?
These questions all arose because in a piece prototype, I created a dynamic property “declared” that had initial value 0 but can be set by command to 0 or 1. For just a few pieces, I needed the initial value to be 1. Short of defining a parallel prototype, I wondered if I could get my result by cleverly ordering dynamic marker and marker definitions.
My guess, but I could be wrong would be where properties have the same Name
handler (like your examples), the overriding marker/dp would be determined
by the trait stack order (works similar to multiple restricted
So where you would have:
Marker Horse = Black
Marker Horse = White
The property Horse would always evaluate to White.
One way to test it out though (especially where you are throwing dynamics
in) is to add a report trait saying “I think the value of Horse is $Horse$”
to the top of the stack under the basic piece and have it report what vassal
thinks the property value is when you move the piece or do something… That
should solve how it thinks for this problem
I think the comma-separated format is just a shortcut to set more than one property using one marker trait. For example, in one marker definition, horse,dog = black,poodle would be a shortcut for two markers, horse=black and dog=poodle. The slash in front of the comma cancels the comma as a parsing field, so it is inappropriate for my use.
Yes, I realize I could run all sorts of tests to determine how it works now, but unless it is documented to behave in a certain fashion, the behavior could change in the next release.
The property value will be determined by the last trait to define the property. Tim’s example is correct. Although this is undocumented, it’s a consequence of the core mechanism for VASSAL’s handling of traits and is not subject to change in future releases.
I futzed around with this and nearly got it working. In the prototype, define the initial value of the DP as $init_declared$ (or whatever name you want). Then define “init_declared” as a marker to have the value you want in the piece that uses the prototype.
I wasn’t able to get it to work precisely how I wanted, but almost. No matter what, you have to force the real piece (i.e., action via a keystroke) to initialize itself. In the prototype, I created a DP modification action called “initialize” that sets the value of the DP to “$init_declared$”
If you want to init a bunch of DPs, use a trigger action.
I wish there was some “automatic, one-time” trigger when a piece was first created/loaded. Better yet, there should be an “initializer” trait so we would have to do this kind of hacking. Maybe it will be included in the “programmatically modify DP” feature enhancement I read about