New Component: DynamicImpulseSearchBlock

[JackTheFoxOtter]

Is your feature request related to a problem? Please describe.

I use dynamic impulses a lot for project organization and reusing code in multiple places. Sometimes I have projects that are "self contained". Currently, when you have a generic dynamic impulse tag (like "Abort" from the current project I'm working on), there's the possibility of it getting triggered by accident if another system happens to send an impulse with a matching tag at a hierarchy containing my system. This can result in unintentional / undefined behavior of my creation.

Describe the solution you'd like

To prevent these accidental impulse triggers, I'd like to request a new tagging component DynamicImpulseSearchBlock that should behave the following way:

• Child slots that contain a DynamicImpulseSearchBlock will be skipped during hierarchy traversal of dynamic impulses
• An impulse aimed directly at the slot containing the DynamicImpulseSearchBlock should NOT be blocked. My rational for this is that when I put the DynamicImpulseSearchBlock on the root of my object, and something sends an impulse directly to that slot, the sender is intentionally targeting my system and an accidental trigger is ruled out.

Describe alternatives you've considered

• Just accepting the risk and changing nothing
• Giving the dynamic impulse receivers very specific names and avoiding generic ones (which is a valid approach as well)

Additional Context

I'm not sure how "heavy" the operation of checking for a specific component type on a slot is. Many complex systems rely on sending thousands of dynamic impulses, so I would be a little hesitant of having this implemented if it would slow down dynamic impulse hierarchy traversal significantly.

Requesters

No response

[shiftyscales]

Giving the dynamic impulse receivers very specific names and avoiding generic ones (which is a valid approach as well)

I consider this the proper solution to this issue, similar to cloud variables- even just prefacing the variable names with a namespace can easily help avoid that issue. E.g. Jack.MyCoolThing.Abort

[Banane9]

I'm not sure how "heavy" the operation of checking for a specific component type on a slot is. Many complex systems rely on sending thousands of dynamic impulses, so I would be a little hesitant of having this implemented if it would slow down dynamic impulse hierarchy traversal significantly.

Well, that's exactly what is done to find all the receivers to trigger as well, so the complexity would double. Not a problem for small hierarchies or rare uses (which should be the application of dynamic impulses anyways), but not free.

I agree with @shiftyscales here though: just make your trigger names longer - basically free and more expressive too.

[Frooxius]

I do agree with these concerns.

This will add complexity to the receiver search. I also have some rough plans to add optimizations to pre-compute/cache receivers in the hierarchy for faster lookups and this could complicate that significantly.

Namespacing your impulse receivers is much better approach for this - this is how it's typically dealt with in other languages too to prevent name clashes.

The benefit of that is that it works with existing system and its mechanisms, without introducing additional complexity to the underlying system.