Fix a crash in some asset editors when you force deleted an asset with pending changes and hit "cancel" on the save dialog
#jira UE-107248
#preflight 64517c880e33f2d51d6e3adb
[CL 25321878 by aditya ravichandran in ue5-main branch]
# Although there aren't references left to the object, iterating over all the things will return the thing. Flagging as garbage seems a lot testier of a change for fixing the 5.1 crash with varied lifettime of the mode and mode manager contexts, so merely tracking it and reporting the correct world here.
#rnx
#Jira UE-168159
#rb lauren.barnes, zach.rammell
#preflight 6356f2ff3d41a4455a628b31
#lockdown jeanmichel.dignard
[CL 22787075 by brooke hubert in ue5-main branch]
Add new MeshTargetInterfaceTypes.h file, move EStaticMeshEditingLOD there and rename to EMeshLODIdentifier. Add FGetMeshParameters and FCommitMeshParameters types.
IMeshDescriptionProvider::GetMeshDescription() now takes FGetMeshParameters to optionally specify LOD.
Added IMeshDescriptionProvider::GetMeshDescriptionCopy() function, to handle copy-case.
removed IMeshDescriptionProvider::CalculateAutoGeneratedAttributes(). This was only being used to force Tangents computation, which can now be done via GetMeshDescriptionCopy() and FGetMeshParameters.bWantMeshTangents option
IMeshDescriptionCommitter commit functions now take a FCommitMeshParameters to optionally specify target LOD.
StaticMeshComponentToolTarget::GetMeshDescriptionCopy() added, optionally computes auto-generated MeshDescription attributes on the copy
StaticMesh(Component)ToolTarget updated to support FCommitMeshParameters target-LOD.
SkeletalMesh, Volume, and DynamicMesh ToolTargets updated for new APIs but do not currently support any of the new LOD parameters. These should never be called w/ LOD parameters in the current codebase, ensures added to catch any errors (they would be non-fatal).
UE::ToolTarget::GetMeshDescription() and GetMeshDescriptionCopy() in now take FGetMeshParameters argument.
Removed bWantMeshTangents param to GetMeshDescriptionCopy(), now done via FGetMeshParameters. Updated call sites.
TransferMeshesTool now supports specifying read and write LOD (numbered or HiRes) for StaticMeshComponent source/target, via above functions.
TransferMeshesTool can now also target a new LOD in a StaticMeshComponent, index is 1 larger than current maximum source LOD.
#rb lonnie.li, rinat.abdrashitov
#rnx
#jira none
#preflight 61b8d56b2e65a1df046aa5e1
#ROBOMERGE-AUTHOR: ryan.schmidt
#ROBOMERGE-SOURCE: CL 18461686 in //UE5/Release-5.0/... via CL 18461725
#ROBOMERGE-BOT: STARSHIP (Release-Engine-Staging -> Release-Engine-Test) (v899-18417669)
[CL 18461778 by ryan schmidt in ue5-release-engine-test branch]
This represents UE4/Main @17911760, Release-5.0 @17915875 and Dev-PerfTest @17914035
[CL 17918595 by aurel cordonnier in ue5-release-engine-test branch]
- rename UEdModeInteractiveToolsContext to UEditorInteractiveToolsContext, made all functions virtual so they can be customized for the new Editor/EdMode implementations where necessary
- add UModeManagerInteractiveToolsContext and UEdModeInteractiveToolsContext subclasses. Most functionality stays in the base class. Mouse-handling functions that manipulate the InputRouter move to ModeManagerITC.
- EdModeITC now is initialized based on a ModeManagerITC, and shares it's InputRouter
- ModeManagerITC creates the child EdModeITCs, forwards Tick/Render/DrawHUD calls
- FEditorModeTools now creates a ModeManagerITC
- Add EToolsContextScope enum, with options for Editor and EdMode ToolsContext
- UEdMode::Enter() now creates a child EdModeITC via new EditorITC::CreateNewChildEdModeToolsContext() function above, in addition to storing reference to the ModeManagerITC. Internal code updated to handle both ITCs.
- The EdModeITC is shut down on ::Exit() and unregistered from the EditorITC parent
- UEdMode ITC access functions (GetToolsContext, GetToolManager, RegisterTool) now take an optional Scope argument
- UEdMode::GetDefaultToolScope() allows EdModes to define default scope for the entire mode, defaults to Editor scope
- removed unused CanStartTool()/etc wrapper functions from FModeToolkit, they were not being called
- FModeToolkit::Init() now listens to events from both the ModeManagerITC and EdModeITC, delete cleans them both up
- FModeToolkit::OnToolStarted() checks both ITCs to see which one owns the new Tool
- updated all EdModes that were directly accessing the UEdMode::ToolsContext member, replaced with calls to GetToolsContext() / GetToolManager() APIs
- updated ModelingToolsEditorMode to use EdMode ToolScope
#rb brooke.hubert
#rnx
#jira none
#preflight 6140cc1130c00d0001dc4b9e
#ROBOMERGE-AUTHOR: ryan.schmidt
#ROBOMERGE-SOURCE: CL 17510176 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v870-17433530)
[CL 17510201 by ryan schmidt in ue5-release-engine-test branch]
#jira UETOOL-3862
#rb lauren.barnes
#preflight 611bf56e3a81b00001053ff1
#ROBOMERGE-SOURCE: CL 17210215 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v855-17104924)
[CL 17210225 by steven dao in ue5-release-engine-test branch]
Storing typed elements in UObjects can easily lead to reference leaks if the elements aren't cleared prior to the UObject being left pending GC. This actually made UTypedElementList tricky to use, as you had to remember to manually empty it when you'd finished with it to avoid reference leaks, and we've had several cases now where that was done incorrectly.
To address this issue, we've moved element lists back to being a normal C++ class, FTypedElementList. However, unlike the original version of FTypedElementList (which was itself a UStruct), this version is always heap-allocated and referenced via a TSharedPtr/TSharedRef.
This gives us a nice middle-ground of a well defined lifetime (ie, no lingering references prior to GC) while still being efficient to pass around, including for scripting APIs via FTypedElementListProxy (which just wraps the TSharedPtr in a UStruct).
The downside of this approach is that we need to wrap the FTypedElementList functions that we want to expose to the scripting API (see UTypedElementListLibrary), however that is a far more reasonable burden than requring every user of the typed element framework to know and understand that UTypedElementList had to be manually cleared to avoid potentially hard to find reference leaks (especially if via leaked via scripting APIs).
The core of this change is to TypedElementList.h/.cpp, with TypedElementListFwd.h existing to forward declare the pointer types, and TypedElementListProxy.h and TypedElementListLibrary.h existing to declare the proxy type and wrapped functions used for scripting APIs. TypedElementSelectionInterface.h (and its implementations) provide an example of using FTypedElementListProxy within a scripting API, and the rest of the change is mostly just fallout to transform const UTypedElementList* to FTypedElementListConstRef and UTypedElementList* to FTypedElementListRef.
#rb Brooke.Hubert
#preflight 60d2720c634cd100016c804b
#ROBOMERGE-SOURCE: CL 16776547 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v836-16769935)
[CL 16776582 by jamie dale in ue5-release-engine-test branch]
[FYI] brooke.hubert
#jira na
#rb na
#ROBOMERGE-SOURCE: CL 16598081 in //UE5/Main/...
#ROBOMERGE-BOT: STARSHIP (Main -> Release-Engine-Test) (v828-16531559)
[CL 16598094 by mike zyracki in ue5-release-engine-test branch]
