Add a utility function and DeprecatedVariable static name to support this.
Use this to replace an old hack that ignored warnings for BeginSpawningActorFromBlueprint.
#jira UE-160577
#rb dan.oconnor
[CL 36448949 by ben zeigler in 5.5 branch]
Adds function to UK2Node_AsyncAction so that its members (really protected members of UK2Node_BaseAsyncTask) can be initialized properly from native. We can also do this via node spawners, but they tend to be clumsy when spawning async action nodes as intermediates.
#jira UE-222399
#rb dave.jones2
#rnx
[CL 35870402 by MagForceSeven in ue5-main branch]
Adds two functions to the UK2Node_ConvertAsset implementation that act as accessors to the pins created by that node.
#rb dave.jones2
#jira UE-222400
[CL 35797193 by MagForceSeven in ue5-main branch]
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]
Since GetThenPin was added to UK2Node in 5.x, derived classes don't need to provide their own implementations. These were largely identical to the one in UK2Node. Additionally, overriding non-virtual functions can be error prone if there's an expectation of polymorphic behavior.
#rb dan.oconnor, jodon.karlik
#rnx
[FYI] George.Rolfe
[CL 35782464 by dave jones2 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]
We already have a check that prevents renaming local variables to parameters, but we don't have the opposite check. Since renames first test the pin rename with RenameUserDefinedPin, we need an implementation in the function entry node that ensures that the new name doesn't collide with the local variable names.
#rb ben.hoffman
[CL 35426907 by dave jones2 in ue5-main branch]
Prior to CL 35309066, CreateExecPinsForFunctionCall would only create exec pins if the underlying function had FUNC_BlueprintPure set. However, since message nodes are always impure, the AllocateDefaultPins override would force exec pins to show even if the function is pure.
CL 35309066 changed the logic in CreateExecPinsForFunctionCall to use IsNodePure for determining if exec pins should display. Since the message node overrides IsNodePure to false, we could get a scenario where both the overridden AllocateDefaultPins and CreateExecPinsForFunctionCall would create exec pins. The most straightforward fix is to remove the AllocateDefaultPins override, and let CreateExecPinsForFunctionCall handle exec pin creation.
Also resaved affected content that needed nodes refreshed.
#rb dan.oconnor
#rnx
#changelist validated
#virtualized
[CL 35420300 by dave jones2 in ue5-main branch]
(Follow up change to CL 35309066)
If enabled, a function that isn't marked as pure can be converted to a pure node in a graph. While this provides flexibility for controlling graph layouts, pure nodes can introduce hidden performance costs. If an impure function is expensive, its conversion to a pure can introduce multiple calls for each connected output. Since Blueprint graphs don't do a great job of visualizing executions of pure nodes, we're defaulting this feature to off. Teams are free to decide if they wish to use it.
Additionally, this will issue a compiler warning if a illegal pure override is discovered in a node. This can occur if a user locally enables the project setting and checks in converted nodes.
#rb ben.hoffman
[CL 35315964 by dave jones2 in ue5-main branch]
Blueprint pure nodes were initially intended to be similar to "functional pure". In other words, they're deterministic and produce no side effects (eg: doesn't mutate state). However, pure nodes have violated both conditions for a while now.
Instead, pure nodes are simply function nodes with output values and no visible exec pins. While this can be convenient, they come with a downside: the pure node is evaluated for each connected output. This can lead to unexpected performance issues if the node is expensive to evaluate. In the case of non-deterministic nodes, this can lead to unexpected behavior. In both cases, the user often needs to cull multiple outputs of a pure node and cache the result manually.
The solution here is to add support for toggling purity at the call site. When a function node is placed, right-clicking on it and selecting either "Hide Exec pins" or "Show Exec Pins" will toggle purity. Additionally, the meaning of BlueprintPure and the "Pure" check box changes slightly: it now means that the function node _defaults_ to a pure state when placed in a graph. However, it can be toggled to show its exec pins.
In future changes, we'll also reevaluate which common library functions should continue to default as pure.
#jira UE-196156
#rb dan.oconnor, jodon.karlik, ben.zeigler
[CL 35309072 by dave jones2 in ue5-main branch]
#rb ben.hoffman
#jira UE-219696
[RN] Blueprint macros can now infer more than one type of pin, especially useful for TMap related macros
[CL 34910045 by dan oconnor in ue5-main branch]
