Scheduler
Added schedule asset
Schedule builds a simple bytecode when edited/loaded/saved
Bytecode describes what tasks to run in order with what dependencies
Scheduler acts as an interface to the schedule world subssystem (so schedules can be run against specific worlds)
Schedule entry ultimately owns all the memory for a running schedule, mostly via the FScheduleInstanceData
Schedule is run via a graph of tick functions that are created on handle registration, held on the schedule entry
Component
Bare-bones component, still a few features to add (e.g. stopping starting ticking etc.)
Holds a handle to a parameterized schedule
Can update parameters by pushing them to named scopes in the schedule
Parameter Improvements
UI/UX
Changed parameter block workflow to be closer to how it works under the hood:
- Parameters are local state
- Graphs operate by writing local state (and reading local/global state)
- This means that parameters and graphs are created independently. Still TODO: setting defaults for parameters.
Added custom widget for selecting parameters (on pins at present - details panel still TODO)
Parameter picker can now create new parameters in-line.
Double-clicking a graph now opens it
Runtime
Patched up parameter blocks to work with the last set of RigVM refactors.
Rebased param block node, graph and schema to RigVM.
Re-duplicated compilation logic for parameter blocks. This should be subject to a later refactor to move the compilation our of URigVMBlueprint.
Switched property bag to create object ptr properties rather than raw object properties
Added support for attaching param stacks to anim BP execution, propagated from a schedule instance.
Consolidated specific layer memory ownership into stack layer storage types: FUObjectLayer and FInstancedPropertyBagLayer. Raw data layers are also still available.
Param stacks now have 'parent' stacks that they will differ to if values are not found in queries. This is used for task-level scopes. Tasks are assigned param stacks to run (and the graph of parent scopes is built) via the schedule instance data.
Param stack results API expanded so we can get ricer info from queries
Moved FParamStackLayer out of FParamStack
Added TLayerBuilder to allow raw data layers to be built out-of-line
Updated tests
#rb Nicholas.Frechette,Jaime.Cifuentes
[CL 28372599 by thomas sarkanen in ue5-main branch]
ConformAutogeneratedDefaultValuePackage assumed that DefaultTextValue had already been initialized, but that doesn't seem to be the case during AllocateDefaultPins.
This would result in AutogeneratedDefaultValue failing to fix-up for the current package ID, and would produce text with a non-deterministic key.
#jira
#preflight 6425e3a738075fa13f008efd
#rb Leon.Huang, Dan.OConnor, Dave.Jones
[CL 24867873 by jamie dale in ue5-main branch]
When a pin type is PSC_Self, then its object class type is assumed to be that of the generated class. FindSpecializedConversionNode performed that check for the input pin, but *not* the output pin. This would prevent linking of the self node's pin to any input pin that would need a conversion (eg: linking the self node's pin to a soft reference pin).
If the output pin type is a self type, then the fix here simply changes the output pin type to use the generated class obtained via the input pin. Note that this assumes that the output pin's type also comes from a pin in the same Blueprint as the input.
#preflight 63f39837e832ea950a75ec89
#rb phillip.kavan
[CL 24344207 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]
[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]
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]
This accidentally worked before (except on make struct nodes) but warned and tried to bind to a function named (null).None
#jira UE-171730
#preflight 6398fdba2540a78d2747e0c5
#rb dave.jones2
[CL 23498837 by ben zeigler in ue5-main branch]
* FFindSpecializedConversionNodeResults was missing its leading 'F'
* The deprecation comments for FindSpecializedConversionNodeResult listed the wrong function
#jira none
#preflight 6398b2da680483bcb1f70bdb
#rb trivial
[CL 23493832 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]
This avoids a runtime crash that otherwise results due to a lack of compile-time expansion support for non-array container types.
#jira UE-170352
#rb David.Garza, Justin.Hare
#preflight 637bdab22a05dabce916e7ed
[CL 23252340 by Phillip Kavan in ue5-main branch]
