Out of interest, what is the CDO and why would it give an error during the loading of a project into the editor? I’m assuming its some kind of serialization issue with a versioning system giving me the error, but I’m curious as to what the error actually stems from.
Hey there!
I recently had some issues with this as well, and was given a rather good answer by cmartell. You can read that here:
There’s also a passage about the CDO here, which explains what it is fairly well:
Hmm, interesting. I suspect with that information that the CDO properties being deserialized from disk when the project loads doesn’t correspond with the UCLASS properties built with the runtime version of the class CDO during a load operation and that is what is causing the error (so in essence an early version of the object had a field/method/property that the current version doesn’t). But then how do I clean up that serialized version such that the error doesn’t keep appearing? Bearing in mind this is during editor loading that specific project.
Unfortunately I’ve not seen anywhere in UE4 a place to “clean up” any intermediate files etc. I guess I could delete the .uasset relating to the character and start again, but that seems a tad overkill.
Its exactly this kind of situation that worries me a bit with UE4. These complex systems which are required to make the C++ manageable also tends to obscure and obfuscate their use a bit. Having the unreal build tool for example, makes it harder to debug where a build is going wrong (but of course I understand why its needed).
I’d really like some deep dive documentation on this side of UE4 for programmers. I admit most would never see the need for it, but its the arcane stuff that is deep in the bowels of the engine architecture that will likely trip up the unwary.
I guess there’s always the source code.
How early is this error? Do you have any assets defined in native code through FObjectFinders? One of the most common CDO initialization errors I get is when natively defined assets are moved – they don’t seem to follow redirectors like Blueprint assets do.
I did, however, have issues once where I’d assigned delegates too early, ending up with them being stored in the CDO and then somehow applied to all instances of that object no matter how I changed the defaults. Fixing that did require a cleanup of blueprint data:
For assets, that would be the Derived Data Cache. Even Win64 builds don’t run from source .uassets, but in order to avoid having to constantly cook assets in order to run in the editor, the editor maintains a cache of assets cooked on the fly. You can clean it up by deleting the DerivedDataCache folders from your game directory as well as the engine’s.
1 Like
When I go to load the project, the editor gives me the CDO error, so its during project load. I’ll clear out the derived data cache and see if that does the trick. Its probably when I’ve been experimenting with a class and changed its definition during some rebuild.
Actually, that reminds me. I’m curious what the different build configurations are actually meant to do and what that means for the UBT process? I’ve noticed that debugging a “development_editor” build will sometimes result in incorrect single-stepping behavior because presumably the symbols are being loaded by a different build. Do you know if there’s a document about that anywhere?
Thanks for the info .
This is normal, and symbols are fine. What you’re experiencing is the result of compiler optimizations – Development builds have optimization enabled. I’ll just repost a brief writeup I gave about compiler optimizations somewhere else:
Debug: Both engine and game in full debug. Slow as molasses, not recommended.
DebugGame: Engine optimized, game in debug. Good compromise if you find yourself debugging a lot of your game code.
Development: Both engine and game optimized. If you only need to debug a few sections of game code at a time, you can run development and surround parts of code with #pragma optimize(“”, off) + #pragma optimize(“”, on) to make it easier to debug.
Right, so its just the compiler settings for the particular DLL for the module you’re building, gotcha.
So follow on question to that, regarding the DLL and hot reload. I’ve noticed that often when I’m working on code, the editor says a hot reload has completed. However the code that was written isn’t actually loaded, its actually running a different DLL, its only updating the code that is being executed in certain circumstances (so for instance if I quit the editor and then run the editor from the debug option in visual studio). My question is, how does the editor know which DLL to load and which version is the “current” DLL? I mean ok it can check the file timestamp and reload the DLL ok. But if I switch from debuggame_editor to development_editor and recompile, how does the editor know which DLL is the current one?
Also, what is the recommended way of working with a debuggable version of the game that allows hot reload. I’m assuming debuggame_editor as the build setting and then how do you make sure that the editor is actually hot reloading the correct build version? If I run the editor and run visual studio from it, then build a debuggame_editor version, how do I ensure that the editor is going to load THAT version of the built DLL?
Thanks for answering these questions btw , very useful.
Have you managed to get this resolved? I had never seen this until about an hour after reading your post, and now it’s driving me crazy.
It also happens to me during editor startup. I cannot think of anything I had done to cause it to start happening, and now I cannot seem to find any way to resolve it. It’s possibly worth mentioning that this code was all running nicely before…
I reverted my entire project and finally got rid of the error, but still haven’t tracked down the precise cause. I’ll be adding things back in one by one until I get it again, and will hopefully know more then.