What is the effect of several pieces having the same PieceId?
When using [gkc], I set matching properties to PieceId != $PieceId$ to exclude the invoking unit (otherwise it gets its own global command). However, I have discovered that ReplaceWithOther in a prototype creates the selected unit with the same PieceId whenever the [rwo] is executed. This results in these Other units ALL having the same PieceId.
What then uniquely identifies the pieces from each other under the Java Code? Is this a bug or a feature (with me misusing the property)?
After a few ReplaceWithOther executions, my [gkc] exclusion starts ignoring many units that should be affected. Any suggestions to maintain uniqueness?
I’ve never tried working much with PieceId, and I’m not able to check it out right now, but it certainly seems a plausible bug. Two possible workarounds, in any case:
Give each piece a Dynamic Property, ‘IgnoreTriggers’. Have the invoking piece set, GKC, unset.
More generally, you can create your own ID property, using a Global Property NextID - each piece grabs NextID, then increments NextID. This would probably require either a Startup Command (custom class in 3.1.x, builtin in 3.2), a startup button for your players to push, or manual assignment to at-start stacks; also, aggressive use of ‘Keystroke to apply after placement’ for the RWO and ‘Keystroke to apply to units created on this map’ on every single map.
I bet both of these methods would have some problems online. Well, lots of problems, I would guess, because I bet the PieceId is used to tell the other players which piece(s) to update. Do you have the same problem with RWO outside of a prototype?
What I did was to add a Dynamic Property [DP] IdNum (updateId) ← $PieceID$ to all units.
I also added to each unit a trigger [TRIG] (movedInWIndow) → (updateId) when IdNum=0.
So whenever I envoke a Replace With Other [RWO], I make sure match properties is checked, and now reference the IdNum instead of PieceId.