I’m recently encountering some issues within my project, that the player character got destroyed occasionally by unknown reason.
I’ve searched and reviewed all my logic, apparently nothing related to “destroy actor” is connected to the player character. There might be some physics acting weird and caused the deletion of the player character - I have no idea at this point and it might be impossible to pin point the actual issue.
So my question is, is there a way to override the existing destroy actor function, so any known or unknown command won’t get the player character removed from the level?
Yes - and I actually never called destroy actor on the player character anywhere in my logic
and it’s hard to pin point what’s causing it, that’s why I’m thinking to just lock the destroying function itself, if there’s a way.
Is the actor in the world? Is the player controller attached to it? If you unload a world the actor is attached to, it may get destroyed; if you do this, make sure the player is part of the top-level persistent world.
If that’s not the problem, the next thing you have to do is to override the destroy method in your actor, and put a breakpoint on it, and figure out who calls it. In general, objects don’t just get “randomly” destroyed.
Hey there @Guesscui2018! As Jwatte mentioned, most actors of any sort don’t get destroyed without cause usually.
Are you using World Partition? If so, it may not be destroyed, but out of loading context if you hadn’t set it up as an actor to force stream in the area around them. Objects can also be destroyed if below a certain height (defined in the world settings).
I’d also recommend following Jwatte’s recommendation and setting a breakpoint on the destroy method and see where it comes from.
Yes, in my case I’m using world partition. The thing is, world partition has been enabled for a long time and I never had any problem like this.
My issue seems to happen when certain enemy AI is touching the player actor. However, I couldn’t find anything lead to any destroy actor calls, the logic between these actors are really not that complex.
I’m crashing my head now since I really don’t have any idea what’s causing it.
Yeah sure will set some break points and dive deeper on the matter.
It could be that the interaction between the AI and the player could be maybe launching the player to the kill distance. I would definitely inspect the breakpoint on the destroy method first, then walk down to see what the cause was.
Ok, so after I investigate the case with breakpoint, the call stack pointed me toward this actor.
The graph shows the event.
I still don’t fully get it - the overlapping event triggered the destroy actor event at the end.
However I’ve put a tag to filter out player actor from the beginning of the overalpping event.
I have no idea how the logic went through, is it because of the 0.1 sec delay? so even if the tag has a filter, and player start overlapping within the 0.1 sec interval, the overalapping event will see player actor as the “other actor”??
This is really something I never thought about before, can someone confirm this is what’s actually happening in this graph?
Lets say this is executed a first time and your tag check passes so the delay starts. And in the meantime another execution happens, but this time for the player character, which is filtered out by your tag check. Then the OnComponentBeginOverlap’s OtherActor references now the actor of the last execution (-> Your player character).
Therefore, when adding a latent node (like a delay) to an event like this one, you can never be sure to access the desired data after the latent node completes.
Glad you’ve resolved it! Another note to add is that delays are going to fire again regardless of any situation once you’ve stated them. So if you have something that fires 100 times, no matter what changes between now and when the delay was set to fire, it will go off 100 times after that time frame. It’s also no longer in sync with the script prior, so for example if you check a variable after a 3 second delay, but that variable changes in that time since the first execution, it will read what it is at the time of the delayed execution, which causes all sorts of problems.
