"Create Widget" blueprint node ignores default values of exposed struct pins

We are currently in the process of upgrading from UE 5.2 to 5.7 and have run into an issue when creating widgets using the “Create Widget” blueprint node.

If the created widget has any properties of struct type (e.g. FSlateBrush) which are marked as “Expose on Spawn”, any default values configured for these properties will be lost when the widget is created. (See reproduction steps for details).

Note that this seems to only affect struct properties. Primitive variable types like booleans, integers, etc. seem to keep their default values.

I dug into the code a bit and noticed that in FKismetCompilerUtilities::GenerateAssignmentNodes, an assignment node will be created for the affected properties because the “DefaultValue” member of the corresponding input pin is always empty rather than matching the default value of the widget.

I believe the reason for this is that in UK2Node_ConstructObjectFromClass::CreatePinsForClass, default values will only be set for pins which are editable according to UEdGraphSchema_K2::PinDefaultValueIsEditable (which returns false for most struct types, with a couple of exceptions).

My guess is that the solution to this issue would either be to always assign the pin default values in UK2Node_ConstructObjectFromClass::CreatePinsForClass, or to skip generating assignment nodes for pins without connections for which UEdGraphSchema_K2::PinDefaultValueIsEditable returns false.

Any input on this would be appreciated!

[Attachment Removed]

Steps to Reproduce

  1. Create a new widget blueprint
  2. Add a variable of some struct type (e.g. FSlateBrush) to the blueprint and mark it as “Expose on Spawn”
  3. Change the default values of the created variable in the blueprint
  4. Spawn an instance of the widget blueprint using the “Create Widget” blueprint node (do not connect anything to the input pin of the variable you created in the previous step)
  5. Observe that the value of the variable on the spawned widget does not match the default value configured in the blueprint
    [Attachment Removed]

Hi [mention removed]​,

Thanks for the detailed report. I can confirm I’ve reproduced the exact behavior you described in UE 5.7 as well as a recent source build from Main (CL 49363951). Struct properties marked Expose on Spawn lose their configured default values when using the Create Widget node if the pin is left unconnected.

I’ll continue investigating and will follow up with more information soon.

Best,

Francisco

[Attachment Removed]

Thanks for looking into it!

As a little update from my side: It looks like this issue does not only affect the “Create Widget” node but also all related object construction nodes like “Spawn Actor”, “Add Component by Class” and the generic “Create Object” node.

For now, our solution to this issue is to add the following code to FKismetCompilerUtilities::GenerateAssignmentNodes after line 821:

UEdGraphPin* FKismetCompilerUtilities::GenerateAssignmentNodes(class FKismetCompilerContext& CompilerContext, UEdGraph* SourceGraph, UK2Node* CallBeginSpawnNode, UEdGraphNode* SpawnNode, UEdGraphPin* CallBeginResult, const UClass* ForClass, const UEdGraphPin* CallBeginClassInput)
{
// ...
			if (OrgPin->LinkedTo.Num() == 0)
			{
				FString DefaultValueErrorString = Schema->IsCurrentPinDefaultValid(OrgPin);
				if (!DefaultValueErrorString.IsEmpty())
				{
					// Some types require a connection for assignment (e.g. arrays).
					continue;
				}
+				// FIX START: Do not generate assignment nodes for unconnected values which are not editable.
+				// Doing this would overwrite the default values configured in the class.
+				else if (OrgPin->DefaultValue.IsEmpty() && Schema->PinDefaultValueIsEditable(*OrgPin) == false)
+				{
+					continue;
+				}
+				// FIX END
				// If the property is not editable in blueprint, always check the native CDO to handle cases like Instigator properly
				else if (!bIsClassInputPinLinked || Property->HasAnyPropertyFlags(CPF_DisableEditOnTemplate) || !Property->HasAnyPropertyFlags(CPF_Edit))
				{
// ...
}

This solves the problem and so far we did not notice any other side effects. But I’m not familiar enough with the whole blueprint code to know if this is the best solution, so I’m looking forward to whatever you come up with :smiley:

[Attachment Removed]

Hello [mention removed]​,

Thanks again for the extra details. After some further investigation, I was able to confirm that this behavior appears to have been introduced in UE 5.5. Specifically, there were several changes made to FKismetCompilerUtilities::GenerateAssignmentNodes, and CL 34908597 (UE 5.5) is particularly relevant here. The intent of that change, per the CL description, was to:

Always generate assignments for unlinked exposed parameters when the class input may not be resolved until runtime.

This change affected all object construction nodes, including SpawnActor, CreateWidget, CreateObject, AddComponentByClass, etc.

I also found CL 36647670, which fixed a related regression where object properties were incorrectly cleared when compared against the CDO (e.g. Instigator on SpawnActor), but that fix appears scoped to SpawnActor.

For now, your workaround looks reasonable if it’s not causing issues in object construction nodes outside Create Widget.

I’ll keep looking into this and will follow up with any updates.

Best,

Francisco

[Attachment Removed]

Hello [mention removed]​,

After looking into this in more detail, this behavior is a known regression introduced in UE 5.5 and currently tracked internally as UE-235061: Unreal Engine Issues and Bug Tracker (UE\-235061)

As described in the issue, this change was intentional and made to address a separate regression. Since UE 5.5, properties marked as “Expose on Spawn” are treated as explicitly overriding the spawned object’s defaults, even when the pin is left unconnected. The underlying change is discussed in more detail in the following PR: https://github.com/EpicGames/UnrealEngine/pull/12637

You may continue using your own workaround or don’t mark the property as “expose on spawn”, as it is suggested in the PR, until a fix is introduced.

Let me know if this information helps your case.

Best,

Francisco

[Attachment Removed]