Is there a reason you’re forcing garbage collection instead of letting ue4 handle it?
I’ve created a simple actor class (a bomb class) in C++ which I am trying to spawn and then destroy as the bomb is released and explodes.
The spawning code segment is as follows (with bomb being a class pointer previous set to equal nullptr),
if (!bomb)
{
if (GetWorld())
{
UWorld *world;
FActorSpawnParameters SpawnParams;
world = GetWorld();
SpawnParams.Owner = this;
SpawnParams.Instigator = Instigator;
bomb = world->SpawnActor<ABomb>(ABomb::StaticClass(), get_position(), GetActorRotation(), SpawnParams);
if (bomb)
{
bomb->set_speed(max_speed);
}
}
}
This seems to work fine. However, I then added the following code to destroy the spawned actor when I’ve finished with it…
if (bomb)
{
// ACTIVE BOMB - CHECK IF DEAD
if (bomb->get_time_to_live() < 0)
{
// DESTROY BOMB
bomb->Destroy();
GetWorld()->ForceGarbageCollection(true);
bomb = nullptr;
}
}
This seems to work fine … if I play the level once. The bomb actors are spawned, destroyed, respawned (using the same pointer) and so on. However, sooner or later (usually on the next replay) the game freezes for a few seconds after start up and I get a crash (I’ve attached a log file if that is of any use).
As this is the first time I have spawned actors in a project of my own am I doing something wrong either with the spawning itself or more specifically with the destroy handling. For the destroy I’ve forced the garbage collection as quickly as possible and I’ve reset the pointer to nullptr to avoid any erroneous calls to the destroyed actor (not that there are any other than those shown in the code segments above).
Any help would be appreciated!
I’ve been checking through other answers and there was advice to try this. However, it doesn’t seem to make any difference - same result with and without the forced garbage collection.
Is “bomb” a UPROPERTY? If so, there’s no need to null it. The engine will do it for you when the object is GC’d. You can check bomb == nullptr || bomb->IsPendingKill()
The nulling out might be causing something that thinks it’s a valid reference doing something to it and hitting a null pointer.
Thanks for the additional feedback. No bomb wasn’t a UPROPERTY - changing this (by itself) didn’t help.
However, in the end I think the main problem is that I’ve been migrating in code including its own garbage collection (the original reason for the pointer in the first place) and this has been causing ‘disagreements’ with the GC of UE4. I’m currently going back through all the classes so far imported to UE4 (fortunately there are only a few!) and ensuring that they are set up for UE4 GC correctly (notably using UPROPERTY more frequently).
You’ll find that this uproperty/gc thing is indicative of pretty much everything in UE4. If you can think of something, Epic probably made their own system for it or included a library and added an interface for you to use. TArray instead of std::vector, FString instead of string, etc. I suppose it’s so they can maintain some sort of controllable cross-platform support and general code quality.
General advice? Make 99% of your variables UPROPERTY’s, pointers or no. It’s always nice to have them visible to blueprints or editable in the details panel. I do use some non-uproperty stuff, but when I do, I always include a blueprint accessible mutator/accessor. Well, when the types involved are blueprint types.
So I cleaned up the code and ‘reluctantly’ handed over the garbage collecting to UE4 rather than trying to do it myself in parallel. The bomb class has been recoded so the Destroy handling is internal to the class, the pointer to the bomb is used only to complete the initiation of each spawned bomb and then no longer referenced, UPROPERTY makes more of an appearance … and the game no longer crashes! Thanks for the pointers and advice … this really helped.