I have units placing a marker that should have the parent unit stamped on it. However, in the “Define Marker” I have no longer access to the name of the parent. BasicName refers to the marker itself. Is there another property that could help here?
1 Like
I am trying to squeak a new feature into the 3.7 beta 5 that will add two properties UniqueID and ParentID.
All pieces will be allocated a UniqueID which will be a guaranteed unique ID that will be maintained across future Game Refreshes. ParentID will be set in Markers created by the ‘Place Marker’ trait with the UniqueID of the piece that placed it.
You will then be able to add {UniqueID == "$ParentID$"} to the Additional matching expression of a GKC or Set Piece Property trait (new to 3.7) to affect the parent piece. The $ParentID$ is replaced with the literal value of the ParentId property on the placed piece before the expression is checked against other matching pieces of the GKC.
This can be used in conjunction with the new 3.7 Attachments feature.
There are ways to do this pre-3.7 but are complex and clunky, involving setting an identifier into a Global property and then having the placed piece read the value of the GP via the after-placement key command. You can then use this is a GKC using similar syntax to the above.
There is an existing unique ID PieceUID that exists in 3.6 but it gets updated when a game is refreshed, so is of no use for long-term connecting of pieces.
3 Likes
That sounds very interesting, thanks.
I may be trying the clunky way, because otherwise I’ll have to modify a couple of hundred counters with almost identical code.
One question: I didn’t entirely understand the substitute part of {UniqueID == "$ParentID$"}. Wouldn’t that be identical to {UniqueID == ParentID} ?
If you use that fragment in most places, yes, the two are identical.
However, the Additional matching expression field in a Global Key Command (GKC) trait or in a Set Piece Property (new v3.7) trait work differently.
In a GKC trait, the GKC is running in piece A, but is running the Match expression against other pieces (B, C etc).
What happens is that before the GKC starts, the $ParentID$ (and any other $$ variables) are literally replaced with the values from counter A, so when the GKC starts running, the match expression has been converted to {UniqueId == "123456789012345"}. Next, that updated match expression is then checked against counter B using counter B’s value for UniqueId. And so on.
This is a standard technique for finding and influencing other pieces that are related to the piece that is currently executing a Command. (it’s described on the Global Key Command and Property Match Expression pages in the reference manual).
Thanks for the explanation. I thought I had seen that notation before, but I couldn’t remember where.