What causes Destroy() to return false? (Fail)

Development Programming & Scripting C++
1

I’ve been stuck on this for a couple of days. I have a blueprint actor that refuses to be deleted. Not just in code, but in the editor also. When I click play and the actor is spawned in, I F8 out and click the actor, and hit delete. The console output says “Deleted actor Workshop_BP_0”, but it’s still there. Another very similar actor deletes just fine. For a time, it was deleting just fine, and seemingly overnight it stopped working. I’ve tried rebuilding the BP from scratch thinking it might have corrupted, but it still happens. I’ve removed all the meshes and done everything I can think of to debug and find out what’s causing it.

So what factors can cause Destroy() to fail and return false? I can’t find any documentation or discussion about Destroy() returning false and not working.

HELP LOL this is driving me crazy.

EDIT SOLVED: It appears I was not calling Super in BeginPlay(). Not 100% because I don’t have a version control for that that I can check. But, what I can check suggests that is the most likely explanation. It makes sense that all kinds of stuff would get registered in BeginPlay() that you would need to properly destroy an actor.

3 Likes
2

So I finally solved this. I narrowed it down to this code on LevelActor.cpp that was returning false in DestoryActor(). I could not figure out why.

const bool bCanDestroyNonNetworkActor = !!CVarAllowDestroyNonNetworkActors.GetValueOnAnyThread();
if (!bIsNetworkedActor && !bCanDestroyNonNetworkActor)
{
return false;
}

So I set about adding one section of code back at a time in a fresh class until I got it to fail in the same way. It had something to do with BeginPlay(). Once I removed beginplay() it worked as expected. Luckily I don’t need it there. Somehow BeginPlay() was flipping a bit in CVarAllowDestroyNonNetworkActors, and causing DestroyActor() to return false. Sucked.

1 Like
3

I got the same issue. Your solution works perfectly, but still don’t know the reason.

4

Are you calling Super::BeginPlay() in your BeginPlay() function? If you don’t, all kinds of mischeif will occur. It’s important to always call the parent implementation when overriding an engine function, unless you know what you’re doing of course.

5

TheJamsh I think I was because I started with a totally new class that would have had BeginPlay() included along with the super call.

Edit: And I learned early on about the importance of calling super when you override, so I kind of doubt I would have made that mistake.

Edit 2: I think I may have actually neglected to call super lol.