This question was created in reference to: [GameplayCues breaking garbage [Content removed]
Hi there!
To further optimize the GarbageCollection (we still have 8ms hitches on Reachability), I decided to enable both Actor and Asset Clustering.
We’re testing to see if nothing is breaking assumptions, but once we fire a GameplayCue, the next GC will assert when checking the assumptions.
I found a related post, and it seemed to be resolved (maybe) in private.
Was a solution was found? If so, is there a fix on 5.4 or later that I can backport?
As a temporary solution, to enable AssetClustering while skipping all GameCues, I changed BlueprintGeneratedClass.cpp with the following function :
bool UBlueprintGeneratedClass::CanBeClusterRoot() const { if (GetName().Contains(TEXT("GC_"))) { return false; } // We don't want to cluster level BPs with the rest of the contents of the map return !GetOutermost()->ContainsMap(); }(All our gameplay cues classes are starting with GC_)
Also, I suspect the following being the cause :
Our faulty GameplayCue has a Blueprint Execute that call another Blueprint function. In this function, we have a Character local variable. So perhaps in some way, when setting an object to this local variable will bind this reference to the GameplayCue CDO somehow…
the other question was indeed resolved in a confidential ticket.
It turned out they were initializing the GameplayCueManager very early from a CDO constructor through a few indirect calls.
Objects only get added to the DisregardForGC during the startup phase, so you’ll want to get a call stack for when that object is actually constructed and move that construction to a later phase or make it on-demand during gameplay.
A good place for a breakpoint can be UGameplayCueManager::OnCreated().
I wasn’t able to reproduce this issue. Could you explain the issue or your setup further or provide a minimal, reproducible project that demonstrates the problem?
As the GameInstance::Init() is called after the DisregardForGC closure. But just in case I removed InitGlobalData() from the GameInstance::Init(), but the GameplayCue was still breaking the assumptions.
I will try to setup a test project tomorrow (if I can reproduce the issue on a clean project).
But as I said in the first post, I suspect storing a UObject reference as a Local Variable in a function from a Blueprint GameplayCue will break assumptions.
I’m sorry, I’m not sure I follow. (I still have trouble to correctly understand the full extent of the GC system, clustering and disregard)
What should I be looking for here? Should the manager be Outside the pool? Should the Cues CDO also be outside the pool too? (I need to double check but the CDO are also outside)
As you said, I used a Breakpoint on UGameplayCueManager::OnCreated(), to find out that we were calling it through GameInstancce::Init(), by calling UAbilitySystemGlobals::Get().InitGlobalData(). This happends after the DisregardForGC closure. I guess this should be the correct flow?
I made tools to dump the disregard pool so I can quickly check any object if needed.
I tried to recreate the setup as you described, with the references from a local variable to a character, but I may not have to set up the same way. I was still unable to reproduce this bug.
If you were able to get a minimal repro project, that would help in tracking down the issue.