Blueprint autoconversions normally work by checking pairs of linked pins and inserting cast nodes. However, default literal values on nodes aren't linked, so they must be treated differently.
Since default values aren't linked, we need to check the old and new pin types during rewiring. We can't do this during validation stage since we've forgotten the old pin type by that point. Additionally, we should prevent any sort of data loss when handling the default values. The safest way to do so is:
1. Create a literal node from the old type.
2. Create a conversion node between the old and new type.
3. Link the nodes to the pin that has the default value.
The drawback to this technique is that it inserts nodes, but it's safer than directly modifying the default value on the new pin (eg: "1.1" could end up as "1"). We still provide a note that nodes were inserted, which gives the developer the choice of how to handle the conversion change.
#jira UE-188291
#rb phillip.kavan
[CL 26055966 by dave jones2 in 5.3 branch]
(Resubmit: added check for "multiple self" connections. Even though the types mismatch, we permit these connections.)
The previous attempt to add automatic conversion nodes (24029327) had a flawed design: checking pin connections during rewiring might have an incomplete view of the types of the linked pins.
For example, suppose we have two native, BlueprintCallable functions. One returns a float, and the other accepts a single float. In a Blueprint, we have the output of one linked to the input of the other.
Later, we update both functions to use ints. During rewiring of the function with the return value, it might see that its connection is a float (because that node hasn't been rewired yet). As a result, it'll insert a cast node. Subsequently, when we later rewire the function with the input, it'll see that it's connected to a float, because of the recently inserted cast node. This will add yet another cast node. Since both pin types are the same, there shouldn't be any cast nodes to begin with.
The only safe way to insert cast nodes is after node construction has finished. Instead of handling this during rewiring, we can defer the type checking to early validation. Overall, this simplifies the autoconversion since we just need to iterate over pairs of pins, check for type mismatches, and insert cast nodes where appropriate.
This change effectively reverts CLs 24174262, 24029327, 24218437, and 25444139, and moves the type checking logic to EarlyValidation.
#jira UE-183502
#rb phillip.kavan
[CL 25834276 by dave jones2 in ue5-main branch]
Add a small bug fix to it. When attempting to create an auto-cast node from an Interface -> Object type, the UEdGraphSchema_K2::FindSpecializedConversionNode will NewObject whatever node type is required as a template to copy. This Template node does not have a parent graph (rightfully so) which means that the call to GetSchema would return null. When this happened with a Dynamic Cast node, it was checking on the schema being available in the SetPurity function where it was not before.
We don't want to set the parent graph on the template node during conversion because that isn't accurate because its a dummy template node, not something that is actually on the graph. It would also be adding references to that parent graph unnecessarily.
#rb Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Fix potential crash when `bFavorPureCastNodes` is enabled.
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25792482 by ben hoffman in ue5-main branch]
#fyi Phillip.Kavan
Original CL Desc
-----------------------------------------------------------------
Fix potential crash when `bFavorPureCastNodes` is enabled.
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#preflight 6479d868e319748a83f72c54
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25790092 by ben hoffman in ue5-main branch]
`K2Node_Message` attempted to create an impure cast node when expanded, but `SetPurity(false)` had no effect in this case because inside it `IsNodePure` returned `false` even if the default cast purity was `Pure`. It resulted in the creation of a pure node, causing a crash because the Message node attempted to work with its (non-existent) exec pins.
#rb Phillip.Kavan
#preflight 6479d868e319748a83f72c54
#ushell-cherrypick of 25757919 by kristof.morva1
[CL 25758302 by ben hoffman in ue5-main branch]
[FYI] dave.jones2
Original CL Desc
-----------------------------------------------------------------
UE-183502 - BP autoconversion adds extraneous conversion nodes
The previous attempt to add automatic conversion nodes (24029327) had a flawed design: checking pin connections during rewiring might have an incomplete view of the types of the linked pins.
For example, suppose we have two native, BlueprintCallable functions. One returns a float, and the other accepts a single float. In a Blueprint, we have the output of one linked to the input of the other.
Later, we update both functions to use ints. During rewiring of the function with the return value, it might see that its connection is a float (because that node hasn't been rewired yet). As a result, it'll insert a cast node. Subsequently, when we later rewire the function with the input, it'll see that it's connected to a float, because of the recently inserted cast node. This will add yet another cast node. Since both pin types are the same, there shouldn't be any cast nodes to begin with.
The only safe way to insert cast nodes is after node construction has finished. Instead of handling this during rewiring, we can defer the type checking to early validation. Overall, this simplifies the autoconversion since we just need to iterate over pairs of pins, check for type mismatches, and insert cast nodes where appropriate.
This change effectively reverts CLs 24174262, 24029327, 24218437, and 25444139, and moves the type checking logic to EarlyValidation.
#jira UE-183502
#preflight 647102108145a219b1209905
#rb phillip.kavan
[CL 25748352 by bob tellez in ue5-main branch]
The previous attempt to add automatic conversion nodes (24029327) had a flawed design: checking pin connections during rewiring might have an incomplete view of the types of the linked pins.
For example, suppose we have two native, BlueprintCallable functions. One returns a float, and the other accepts a single float. In a Blueprint, we have the output of one linked to the input of the other.
Later, we update both functions to use ints. During rewiring of the function with the return value, it might see that its connection is a float (because that node hasn't been rewired yet). As a result, it'll insert a cast node. Subsequently, when we later rewire the function with the input, it'll see that it's connected to a float, because of the recently inserted cast node. This will add yet another cast node. Since both pin types are the same, there shouldn't be any cast nodes to begin with.
The only safe way to insert cast nodes is after node construction has finished. Instead of handling this during rewiring, we can defer the type checking to early validation. Overall, this simplifies the autoconversion since we just need to iterate over pairs of pins, check for type mismatches, and insert cast nodes where appropriate.
This change effectively reverts CLs 24174262, 24029327, 24218437, and 25444139, and moves the type checking logic to EarlyValidation.
#jira UE-183502
#preflight 647102108145a219b1209905
#rb phillip.kavan
[CL 25727812 by dave jones2 in ue5-main branch]
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]
A reflected Blueprint type can now be changed without breaking existing content, so long as an autocast function exists for the two types.
Previously, pin reconstruction would give up if two pin types didn't match exactly, which resulted in orphaned pins and compilation errors. Now, it'll first try to find an autocast function for the two types, and insert a cast node into the graph if one is found.
Additionally, notes will be added whenever a new cast node was added, which serves as a notice that users might want to update their API to use the new type change.
#jira UE-172222
#preflight 63d85cf57a39a1802189bdda
#rb phillip.kavan
[CL 24029327 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]
#fyi dave.jones2
Original CL Desc
-----------------------------------------------------------------
UE-172222 - Improve redirect support for Blueprints.
A reflected Blueprint type can now be changed without breaking existing content, so long as an autocast function exists for the two types.
Previously, pin reconstruction would give up if two pin types didn't match exactly, which resulted in orphaned pins and compilation errors. Now, it'll first try to find an autocast function for the two types, and insert a cast node into the graph if one is found.
Additionally, notes will be added whenever a new cast node was added, which serves as a notice that users might want to update their API to use the new type change.
#jira UE-172222
#preflight 63b72580af3ebedd9988ae4c
#rb benjamin.fox,dan.oconnor
[CL 23657454 by dave jones2 in ue5-main branch]
A reflected Blueprint type can now be changed without breaking existing content, so long as an autocast function exists for the two types.
Previously, pin reconstruction would give up if two pin types didn't match exactly, which resulted in orphaned pins and compilation errors. Now, it'll first try to find an autocast function for the two types, and insert a cast node into the graph if one is found.
Additionally, notes will be added whenever a new cast node was added, which serves as a notice that users might want to update their API to use the new type change.
#jira UE-172222
#preflight 63b72580af3ebedd9988ae4c
#rb benjamin.fox,dan.oconnor
[CL 23629872 by dave jones2 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]
- Scenario is: A module gets loaded and triggers a RefreshPromotionTables on the game-thread while the ALT reads FindBestMatchingFunc from the table.
#rnx
#jira UE-173083
#rb Dan.OConnor
#preflight 63b71395763c6c1064aec427
[CL 23590450 by danny couture in ue5-main branch]
