Questions about piece properties/marker trait

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.

  1. 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?

  2. 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
access/command traits)

So where you would have:

Basic Piece
Marker Horse = Black
Prototype Blah
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

Post generated using Mail2Forum (mail2forum.com)

Addendum Query.

The help file mentions the provision to place multiple name-value pairs by
using “,”

i.e
Property name: Rank,SerialNumber
Property value: Captain,123456789

Could it be possible to instead do something like -

Property name: Rank
Property value: Captain,General

Don’t know, but worth a try to see what happens :slight_smile:

Post generated using Mail2Forum (mail2forum.com)

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.

rk

Post generated using Mail2Forum (mail2forum.com)

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 :smiley:

Cheers!