Notes:
- See 24252017 for additional context/review notes. The original change was backed out due to not handling mismatched object->object pin contexts on existing function call nodes (rare), so this version adds that part. An A/B screenshot is attached to the latest swarm review.
#rnx
#jira UE-157527
#rb Dave.Jones2
#preflight 63e75b9e043416e7ad4699b3
[CL 24315905 by phillip kavan in ue5-main branch]
Notes:
- This change is part of an upcoming regression fix (UE-157527) that will merge in from another stream that doesn't yet include type redirect support (UE-172222).
#rnx
#jira UE-157527, UE-172222
#rb Dave.Jones2
#preflight 63eb3afdf36e1a5ece5311a8
[CL 24218437 by Phillip Kavan in ue5-main branch]
[FYI] Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Generated Blueprint skeleton class functions will no longer parent themselves to interface class functions in the fast path, while also ensuring backwards-compatibility for existing call sites to implemented interface functions.
Epidemiology:
- There was a regression introduced with the change to BPCM in 4.17 which started causing all newly-placed function call nodes to use the interface class as the Target pin type, rather than the 'self' type.
- However, the compiled function context was still inferred as the 'self' type, which resulted in emitting to bytecode only EX_Context w/o the required EX_InterfaceContext.
- This meant at runtime the VM would read an FScriptInterface value (16 bytes) into a UObject* ptr value (8 bytes) allocated on the stack (execContext), which caused a stack overrun (recently surfaced by ASAN).
- That regression is now fixed in the BPCM, however..
- Since we also allow object->interface connections to pass w/o casting when the object type implements the interface, this appeared to work the same as before the regression from a user perspective. However, it created an inconsistency for Target pin types that led to some odd UX; for example, if you choose to no longer implement the interface, now you might have a local function call site w/ an interface-typed Target pin that you can no longer connect self to/broken connection.
- Fixing the BPCM issue also meant that Target pins reverted back to 'self' object type on existing nodes, which caused a backcompat issue from being linked to interface pins (as that requires an interface->object conversion and will fail validation).
- Fixing that *seemed* relatively straightforward; I added a bit of code to modify the node expansion to spawn an intermediate cast node. However..
- Discovered that dynamic cast nodes had an issue where ones we dropped as an autocast via TryCreateConnection() would not be pure (i.e. no exec pins) even though it was explicitly being set in the autocast logic.
- This meant that any intermediate autocast nodes for interface->self end up being dropped as impure, with no connection to the exec pins, so they would end up being pruned at compile time. (this problem was due to another regression that traced back a long long ways..it was introduced in UE 4.6).
- Fixing that required a change to the way in which Dynamic Cast nodes manage the internal pure/impure state (since it can be toggled by the user, and it also has a default setting for new nodes).
- After fixing that, existing connections now continue to work (including previously-connected interface array outputs), while dragging new connections from interface->self will now add an explicit autocast node.
- An additional fix was made to prevent users from connecting an array of interfaces output to a function call node's Target pin for new connections (existing connections will continue to function per above).
--> Since call nodes support a ForEach-style expansion, the array connection was being allowed to pass, but then it would try to add an autocast node as if it were a scalar type, which doesn't support the expansion, so it could not be connected (broken UX).
#jira UE-157527
#rb Dave.Jones2, Dan.OConnor, Ben.Zeigler, Marc.Audy
#preflight 63dd78f4cc75b137677aaa32
[CL 24067070 by bob tellez in ue5-main branch]
Epidemiology:
- There was a regression introduced with the change to BPCM in 4.17 which started causing all newly-placed function call nodes to use the interface class as the Target pin type, rather than the 'self' type.
- However, the compiled function context was still inferred as the 'self' type, which resulted in emitting to bytecode only EX_Context w/o the required EX_InterfaceContext.
- This meant at runtime the VM would read an FScriptInterface value (16 bytes) into a UObject* ptr value (8 bytes) allocated on the stack (execContext), which caused a stack overrun (recently surfaced by ASAN).
- That regression is now fixed in the BPCM, however..
- Since we also allow object->interface connections to pass w/o casting when the object type implements the interface, this appeared to work the same as before the regression from a user perspective. However, it created an inconsistency for Target pin types that led to some odd UX; for example, if you choose to no longer implement the interface, now you might have a local function call site w/ an interface-typed Target pin that you can no longer connect self to/broken connection.
- Fixing the BPCM issue also meant that Target pins reverted back to 'self' object type on existing nodes, which caused a backcompat issue from being linked to interface pins (as that requires an interface->object conversion and will fail validation).
- Fixing that *seemed* relatively straightforward; I added a bit of code to modify the node expansion to spawn an intermediate cast node. However..
- Discovered that dynamic cast nodes had an issue where ones we dropped as an autocast via TryCreateConnection() would not be pure (i.e. no exec pins) even though it was explicitly being set in the autocast logic.
- This meant that any intermediate autocast nodes for interface->self end up being dropped as impure, with no connection to the exec pins, so they would end up being pruned at compile time. (this problem was due to another regression that traced back a long long ways..it was introduced in UE 4.6).
- Fixing that required a change to the way in which Dynamic Cast nodes manage the internal pure/impure state (since it can be toggled by the user, and it also has a default setting for new nodes).
- After fixing that, existing connections now continue to work (including previously-connected interface array outputs), while dragging new connections from interface->self will now add an explicit autocast node.
- An additional fix was made to prevent users from connecting an array of interfaces output to a function call node's Target pin for new connections (existing connections will continue to function per above).
--> Since call nodes support a ForEach-style expansion, the array connection was being allowed to pass, but then it would try to add an autocast node as if it were a scalar type, which doesn't support the expansion, so it could not be connected (broken UX).
#jira UE-157527
#rb Dave.Jones2, Dan.OConnor, Ben.Zeigler, Marc.Audy
#preflight 63dd78f4cc75b137677aaa32
[CL 24067044 by phillip kavan in ue5-main branch]
ExpandEnumAsExecs was using an ambiguous pin lookup. These types of function nodes add additional exec pins that are named after the enumerators. If the target pin specified by ExpandEnumAsExecs happens to have the same name as an enumerator value, then we'll end up with the wrong pin if the basic FindPin function is used.
Instead, we prefer using FindPinByPredicate to specify the exact pin that we're interested in. This ensures that the expansion step creates a SwitchEnum node with a valid UEnum object.
#jira UE-174107
#preflight 63d9b16e65738ba9510f7d1e
#rb phillip.kavan
[CL 23983965 by dave jones2 in ue5-main branch]
In certain cases, non-self object pins have been serialized with null subobject category values. The root cause is due to how UEdGraphSchema_K2::GetPropertyCategoryInfo assigns UClass values. In rare cases, the UClass will be the skeleton class, which is transient, and leads to the null subobject category.
The fix simply modifies GetPropertyCategoryInfo to grab the authoritative class instead. Currently, this issue has only shown up in CallFunction nodes. If older content has this issue, then we'll assign the function's parent class as the subobject.
In a future change, type checking of pins will be a little stricter, so we need to ensure that objects are in a valid state for rewiring to work correctly.
#jira none
#preflight 63d406785428dc67b150f933
#rb dan.oconnor, phillip.kavan
[CL 23907462 by dave jones2 in ue5-main branch]
[Backout] - CL23820159
#fyi dave.jones2
Original CL Desc
-----------------------------------------------------------------
UE-174107 - ExpandEnumAsExecs always uses first Exec if an argument name matches Enum value
ExpandEnumAsExecs was using an ambiguous pin lookup. These types of function nodes add additional exec pins that are named after the enumerators. If the target pin specified by ExpandEnumAsExecs happens to have the same name as an enumerator value, then we'll end up with the wrong pin if the basic FindPin function is used.
Instead, we prefer using FindPinByPredicate to specify the exact pin that we're interested in. This ensures that the expansion step creates a SwitchEnum node with a valid UEnum object.
#jira UE-174107
#preflight 63cb0789fa290562c1c8b6b2
#rb phillip.kavan
[CL 23859234 by dave jones2 in ue5-main branch]
ExpandEnumAsExecs was using an ambiguous pin lookup. These types of function nodes add additional exec pins that are named after the enumerators. If the target pin specified by ExpandEnumAsExecs happens to have the same name as an enumerator value, then we'll end up with the wrong pin if the basic FindPin function is used.
Instead, we prefer using FindPinByPredicate to specify the exact pin that we're interested in. This ensures that the expansion step creates a SwitchEnum node with a valid UEnum object.
#jira UE-174107
#preflight 63cb0789fa290562c1c8b6b2
#rb phillip.kavan
[CL 23820159 by dave jones2 in ue5-main branch]
Adding Latent BP info to aync task nodes
#Jira UE-172965, UE-172960
#rb dan.oconnor
#preflight 63bda40ec45a2c81e013dd70
[CL 23759334 by nate strohmyer in ue5-main branch]
UFUNCTION(BlueprintCallable)
static void TestRequiredIntParameter(UPARAM(Required) int32 Value);
Useful for marking pointer params as required so they are not null by default, but also applicable to complex types with custom make nodes
#jira
#rb Jordan.Hoffmann
#preflight 63b89fff763c6c10645b94c4
[CL 23604737 by dan oconnor in ue5-main branch]
#jira UE-160577
#preflight 62f2b7df3f500fb6dcfa7513
#preflight 62f2bceaf75a2a539c44a908
#rb marc.audy
#fyi kriss.gossart
[CL 21321899 by benjamin fox in ue5-main branch]
- Plugins/BlueprintContext
- Editor/GlueprintGraph
- Editor/GraphEditor
- Editor/Kismet
- Editor/KismetCompiler
- Editor/UnrealEd/Private/Kismet2
note: if you're seeing this CL in the perforce history because you're trying to figure out why there's a null check that doesn't make sense, This is why. The goal of this CL is to preserve the behavior before IsChildOf changed rather than analyze whether that behavior makes sense. Use your best judgement
#rb marc.audy
#preflight 6299023a6438e3c731307a69
[CL 20474984 by jordan hoffmann in ue5-main branch]
#rb Rex.Hill
#preflight 6202c1f2e85c7a08bbf3987b
#ROBOMERGE-OWNER: dave.belanger
#ROBOMERGE-AUTHOR: dave.belanger
#ROBOMERGE-SOURCE: CL 18918552 via CL 18918618 via CL 18918624 via CL 18918631 via CL 18922663 via CL 18923570
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v916-18915374)
[CL 18923679 by dave belanger in ue5-main branch]
Adjust weights a bit to prioritize starts of words more
#ROBOMERGE-SOURCE: CL 17376142 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v865-17346139)
[CL 17376157 by ben zeigler in ue5-release-engine-test branch]
Description: Make it so breakpoints are saved in the EditorPerProjectUserSettings ini rather than blueprint uasset files so that they can be excluded from version control and be unique to the user
#jira UE-119540
#rb Ben.Zeigler
#ROBOMERGE-SOURCE: CL 16959614 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v838-16927207)
[CL 16959625 by jordan hoffmann in ue5-release-engine-test branch]
