I would like to take copies of the same set of piece traits defined in a prototype and use them for a number of pieces in a piece palette. BUT… I would like to be able to set the initial value of dynamic properties assigned to the pieces so they are different from one another, without actually creating any difference within the common piece definition.
For instance, if I use a marker trait in the single piece definition, and configure the marker to set a value of a dynamic property defined in the common prototype… what happens? Does it override the initialized value of the dynamic property and set it to the value for that piece that I want? Or does it create its own new property value with the same name really messing things up? Or does the initialize value of the dynamic property definition come along and overwrite the value set by the marker anyhow?
I guess one answer would be to try it, and I will. But curious what the underlying reason is for the behavior I might see.
“Common Piece Traits” Prototype Defintion:
Dynamic Property Definition “Test Property” numeric with initializer to 0.
Text Label showing $Test Property$
In the Piece Palette…
Single Piece Definition “A”:
Empty Basic Piece “A”.
“Common Piece Traits” Prototype.
Marker “Test Property” = 1.
Single Piece Definition “B”:
Empty Basic Piece “B”.
“Common Piece Traits” Prototype.
Marker “Test Property” = 2.
When I load the module what do I see in the piece tray? Two units A and B with Test Property of 0, or one with Test Property 1 and the other with Test Property 2? Or is the Test Property now completely flummoxed with unpredictable results? And I guess another question just in case is… does this change when the piece is dragged onto the map?
looks like it works in one sense… the marker value effectively seems to override the DP definition for just that piece.
however when I hit the key to modify the dp value it tracks and modifies the dp value but has no bearing on the value displayed by the label, or reported in the reports for the piece. those are determined instead by the fixed value of the marker.
so the marker is not a dynamic trait, which is I suppose what the difference is between a marker and a dynamic property.
what happens then if I remove the dp altogether for the items I want essentially fixed once the scenario design is done, just using a marker trait with a list of property key-value pairs? it means I am forcing the scenario design to happen in the module editor. that might be okay in terms of the benefit however. BUT… can I do that or will the system somehow break down and complain that there is no property value defintion at a low enough level? will test.
or… keep the dp’s but remove the dp key commands to change them (and triggers up the line). then they are there to be reference but their values are set by the marker trait for the particular piece instead of by the scenario designer entering a command.
of course, for properties that are meant to be changed during play I would not be using a marker at all.
I think the answer to #3 is that if you want multiple actions to take place, you would add a Trigger trait to the piece, which lets you combine multiple actions into a single keystroke. Then the hotkey you put in the Map Properties box would invoke the Trigger action.