Any way to access Blueprint class node anonymous variables through reflection?

Development Programming & Scripting C++
, , , ,
1

I’m wondering if there’s any way to access the variables stored inside Blueprint nodes, through reflection?

I’m taking about things like the DoOnce macro or the DoOnceMultiInput node, which both expand out to a Temporary Variable node (UK2Node_TemporaryVariable) during compilation.

I’m trying to access the state of those on a given object, through reflection - but I can’t find any way to do it, as they don’t seem to be UPROPERTIES or UFIELDS to iterate over.

I want to save the state of those nodes and restore them as part of a save/load system.

(Yes, I know the logic could be re-written to use a boolean variable and a branch instead of using one of these nodes, but my question is if those variables can be accessed via reflection, not how to re-code it to avoid ever using such nodes.)

2

UK2Node_TemporaryVariable
bool bIsPersistent
Whether or not this variable should be flagged with CPF_SaveGame, and inherit its name from the GUID of the macro that that gave rise to it

seems to be the solution if you’re using serialization

3

I figured it out.

Blueprint local variables are stored in the Ubergraph Persistent Frame.

if (UBlueprintGeneratedClass* BlueprintGeneratedClass = Cast<UBlueprintGeneratedClass>(Object->GetClass()))
{
	if (UFunction* UbergraphFunction = BlueprintGeneratedClass->UberGraphFunction)
	{
		uint8* FramePtr = BlueprintGeneratedClass->GetPersistentUberGraphFrame(Object, UbergraphFunction);
		for (TFieldIterator<FProperty> PropIt(UbergraphFunction); PropIt; ++PropIt)
		{
			const FProperty* Property = *PropIt;
			const void* PropData = Property->ContainerPtrToValuePtr<uint8>(FramePtr);

			// TODO: Do something with Property and PropData
		}
	}
}

I hadn’t realised just how much state Blueprint graphs keep.
A lot of the logic is in macros which use local variables, but they don’t (and can’t) actually use the persistent flag, so it just stores everything. DoOnce and FlipFlops and Gates, but also the counters for loops, the return values of every node, etc.

That does reveal one major problem with the idea of saving these values - none of them have unique names, which means that saving them would be really fragile.
Saving “Blueprint boolean property #5” is all very well, but it quickly falls apart if the Blueprint graph changes and the numbers no longer align with the old save.

1 Like