Pre-Defined setup updating

Your Place Marker trait has no Key Command (3rd box down, below Menu Command and above the piece image) defined, so it will never be invoked by anything. You need to set a named command or keystroke command there, then that is what your SGKC should send, not Alt+U.

I apologize for this taking so long, I thought it would be simple :thinking:

here is the new SGKC:
image

the Control Piece Place Marker:

And the actual unit’s Sent To Location properties:

Not sure where the disconnect is?


You don’t have a Key Command–traits cannot be activated without one. THIS is what must match the SGKC being sent. The “Key command to apply after placement” is separate from and after the received SGKC. Apologies for being too brief in my previous post as “Key command” is in both places.

I’d like to add a bit, please note that a Menu Command by itself (without either Named Command or Keystroke Command) won’t do anything. As @JoelCFC25 said, there must be either a Named Command or Keystroke Command. (I beat my head against that wall for a while too.)

Thanks, guys, my head is definitely feeling mushy…

So if the Key Command in the SGKC must match the Key Command in the Place Marker trait, what should that Key Command actually be? it seems a bit recursive to put Place Marker as the Key Command inside a Place Marker trait.

I thought it should be Send To Location but it seems that is what I want it to do after it places the marker on itself (the Year marker).

You are confusing Key Commands with trait names.

Key commands take one of two forms. A Named Command (the lefthand box) is an alphanumeric sequence that pretends to be a keystroke. It should not contain spaces, but can be nearly whatever you want–I would recommend some short phrase that would help you in the future remember what it does (e.g. PlaceStartingUnits, or similiar). A Keystroke Command is something that you can invoke with your physical keyboard: Alt+C, Ctrl+H, Ctrl+Shift+A, and so on. These options are mutually exclusive–a key command can be a Named Command or a Keystroke Command, but not both.

You can do whatever you want here, but what’s being sent by the SGKC must match whatever you set as the key command for the Place Marker traits. Do not confuse the “Key Command to apply after placement” at this point. This will execute after the Place Marker acts and the piece is put on the map–the SGKC need not match this, as they will not interact. In fact, if you haven’t altered the Send to Location traits themselves, pictures indicated they were wired to the Alt+U keystroke, so if that remains the case the “Key Command to apply after placement” must be set to Alt+U (goes in the righthand box on that line).

1 Like

See if this helps. I must emphasize that the usage of Ctrl+T is purely for example. Use whatever you want here. The point is to show the parts that must match.

  1. SGKC sends Ctrl+T out in the void.
  2. The Year piece happens to have a Place Marker trait that is invoked by Ctrl+T. It fires.
  3. After the light blue aircraft piece is placed, the Alt+U keystroke is applied to it, firing that aircraft piece’s Send to Location trait.

1 Like

Thanks again, some progress has been made.

The Control Piece (the Year marker) will place the new units where I want them but only if I manually fire it. It seems the SGKC is not quite working. Does the order of SGKCs in a module matter? There are several others there. Images attached for reference, I took your advice and used ‘PlaceNewUnits’ as the GKC for this action.

image

The more qualifiers you add to the SGKC, the more likely you’re introducing an error that’s causing it to not execute. If there is only 1 “control” piece (Year marker, I take it) that must be targeted by this SGKC, you needn’t use a Pre-select Fast Match and the “Additional matching expression”. Use whatever limited method is sufficient to identify the piece. Based on what I’m seeing in this image, my guess–without seeing the module–is that you are introducing failure by the inclusion of {year} as the Zone name, unless year is in fact a Global Property that will resolve to the valid name of a Zone somewhere.

Thanks, there is , in fact, a Zone on the map named {year} but if I don’t need both I will delete the Fast Match as you suggest.

If the name of the Zone is literally the text string “year”, then using {year} is an error, it would need to be {"year"}.

If there is a Global Property named year, and the current value of that GP resolves to a value that matches the name of a Zone, that should work. Example: a GP named year currently has a value of 1943, and there’s a Zone on the map named “1943”.

Ok, thanks. I think we’re on the cusp of solving this, I really appreciate the help.

Running the Refresh Predefined Setups tool as I type…

Huzzah!!! It works!

I even deleted the Place Marker Menu command from the Year marker so player’s can’t inadvertently add duplicate counters to the game.

Thanks so much for your help and patience!

1 Like