I have a status marker that I want to be able to toggle between two regions I’ve defined on an irregular grid. The regions are called E1 and E2. The regions seems properly setup, since the marker snaps nicely into place when I’m just dragging it around. The marker begins life in an At-Start stack on region E1. But when I try to add the Send to Location property to the marker (and choose “Region on selected map” and Region Name = E2), the command appears grayed out when I right click on the marker. I can make it move with a Move Fixed Distance, but that results in ugly movement reporting, plus I’m not sure how to get it to toggle back at that point using the same command.
I got Send to Location to work. I believe my error was that, in an effort to have one command toggle the piece back and forth between the two regions, I defined the same keyboard command for the Send to Location and the Send Back, and I think this made it choke. But it’s a lot better now, simply using the up and down arrow keys to move the piece. Which is fine, but not all that I want.
Is there a way to set a value on the piece denoting its position (“Slot1”, “Slot2”, for instance) and then have a command that, depending on that value, fires the appropriate command to move the piece, then updates the location flag on the piece? In this way, for example, I might make CTRL-P check a field on the “P Status” piece, see that it’s in the “Down” position, and therefore fire the command to move it up, then reset the “P Status” piece to the “Up” position.
I see that I can set properties on pieces and that Global Key Commands can be made to only look for pieces with certain sets of properties, which is all promising. What I don’t see is that GKCs can do if…then…else type logic. In other words, I might make a “Toggle Status P” GKC that looks for name=StatusP && position=up and then sends the command to move StatusP down, but I don’t see how the same “Toggle Status P” GKC could say, “Oh, there’s no piece that matches ‘name=StatusP && position=up’, so let me see if there’s a ‘name=StatusP && position=down’…yep, OK, sending the command to move that piece up.”
I see this as a similar problem to wanting a wargame to have a command to Damage a unit. If the unit is at full-strength, I want the Damage command to flip it to its reduced strength side; if it’s already at reduced-strength, I want it destroyed.
Thanks again for any help you can offer. I can certainly send a copy of my module to anyone who thinks it would help diagnose my problems.
OK, here’s what’s happening. I have a GKC that sends CTRL-T to name=StatusP. Here’s my piece, in case I’ve muffed the order of traits somehow:
Milankovich P (name of the piece)
Text Label (for testing purposes, see comments below)
Text = $position$
Keyboard Command = CTRL-L
Send to Location - Move Up/Down
Keyboard Command = DOWN
Send Back Keyboard Command = UP
Destination = Region on selected Map
Map = Main Map
Region Name = P2
Dynamic Property - position
Name = position
value = up
Key Command = ALT CTRL DOWN, Type=Set Value Directly, New Value = down
Key Command = ALT CTRL UP, Type = Set Value Directly, New Value = up
Trigger Action - Move Down
Trigger when properties match: position = up
Watch for = CTRL-T
Perform these keystrokes =
Trigger Action - Move Up
Trigger when properties match: position = down
Watch for = CTRL-T
Perform these keystrokes =
Property name = name
Property value = StatusP
With everything set up like this (but without the text label, I would click the button for my GKC, and nothing would seem to happen. The UP and DOWN commands worked fine if the piece was selected and given the commands directly. Frustrated that I couldn’t see which parts of the process, if any, were working, I added the Text Label in an effort to see whether perhaps the “position” value was being changed but something else was broken. Apparently, the label isn’t dynamic, so I had my Move Down Trigger Action fire CTRL-L to adjust the label to whatever the new value is after the GKC and Trigger Action do their work.
Well, I observed an interesting thing. When the dialog popped up asking for the new value for the text label, the StatusP piece had moved down. After I told it to use $position$ for the text label and clicked OK, it popped right back. What I believe happened is that the Move Down Trigger Action indeed sent DOWN and moved the piece to the correct location, then indeed sent CTRL-ALT-DOWN and changed the value of $position$ to “down” and then fired CTRL-L to show me that dialog (and the teasing little glimpse of the piece in the correct place (and with the correct label). THEN, I believe it went on to run the Move Up Trigger Action, based on the fact that position NOW = down.
OK…I just swapped the positions of Trigger Action - Move Up and Trigger Action - Move Down, and I think this confirms what I was thinking. With them in the new order, I clicked the GKC button. The piece moved and the text label dialog came up, after which, the piece stayed in the Down position. (It checked Trigger Action - Move Up, didn’t get a match on $position$, and moved on.) After that, the GKC button appears to do nothing, since it’s the above problem in reverse (the second Trigger Action undoes the work of the first.)
Any ideas on how to update $position$ without having this problem?
Is there a reason to actually define a dynamic property named position and manipulate it? Are the two positions in different zones/regions/locations? If so, instead of using position=down/up, just strip that stuff all out and use CurrentZone=P1/P2 or LocationName=P1/P2.
To answer you actual question, yes, the order of the traits is probably significant, but offhand, I can’t offer suggestions as to how to improve it.
I hadn’t run across a reference that listed the properties that pieces exposed; for all I know, I don’t need to add a Marker trait to be able to have a GKC discriminate by a property called “name”! (Guess I should try that!)
Is there a link in the documentation to all these properties?
In any case, thanks for the tip! I’ll give that a shot.
OK, I cleaned things up a bit, but the problem remains essentially unchanged. I ditched the Marker trait “name” and instead now direct the GKC to BasicName=Mil-P (the name in the Basic Piece trait). I also got rid of the manipulations of the Dynamic Property “position,” and I’m now referencing “LocationName=P1” or “LocationName=P2”.
Sadly, this doesn’t address the underlying conundrum: Once the Trigger Action detects the CTRL-T the GKC is sending the piece and moves it to the new location, the LocationName has changed … and then the other Trigger Action fires, moving the piece back. If it weren’t me we were talking about here, I’d be shocked that this is proving so difficult! But I know it’s a failure of vision – there MUST be a different way of approaching this that I just can’t see.
My understanding is you have created your triggers to move the piece if the condition is true and this is exactly what it is doing causing the looping effect of going from one place then immediately back to the other.
In this circumstance you will need a third ‘control’ conditional in a DP acting as a toggle true/false and a higher trigger to control the conditional and both movement triggers.
With the DP set to false the higher trigger executes setting it to true then executes the movement triggers. One of the movement triggers will fire (youll have to set your properties correctly to something like conditional = true && currentZone = whatever in each move trigger) which immediately turns the conditional back to false (prevents other move trigger from possibly firing) and then the key command to move the piece