Levels follow expression value

I know I’ve done this before but forgot how to do it.

I’ve got Artillery pieces and a Target piece for each.

Arty piece Traits:

Basic Piece Name: 13/LAH Arty
Layer Name: Side
Layer has two levels

Target piece traits:

Basic Piece Name: 13/LAH Tar
Layer Name: none
Layer has two levels

I want to use “Levels follow expression value” to set the target piece level to the same as the Arty piece level.

What should the expression be?

Thanks.

Guess I’ve stumped the stars on this one. :frowning:

Basically you need a Global Property to store the layer level of the artillery piece (so use a Set Global Property on the same keystroke that’s adjusting the artillery’s layer), then have the target piece refer to that Global Property in the expression to follow. There’s no way for the target piece to query or directly monitor properties contained within the artillery piece (e.g., Side_level or a new dynamic property you might create within the artillery piece).

That doesn’t work, either–you would need a separate Global Property (GP) for each possible Artillery piece. I can’t actually think of any viable way to do this (which is why I hadn’t responded sooner): somehow, you need every Artillery piece to “know” which Target piece is attached to it, so you can then use a temporary GP and a Global Key Command (GKC) targeting that specific Target piece to pass the new value to the appropriate piece whenever the level of the Artillery changes (using a Dynamic Property (DP) on the Target piece to store the new value). I can’t think of any way to link the pieces properly, however.

And, I just thought of a way to do it (LOL). Need another GP, call it “ArtilleryCount” or some such, and give it a default value of 0. When a new Artillery piece is created, it needs to use a Set Global Property (SGP) to add 1 to ArtilleryCount. Then it needs to set a local DP “ArtilleryNumber” to equal the new ArtilleryCount. If the matching Target piece is created immediately, it can then reference ArtilleryCount to set its own ArtilleryNumber DP. If, on the other hand, the Target piece can be created at an undefined later time, you will need a temporary GP (I’ll go with “CurrentArtillery” here) to pass the correct value–the Artillery piece will need to use a SGP to set CurrentArtillery equal to its own ArtilleryNumber, then (assuming you’ve created the Target piece with a “Place Marker” trait within the Artillery Piece) send a command to the new Target piece, using the option to trigger a command after creating a new piece with Place Marker, to have the Target piece set its own ArtilleryNumber to equal CurrentArtillery. (Have I confused you thoroughly yet? :stuck_out_tongue: )

Now, whenever the Artillery piece changes level (and also when the Target is first created), it needs to use a SGP to set another GP (call it “CurrentArtLevel”) equal to its new layer (which can be referenced as “Side_level”, IIRC), then use a GKC targeting a Target piece that matches ArtilleryNumber == $ArtilleryNumber$ (if not using the Fast Match field, you will need to enclose that in curly braces {} ), telling it to update a local DP (we’ll call it “ArtilleryLevel”) that stores the current level of the artillery, and is used as the expression for the Target piece’s layer trait.

I’m sure that’s all clear as mud, but it’s about the best way to explain it I can think of at the moment.

(As an aside, this conversation should really be in the Module Design forum, not the Technical Support & Bugs forum–can a mod move it?)

In my too-brief reply I was in fact envisioning one GP per artillery piece (not knowing how many we’re talking about here), but I thought it and didn’t type it. And I guess I was assuming there was only 1 omnipresent target marker per artillery piece and that they wouldn’t be getting created/deleted.

If there are a fixed number of uniquely identified Artillery pieces, each having a single uniquely identified Target piece, then yes, a single GP for each Artillery piece would be a slightly simpler way of doing this. I didn’t want to assume that, though.

Thanks. I thought it was something like that. I’ll give it a try this weekend.

Jim