While working with Unreal BP, i noticed that creating local variable (in function) with specific name and using ‘set’ node will always result in crash. Im not sure why exactly is it like that but it cause ‘corruption’ that can result in 100% crash of editor on startup. It seems that unreal will try to compile all files on startup and once it try to compile this specific BP with set node, it crashes. Your only way to fix that issue is removing BP from depot and make it from scratch which is really not optimal.
We would like to know what exactly is causing this issue and what names should we not use in naming for our variables. We will mark ‘Role’ as something we should avoid but if there are another names, please tell us so we can mark them too.
When the Blueprint compiler processes a Set Variable node, it runs a transform step that injects extra nodes for replicated properties. This is handled by FKCHandler_VariableSet::Transform.
The issue occurs because when you name a local variable “Role”, the compiler performs a name-based lookup in ShouldFlushDormancyOnSet(). It finds the replicated UPROPERTY “Role” inherited from AActor (which has the CPF_Net flag) and wrongly assumes the node is setting that replicated field. The compiler then runs the dormancy transform, which expects a “self” pin that local variable Set nodes do not have, and crashes when calling FindPinChecked(“self”).
if (SetNotify->ShouldFlushDormancyOnSet())
{
...
UEdGraphPin* NewSelfPin = CallFuncNode->FindPinChecked(UEdGraphSchema_K2::PN_Self);
// Crash triggered here
UEdGraphPin* OldSelfPin = Node->FindPinChecked(UEdGraphSchema_K2::PN_Self);
NewSelfPin->CopyPersistentDataFromOldPin(*OldSelfPin);
...
}
Only properties actually marked as replicated can trigger this path, which is why “Role” and “RemoteRole” do it (both are UPROPERTY(Replicated) in AActor). To avoid this crash, please avoid using the following replicated Actor property names for local variables:
Role
RemoteRole
bHidden
bTearOff
bReplicateMovement
Owner
ReplicatedMovement
AttachmentReplication
bCanBeDamaged
Instigator
Local variables should never go through this transform and this indeed is an engine bug worth submitting for review. In the meantime, avoiding those names for local variables being set will prevent the crash.
Please let me know if this information helps your case.
Thank you, this information indeed help us preventing Crash / BP corruption.
I didnt ask previously but is there way for us to “fix” BP that have saved local variable named like Role, RemoteRole etc. ? We can always make it from scratch or revert to previous version if its on server but it will be better to have some option to just fix it (something like removing variable, or rename it outside of editor?)
Unfortunately, once the execution pins are connected and the Blueprint is saved, it can’t be safely recovered outside the editor. The crash occurs during asset load, because the compiler automatically tries to re-compile the graph and re-enters the dormancy transform path we discussed earlier.
The Python API provides methods to edit Blueprints but it still requires loading the asset first, which will trigger the same crash even when running headless or outside the editor.
A possible workaround would be to modify the engine source and forcibly skip the dormancy transform in FKCHandler_VariableSet::Transform when handling local variables. Otherwise, reverting the asset from source control or recreate the Blueprint is a good option.