Yellow-Dog-Man / Resonite-Issues

Issue repository for Resonite.
https://resonite.com
140 stars 2 forks source link

New Component: DynamicImpulseSearchBlock #3178

Open JackTheFoxOtter opened 19 hours ago

JackTheFoxOtter commented 19 hours ago

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:

Describe alternatives you've considered

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 commented 13 hours ago

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 commented 34 minutes ago

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.