Came out with an idea. Will hear other options with pleasure.
Possible solution:
Create a dedicated class for the FX, containing both collided objects as variables
Have a function in the colliding objects class, that spawns that FX class
Upon each collision, first check if there is already a FX class instance spawned in some small radius, that contains these objects & were created in the last 0.1 sec or so. if true - don’t create a new one. (avoid duplicate)
This way the first one to trigger the hit event will spawn the FX, and the second one will be prevented from doing so.
Hello! Was thinking you could also use an Event Dispatcher to talk to the LevelBP and have the LevelBP execute a Spawn Emitter at Location after a DoOnce (Pass the world location of a hit in the Dispatcher). Have also a FlipFlop behind the DoOnce (and after the Dispatcher) that has A wired to the DoOnce’s Exec and B wired to the Reset so that the second/superfluous Dispatch resets the Do Once for the next pair of Hits.
hmm that’s actually a nice idea. a DoOnce would be problematic here though because it’s global for all calls (will execute for all the calls from all the objects and locations) and not “local” for some specific location or another variable. Would have to implement the logic otherwise, without DoOnce and FlipFlop.
I know this is extremely aged, but I’ve been running face-first into this problem. I kinda got a jenky solution working with one actor taking ownership and setting up the required events on the other actor, as well as spawning the resulting effect, but it’s a little unreliable.
My use case is that I’m essentially doing stuff with “lasers” that add their vectors and colors when they collide, resulting in a third beam at the collision point. Obviously this can be problematic with both beams colliding into the third, new beam, as well as winding up with four beams because both took control.
Could you share more detail on how you’d wire this up generically?
The collision or overlap have the actor that generated them avaliable.
Assuming 2 of the same collide, where the code on both is identical.
You just call a blueprint interface function on a 3rd party object from them (so you have 2 calls). Passing themselves as variables.
In the 3rd entity you register who called first (update an actor variable).
If that value is set (not empty) and If the second call is from the same class type as the first, you ignore it. Otherwise you fire your function(s) as you would normally.
With each call you potentially reset the entity who called the function but you should still clean up (set to empty) after your function executes, so it can repeat the whole process again.
You could pack similar logic into the very same entity, but it gets into a race condition of who generated what first, which is why using a 3rd element makes things easier.