Does Send to Location functionality depend on location?

I have a Send to Location with a Keyboard Command CTRL-P that sends a Piece to an X-Y Position. It is a common Command for this type of Piece but that X-Y Position is nation-specific so I have it in a Prototype that is unique for each nation. All the restrictions related to that Send to Location are beneath it and within that Prototype. I also have a generic Prototype for that Piece for shared (non-nation specific) Traits which is beneath. This hierarchy is intentional and creates the desired interaction between traits:

Prototype - German Counter (Send to Location here)
Prototype - Counter (generic)

The Send to Location only works if it is AFTER the generic Prototype and I don’t understand why. There is no reference to that Keyboard Command at all in that generic Prototype. The Send to Location command is very vanilla and is neither greyed out nor hidden. The Command is there when you right-click, and it seems to work, except nothing actually happens. The Piece does not move. Again, I know the solution: I made a third Prototype and placed it beneath the other two:

Prototype - German Counter
Prototype - Counter (generic)
Prototype - German Send to Location

But I have no idea why it is behaving this way… What in the generic Prototype would cause a Send to Location to not work even though the Keyboard Command is never referenced in it?

This begs the obvious question. Does anything in your Send to Location depend depend on the Generic prototype? I feel stupid asking that question, but it is the inverse of what you were focussing on and could be relevant. If either that is a stupid question or the answer is “No”, would you like to post some more detailed information about the prototypes?

Found the issue. Apparently it doesn’t like that I have a Restrict Command for the CTRL-P that references a Dynamic Property that isn’t defined until later in the generic Prototype. I’m not sure I agree with the behavior because it just breaks the Trait when it encounters an unrecognized value rather than ignore it, but at least I know the solution. I moved the Restrict Command after the definition of the Dynamic Property and it all works now.

I’d like to see a more detailed listing of your prototypes and commands so I can better understand what’s happening. You omitted important information (restrict command trait) in your OP.

Restrict Commands, along with anything else that “affects” another trait in the same piece, like a Mask trait, (as opposed to sending a keystroke that is processed by the trait), can only affect things ABOVE them in the hierarchy (and you can imagine the entire contents of a Prototype as being “dumped in” at the location you have the prototype).

I can’t remember the reason(s) it is architected this way, but I know it is a Key Fact To Know.

Keystrokes, on the other hand, start at the top of the list and attempt to apply themselves one-by-one until they reach the bottom. Except as-far-as-I-can-tell they will sometimes be “eaten” inside of one prototype branch if anything fires for the keystroke, and will thus not happen to things in a prototype “down below”. Here I’m getting onto shaky ground as far as what the exact functionality is, but at least it gives you the general shape of something to keep an eye out for.

Brian

This rings familiar.
I seem to remember (don’t quote me for sure - I’ve been inactive a while now!!) that TA’s were weird in that they will also ignore the bottom up structure iirc. I seem to remember doing many funky things manipulating DP’s and TA’s with nests that weren’t normal as it pertains to true bottom up hierarchy which governs most traits

These sentiments are consistent with the observed behavior of my module. I assumed that the yet to be defined Global Property that was the culprit, as it was the only “suspect” item in my nation-specific Prototype. But I have multiple Trigger Actions and Restrict Commands that affect the same keystrokes. I did this specifically BECAUSE I was trying to be mindful of the location-based Trait behavior. I was INTENTIONALLY splitting Trigger Actions and Restrict Commands that did the same thing because I didn’t want traits to be unintentionally ignored. I guess in the case of keystrokes, it’s not a good idea to divvy them up across multiple prototypes, but better to have a single keystroke trigger at the bottom of your definitions…

There are tradeoffs with performance too, especially as your pieces start to have a whole lot of traits. When I was first getting going into doing “complexish stuff”, I tended to split everything up into a step-by-step. And actually that can be a pretty straightforward way to prototype algorithms and get things running in the first place – but you can then often make things a LOT faster by reducing the number of times a trigger has to get fired through your stack of traits.