Newly installed versions of the engine will now attempt to copy the project-agnostic config settings from a previous engine installation. This happens by way of a versioned manifest that copies old versions when the manifest does not exist, or is a different version. This code path is benign for non-installed versions of the engine (or FPaths::ShouldSaveToUserDir() is false).
EditorGameAgnosticSettings and EditorUserSettings ini paths have been renamed to EditorSettings and EditorPerProjectUserSettings respectively to better convey their purpose. In general, most settings should be saved in EditorSettings (project-agnostic) so that they apply regardless of which project is open. We have some way to go migrating existing settings for this to be the case, however.
Some previously per-project configuration files are now project-agnostic (such as Editor.ini, EditorKeyBindings.ini, and EditorLayout.ini)
GEditor->Access...Settings and GEditor->Get...Settings have been removed in favor of direct access of the CDO through GetMutableDefault<> and GetDefault<> respectively. Global config ini filenames that are not set up are now neither loaded nor saved on build machines, to handle the problem of indeterminate state more generically.
This addresses UETOOL-270 (Most editor preferences should be project-agnostic)
[CL 2517558 by Andrew Rodham in Main branch]
#jira UE-11645 - Changing UPROPERTY() settings causes detail components to vanish in editor
#reviewedby Phillip.Kavan
[CL 2514339 by Richard TalbotWatkin in Main branch]
References to hot-reloaded class are updated in blueprints (before recompiling and reinstancing).
I guess it could be optimized if necessary.
#codereview Robert.Manuszewski
[CL 2478024 by Maciej Mroz in Main branch]
We already had FPlatformProcess::CreateProc/CloseProc pair (which is part of larger set with WaitForProc(), TerminateProc(), GetProcReturnCode(), etc). FProcHandle::Close() made the API more confusing (and actually introduced bugs, because it did not call CloseProc() until recently).
#codereview Josh.Adams, Robert.Manuszewski, Jaroslaw.Surowiec
[CL 2476322 by Dmitry Rekman in Main branch]
All children classes are recompiled before any object is reinstanced.
#codereview Nick.Whiting, Robert.Manuszewski
[CL 2451921 by Maciej Mroz in Main branch]
Stopped the "Compiling C++ Code" message in the editor MainFrame always having a cancel button
FModuleCompilerStartedEvent now passes a bool to say whether the hot-reload/compile operation is being run async, or whether it's blocking. We now only show the cancel button for async compiles, as the UI is otherwise blocked waiting for the compile to finish.
Added a bWaitForCompletion input parameter to DoHotReloadFromEditor. This mirrors the RebindPackages API that DoHotReloadFromEditor internally calls, and prevents UPackFactory needing to perform a manual tick.
[CL 2437789 by Matthew Griffin in Main branch]
Made sure that FHotReloadModule still reported slow task progress while stuck in a busy loop
ReviewedBy Anderew.Rodham
[CL 2435569 by Matthew Griffin in Main branch]
Fixed failed C++ hot reload not displaying an error to the user (UE-8241)
- Also added slightly better progress reporting to hot reload when adding code to a project
[CL 2419709 by Ben Marsh in Main branch]
* Multicast delegate Add* calls now return FDelegateHandles, and Remove* calls are now all deprecated, except for a new Remove function which takes a FDelegateHandle.
* New FConsoleManager::RegisterConsoleVariableSink_Handle and UnregisterConsoleVariableSink_Handle functions which work in terms of FConsoleVariableSinkHandle.
* Timer calls which don't take FTimerHandles are deprecated.
* FTicker::AddTicker now returns an FDelegateHandle and is removed by an overloaded Remove function.
* DEFINE_ONLINE_DELEGATE* macros now define _Handle variants of the Add/Remove functions which return/take handles.
* Various other handle-based registration changes.
* Some unity build fixes.
* Some simplification of delegate code.
* Fixes for lots of existing code to use handle-based registration and unregistration.
#codereview robert.manuszewski
[CL 2400883 by Steve Robb in Main branch]
- When hot reload was invoked from the IDE, the editor would not reload all of the game modules if there was more than one module had the game name as part of the module name
- For example after compiling "VehicleGame" and "VehicleGameLoadingScreen", only "VehicleGameLoadingScreen" would be reloaded in the editor
#codereview Robert.Manuszewski
[CL 2391306 by Mike Fricker in Main branch]