Partial back-out of this CL (MessageNodes still allow hookups to redirected static functions so as not to break potentially submitted content).
[FYI] jodon.karlik
Original CL Desc
-----------------------------------------------------------------
K2Nodes now allow a CoreRedirect from the "self" pin if (and only if) the new function changes the visibility of the "self" pin. This allows you to redirect member functions to non-member static functions (which will hide the self pin). For example:
If the original call was a member function Foo.Bar(123) you could redirect that to a static function Bar(Foo, 123).
Syntax in BaseEngine.ini [[CoreRedirects] looks something like:
; Redirect the Member Function to a Static Function
+FunctionRedirects=(OldName="/Script/PluginName.Foo.Bar", NewName="FooBlueprintLibrary.Bar")
; Redirect the Self Pin to a Parameter Pin named "InFoo"
+PropertyRedirects=(OldName="FooBlueprintLibrary.Bar.Self", NewName="InFoo")
#rb ben.zeigler
[CL 35787966 by jodon karlik in ue5-main branch]
If the original call was a member function Foo.Bar(123) you could redirect that to a static function Bar(Foo, 123).
Syntax in BaseEngine.ini [[CoreRedirects] looks something like:
; Redirect the Member Function to a Static Function
+FunctionRedirects=(OldName="/Script/PluginName.Foo.Bar", NewName="FooBlueprintLibrary.Bar")
; Redirect the Self Pin to a Parameter Pin named "InFoo"
+PropertyRedirects=(OldName="FooBlueprintLibrary.Bar.Self", NewName="InFoo")
#rb ben.zeigler
[CL 35774031 by jodon karlik in ue5-main branch]
Some users are hitting a check where no compiler relevant pin cannot be found during validation. It's unclear if this is an expected scenario. For now, we'll relax this to a soft-fail, and add logging to help track down the issue. If this turns out to be a valid scenario, we can remove the log in a future change.
#rb dan.oconnor
[CL 29602075 by dave jones2 in ue5-main branch]
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 26034634 by dave jones2 in ue5-main 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]
[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:
- UEdGraphSchema_K2::CreateAutomaticConversionNodeAndConnections() handles both, but we were only allowing auto-cast scenarios to pass in the revised UK2Node::DoPinsMatchForReconstruction().
- This is needed for linked pins with matching names which were previously being allowed through, but now require types to match as well (or at least have a matching auto-conversion or auto-cast operation).
- UK2Node::DoPinsMatchForReconstruction() is now at parity with UEdGraphSchema_K2::CanCreateConnection() in terms of when the latter returns CONNECT_RESPONSE_MAKE_WITH_CONVERSION_NODE.
#rnx
#jira UE-172222
#rb Dave.Jones2
#preflight 63e6e33de92f139c517a0f4e
[CL 24174262 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]
#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]
* Added overloads for FindSpecializedConversionNode and SearchForAutocastFunction that don't use output parameters. There are several instances in the engine where dummy variables are used to get around this.
* Updated the Message_ functions to use template parameter packing. The arguments are forwarded to the underlying FCompilerResultsLog, if one exists. This allows us to use tokenized messages.
* Changed several functions in FCompilerResultsLog to use the coding standard's naming convention. Specifically, arguments need to start with an uppercase letter.
#jira none
#preflight 639778dc2960b732208492ae
#rb phillip.kavan
[CL 23482483 by dave jones2 in ue5-main branch]
Overview:
- An "override flag" is an inline toggle-style Boolean edit condition. These are implicitly set to true at runtime within the output struct value if any member that's bound to it is exposed as a visible input pin on a MakeStruct node.
- For context, the Property Editor implicitly sets an override flag to true at edit time when a member that's bound to it is enabled for editing. These members are not otherwise labeled/exposed for direct editing.
- An override flag is meant to signal to a system that the user wishes to use the bound member's value in place of the current value (whatever that may be) when the full struct value is applied. Examples: FPostProcessSettings, FMovieSceneSequencePlaybackSettings, etc.
Previous UX:
- All boolean edit conditions were being treated as override flags on a MakeStruct node.
- Any inline toggle edit condition that did not begin with "bOverride_" or whose suffix otherwise did not match another value member could be exposed as an input on a MakeStruct node.
- Override flags exposed as inputs would always be set to TRUE at runtime regardless of input if it was declared at the top of the struct and if a member value bound to it was also exposed as an input pin.
After this change:
- Only inline toggle edit conditions and legacy struct members that follow the "bOverride_" naming convention will be treated as an override flag on a MakeStruct node.
- Inline toggle edit conditions can no longer be exposed directly as an input on a MakeStruct node. The intent was to bring the MakeStruct node UX closer to parity with the Property Editor UX.
Additional notes:
- Members that follow the legacy "bOverride_" naming convention were already being excluded from the optional input pin set on MakeStruct nodes if another member property name also matched its suffix. These have historically been excluded from ALL optional pin sets that utilize any FOptionalPinManager subtype (regardless of node type), so there was no change here.
- Existing MakeStruct nodes that may have already exposed inline toggle edit condition members as input pins will now orphan those pins on load if connected or if set to a non-default value (true). The "correct" way to set an override flag is by choosing to expose a member that's bound to the override condition as an input.
- Existing BreakStruct nodes are unchanged currently. Meaning, inline edit conditions that don't follow the legacy "bOverride_" convention can still be optionally exposed as an output pin. This UX was preserved as existing Blueprint logic could conceivably rely on the value of an override flag.
- Only one implicit assignment is now emitted for each override flag binding. Previously, we were emitting one assignment statement per bound property, so it could result in redundant assignments to the same flag if more than one property was bound to it.
#jira UE-147873
#rb Ben.Zeigler, Sebastian.Nordgren
#preflight 632c7353c7791417aa87f3bf
[CL 22164359 by phillip kavan in ue5-main branch]
#preflight 61eefc77ba69a4fdb220bf23
#ROBOMERGE-AUTHOR: marc.audy
#ROBOMERGE-SOURCE: CL 18712765 in //UE5/Release-5.0/... via CL 18712784 via CL 18713147
#ROBOMERGE-BOT: UE5 (Release-Engine-Test -> Main) (v903-18687472)
[CL 18713191 by marc audy in ue5-main branch]
