I’ve been using UE4 since it was realeased, so, I’ve seen the first version of the engine. At the beginnig, HotReload could only support .cpp files reloading. Then, it supported .h, and a lot of things.
However, while compiling with HotReload, I could see a lot of bugs, such as Blueprints which override C++ hot-reloaded classes. But, in the last version of UE4 (i.e. UE4.10), I haven’t seen this things anymore.
But, habits are habits, and every time I make a big change in C++ code, I close editor, wait 5 seconds so UBT doesn’t compile for HotReload, and then, recompile.
Is this habit a bad habit? I mean, should I only use VS HotReload, and never use VS compilation ? Won’t this impact performance, or stability ?
Thanks !
(Oh and, BTW, will there be an engine-code HotReload in the future? I mean, a way to don’t close the editor even if we modified UE4’s engine code ! )
Personally Hot Reload never really worked for me. I just gives me errors (mostly bp). So I always just close the editor and compile, but that’s just the work flow i’m used to.
I’m in exactly the same boat - stopped using it because I didn’t trust it not to introduce time consuming false bugs, and now I realise it probably is reliable enough to use more but can’t change my habits.
There’s no doubt frequently restarting the editor is a hassle though, so I’m going to make an effort to try using hot reload more and see how it goes.
I’ve tried not to close the UE4 Editor, for about 40 minutes. My only issue is, when reparenting a C++ class (I mean, making a c++ class inheriting from another C++ class), it crashes the editor. I experience this when I reparent my test weapon class, to test the automatic weapon class or the semi-automatic weapon class.
But, so far, that’s the only issue I’ve had, at least in 4.10, so, I think HotReload is quite stable now, I agree with you, Gwenn
You must follow some rules before HotReload:
Save Everything and do not edit anything during the compilation or you may face issue once the new dll is loaded
You can’t hotreload changes on Uproperty/Ufunction.
Out of that, it’s working well and it’s a time saver ^^
I’m on latest 4.10 version.
The only issue I’ve had with hot reloading is that it doesn’t play well with changes to structs, the objects get renamed to Original_HOTRELOAD or something like that and things tend to break, blueprints sometimes stop recognizing that two structs are the same, things like that. Other than that, it’s been pretty stable for me for a long time on both Windows and OSX.
My machine takes 5 seconds to open the editor if the map has few actors; so I code within a small ‘test’ level map and just open/close the editor, I don’t use this thing; I can’t trust it, generates a lot of extra binary files and has many issues for what I do.
As with any Hot Reload, you should stick to a few rules. Changing the Structure/Signature is always the thing where most hot reload implementations fail (At least in Eclipse when coding java, eclipse tells you when you changed the structure and should restart the VM, instead of just…crashing ).
For changes inside functions, its more than stable enough, and this is the time the hot reload is most helpful, i.e. while debugging something, seeing a minor mistake and immediately fixing it, continue debugging, etc…
But i can understand that its not easy to change habits that you had for the past years
I guess it depends on what you do - Blueprint interaction can always fail in some way.
For a full-C++ project though, it’s arguably flawless today. Even (carefully) changing the structure of a data asset works with hot reload without breaking the assets, something that was essentiel to us since most gameplay data is stored in assets like these.
I haven’t upgraded from 4.9.2 yet but it’s pretty buggy here. API changes require me to close the edit before I can save again (Otherwise I get complaints about transient/engine or something) so too bad if I had unsaved changes in Blueprint. Changed variable names get replaced by hotreload_324132432 or something similar.
If it’s true that it’s much more stable in 4.10 I look forward to it when I upgrade, but until then I think I’ll stick to the safe method of closing the editor before a recompile.
Pretty much in the same boat. Usually if I use it with header changes it ends up crashing the editor. For CPP changes it works but from time to time if I save assets (not just UMG widgets) they fail to save. Very rarely I get UMG errors when attempting to play after a hot reload.
).