I’ve only started using UE4 with C++, when I’m searching through forums everyone seems to say that hot reload is broken and don’t use it etc.
But my suspicion is that the reasons hot reload breaks are known to really experienced UE4 and C++ devs, and once people have a deep understanding they’ll know how to avoid all the problems that cause it to break.
Is this the case? I’ve come from a different large code base where people thought things would break randomly, but there was always a specific reason. Or does it really just have a lot of different random failure modes?
It breaks when you change the structure of a class, so you add a method or variable. You have to relaunch the engine. It works fine as long as you are just changing logic within a function. Personally I just run out of Visual Studio and don’t even worry about hot reloading, that way I can get all the debugging info if something crashes or step through various methods.
Pretty much what ExtraLifeMatt said. The issue I’ve seen is for any Blueprint related stuff. So if you add a new function or a property defined in C++ that you have exposed to Blueprint will need a restart if you have opened that blueprint in the editor. If you have not opened said blueprint in editor than I have found the hot reload works fine. On the other hand, If you just change the contents of how an already established function works it’s no problem. The issue is more of a problem with how Blueprint Works than hot reload.
Also instead of hot reload I highly suggest using Live Coding, it is in the experimental features set but I was using it way back on with 4.18 when it was Live PP and didn’t come standard with the engine like it does now. It will change your development life. The ability to compile while you are still playing in PIE and have the functionality change in real time is just an amazing feature, to debug your game without having to relaunch it in PIE is a miracle of modern development. It still has the same limiation with blueprints as Hot Reload but that live compile is an amazing feature.
Awesome thanks so much for the clarification, that makes perfect sense and lines up with why it’s failing for me a lot, I’m doing constant structure changes and blueprint edits while I’m learning how to extend all the different classes.
BY GREAT ZEUS’ BEARD!!!
I just tested Live Coding and it works! This is truly incredible! I cannot thank you enough for pointing this out. I feel like the gates of heaven have just opened before me!
Is there an event I can implement in my AActor subclass, or something else I can do to trigger certain things to rerun? Otherwise, I still have to close the editor and relaunch it for it to pick up changes are done when something is constructed. I’d settle for even a hacky event that I can subvert with some temporary code just to be able to refresh my actor with the changes after a hot reload.
Thank you for taking the time to reply. It was super helpful!
If it wasn’t clear, I am already in agreement that constructor is the wrong place. That is why I posted to inquire about possible events or other methods that would enable me to redo work in response to a hot reload.
Thanks for being a great helpful member of the community.
My apologies for not being useful, I guess that I completely misunderstood the point. Since your object is already constructed, and already loaded, I’m not aware of any particular event that would be triggered on a Hot Reload/Live Code update … I’m curious, though, about what sort of changes you make that would require you run some kind of initialization?
You could hookup some sort of notification event called from a blueprint custom event, then use console to trigger it? there might be a better way, i’m feel like i’m not entirely following
When adding fields to classes, you don’t need to relaunch the engine.
Pressing the “Build” button will rebuild, and re-load your DLL, and have the new class available.
(This is without “hot reload” – just using the regular button-based build-reload.)
After doing that 100 times or so, you may run out of DLL handles or something, and need to re-launch the editor. It will clean up unused re-build DLLs when it re-starts, and sometimes there’s an impressive number of them!
In general, I don’t use “hot” reload because it wouldn’t give me anything I would need. Once I know what I want to do, there’s code to write, and somehow staying in the middle of game state, and then reloading my updated code into this old game state, never really felt all that compelling to me. I guess that’s my “secret”
I was already desperate on this and my workflow was to close the editor on every compile. Now going into C++ again and it is really annoying to close the editor for each compile, just to avoid any corruption. I have a lot of blueprint interaction, so I compile quite often and want to test, if things work. Costs time and system resources and ís a torture for the disk drive.
I will try to proceed with blueprint editor tabs closed for any possible affected blueprints as you suggest. I’m still not sure, if this will be a solution - still testing. For now it works. I did have corruptions with components only shown with a purple symbol on left in Components tab - only solution was to remove the component and redefine + set all parameters again…
If it is just some missing change that needs an editor restart (caused by adding new UFUNCTIONS/UPROPERTIES) - well, that’s not a real problem - just need to be sure that no data is lost.
But I had corruptions event with simple changes as well if I remember correctly. Still testing, how things go.
The LiveCoding also sounds very interesting - need to check. But it is experimental - so should I trust some experimental thing if even stuff that’s in place since several years does not work?
In my honest opinion, it is probably more reliable than the built in Hot Reload. Live PP was built not with just Unreal Engine in mind, but general C++ development. The principles behind the two are probably very similar but Live PP is probably bit more mature because it had a dedicated team working on it before Epic/UE4 integration, that was what they did for a product and focused on.
The Catch about using Live Coding is if you (like me) need to have multiple editors (and projects) running, Live Coding highjacks the compile pipeling for Unreal on a global level. So the problem with that is if you have two projects; Project A has live coding enabled and Project B does not. If you Launch Project A first from Visual Studio you would not be able to launch Project B from Visual Studio (you can still click on the .uproject or run previous build). But if you launch Project B from Visual Studio and then Project A then it works fine. Basically there are a few minor inconveniences still and who knows when they will actually get around to hammering them out. I’m also not sure Live Coding is considered “experimental” any longer but it is off by default.
Something I wanted to share in addition:
I wondered, why my changes did not appear after a hot-reload and found, that when doing code for a Plugin, you need to use Window > Developer Tools > Modules. From there, you can recompile your module.
