Files
UnrealEngineUWP/Engine/Source/Developer/Windows/LiveCoding/Private/LiveCodingModule.h

117 lines
3.2 KiB
C
Raw Normal View History

// Copyright Epic Games, Inc. All Rights Reserved.
#pragma once
#include "ILiveCodingModule.h"
#include "Delegates/Delegate.h"
#include "Modules/ModuleManager.h"
#include "Templates/SharedPointer.h"
#include "Internationalization/Text.h"
struct IConsoleCommand;
class IConsoleVariable;
class ISettingsSection;
class ULiveCodingSettings;
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
#if WITH_EDITOR
class FReload;
#else
class FNullReload;
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
#endif
class FLiveCodingModule final : public ILiveCodingModule
{
public:
FLiveCodingModule();
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
~FLiveCodingModule();
// IModuleInterface implementation
virtual void StartupModule() override;
virtual void ShutdownModule() override;
// ILiveCodingModule implementation
virtual void EnableByDefault(bool bInEnabled) override;
virtual bool IsEnabledByDefault() const override;
virtual void EnableForSession(bool bInEnabled) override;
virtual bool IsEnabledForSession() const override;
virtual const FText& GetEnableErrorText() const override;
virtual bool AutomaticallyCompileNewClasses() const override;
virtual bool CanEnableForSession() const override;
virtual bool HasStarted() const override;
virtual void ShowConsole() override;
virtual void Compile() override;
virtual bool Compile(ELiveCodingCompileFlags CompileFlags, ELiveCodingCompileResult* Result) override;
virtual bool IsCompiling() const override;
virtual void Tick() override;
virtual FOnPatchCompleteDelegate& GetOnPatchCompleteDelegate() override;
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
static void BeginReload();
private:
void AttemptSyncLivePatching();
static void OnDllNotification(unsigned int Reason, const void* DataPtr, void* Context);
void OnDllLoaded(const FString& FullPath);
void OnDllUnloaded(const FString& FullPath);
bool IsUEDll(const FString& FullPath);
bool IsPatchDll(const FString& FullPath);
private:
ULiveCodingSettings* Settings;
TSharedPtr<ISettingsSection> SettingsSection;
bool bEnabledLastTick = false;
bool bEnableReinstancingLastTick = false;
bool bEnabledForSession = false;
bool bStarted = false;
bool bUpdateModulesInTick = false;
bool bHasReinstancingOccurred = false;
bool bHasPatchBeenLoaded = false;
ELiveCodingCompileResult LastResults = ELiveCodingCompileResult::Success;
TSet<FName> ConfiguredModules;
TArray<void*> LppPendingTokens;
void* CallbackCookie = nullptr;
FText EnableErrorText;
const FString FullEngineDir;
const FString FullEnginePluginsDir;
const FString FullProjectDir;
const FString FullProjectPluginsDir;
IConsoleCommand* EnableCommand;
IConsoleCommand* CompileCommand;
IConsoleVariable* ConsolePathVariable;
IConsoleVariable* SourceProjectVariable;
FDelegateHandle EndFrameDelegateHandle;
FDelegateHandle ModulesChangedDelegateHandle;
FOnPatchCompleteDelegate OnPatchCompleteDelegate;
struct ModuleChange
{
FName FullName;
bool bLoaded;
};
FCriticalSection ModuleChangeCs;
TArray<ModuleChange> ModuleChanges;
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
#if WITH_EDITOR
TUniquePtr<FReload> Reload;
#else
TUniquePtr<FNullReload> Reload;
LiveCoding Re-instancing LIMITATIONS: 1) Re-instancing will only update UClass instance data. 2) Adding and removing properties should only be done towards the end of a class or structure and can not be followed by complex data types. 3) Adding and removing properties from a base class should not be done if a derived class contains complex data types. KNOWN ISSUES: 1) Changes to enumerations and structures will not be reflected in existing blueprints. However, adding new nodes to the blueprint will show the updated enumeration or structure. 2) If a class contains an enumeration or structure as a member, the class will not be re-instanced if enumeration or structure is changed. CHANGES: 1) LiveCodingServer 1a) Modified to always execute certain static instances during load. 1b) Modified to exclude the _Statics static structures to avoid patching to old copies. 2) Added support for LiveCoding reinstancing 2a) Refactored deferred registration system for UClass, UEnum, and UScriptStruct to use a common system that works for normal game, hot reload and live coding. 2b) Type specific version check data is possible (i.e. enum doesn't have a size) 2c) Single registration static for UClass 2d) Single registration class for all types that is just a blind forward to API. 2e) Static and dynamic registrations use different API entry points to avoid having overloaded argument lists that just apply to one or the other. 2f) Shims for older API 3) New common "Reload" system to avoid using HotReload code. 3a) Support common delegates regardless of who is reloading/reinstancing. 3b) Re-instancing code moved from HotReload to Kismet2 (where the bulk of the re-instance code already existed). 3c) Modified PyWrapper to use new helper class instead of depending on HotRelaod 3d) Added WITH_RELOAD which is defined if HotReload or LiveCoding is enabled. 3e) Modifed existing code to use new #define and delegates. Robert did the review on the changes covered by Part 2. Remaining changes are all straightforward. #rb robert.manuszewski #jira UE-74493 [CL 15736777 by Tim Smith in ue5-main branch]
2021-03-18 08:13:59 -04:00
#endif
bool StartLiveCoding();
void OnModulesChanged(FName ModuleName, EModuleChangeReason Reason);
void UpdateModules();
bool ShouldPreloadModule(const TSet<FName>& PreloadedFileNames, const FString& FullFilePath) const;
bool IsReinstancingEnabled() const;
#if WITH_EDITOR
void ShowNotification(bool Success, const FText& Title, const FText* SubText);
#endif
};