Summary
OnReceive override on custom components isn’t invoked until session end when sending scene events
EDIT: Turned out to be improper casting, the entity I was sending the event from was not the parent of the component I was sending to
Please select what you are reporting on:
Verse
What Type of Bug are you experiencing?
Scene Graph
Steps to Reproduce
Use a component with an OnReceive override and send an event down towards it
Expected Result
OnReceive is invoked for each child of the entity as soon as the event is fired
Observed Result
OnReceive is not invoked. SendDown() does not return successfully because the OnReceive override was not fired until the component is being removed from the scene.
Platform(s)
PC
Upload an image
Your event are never returning true, thus not passing the if (EventResult?) check. It is invoking (super:)OnReceive(SceneEvents), which returns false by default (or internal logic for some specific components)
You have a true laying around after your spawn{}, but it is doing nothing at all. I guess you probably forgot an return true here instead, that should work.
The reason why you are seeing “Event Received” on end, is due to the game itself internally doing some scene event calls at game end for other reasons, and these events show up anywhere that listens for them. (Hint: you can debug the scene event type with Print("SceneEvent: " + ToDiagnostic(SceneEvent)) to check the received type).
Edit: I forgot to mention, also currently there is a implicit limitation, where scene events only propagates if the entity is on scene and simulating (even if the entity/prefab outside the scene has multiple levels of hierarchy).
So, if you send a Scene Event on anything that is not on the scene or not simulating, it will not receive that event. (In case you are trying to initialize the sidekick “link” before adding the component to the scene).
This limitation is set to be lifted in the future (also I find very weird too haha, should never exist to begin with)
2 Likes
Hmm interesting, I’m not seeing the “Event Received” at all invoked until the simulation ends, but I will try your debug trick - and the (super:)OnReceive(SceneEvents) is the way the epic documentation says to do it. It says you can also return false but for better more precise propagation use the super version. As far as ‘return true’ vs ‘true’, the two keywords operate the same in this case because the function is looking for a returned logic, and true in this case provides that. The check is never being made though, because the Event is never propagated, otherwise I would see the “Event Received” even if no further checks happen (where the “assignment event received” print fires is where I believe you are thinking the print is happening.)
I add the component at runtime as is seen in the logs, all are initialized properly and the scene event is fired. For clarification ,I removed all code from my OnReceive override except for the “Event Received” print and it still does not fire until game end. If I’m not mistaken, when I use SendDown, I should see all children of the entity its called on have their OnReceive invoked, which is when I should see the “Event Received” print.
`if you send a Scene Event on anything that is not on the scene or not simulating, it will not receive that event. (In case you are trying to initialize the sidekick “link” before adding the component to the scene).`
hmmm this may be it actually. I think some sleep() time is in order, maybe the event is being sent before the component is simulating…
edit : while adding in delay did not work, it does appear the scene events being called at the session end are unrelated (found thanks to your debug method). It seems my events are not being properly sent for one reason or the next. Thanks again for your help! I’ll keep you posted.
thanks for your help! The debug trick got me in the right direction. It turns out my cast from entity to agent was incorrect. Even though the cast succeeded I still needed to do if(Ent := Result.GetFortCharacter[].GetEntity[]): in order to actually be accessing the correct entity…
Thanks again!
2 Likes
