There’s a talk from from epic that covers the loading and multithreading. You may want to give it a look as it clarifies some stuff and probably references the actual project (which may not be the rpg? I’m 90% sure it was, but I don’t recall tbh).
in short, you want to set up a proper multithreading system (which i would assume both level streaming nodes and world comp do, but you really never know unless you poke in the source). To ensure Async loading of levels and the management of the transitions.
Maybe we take multithreading for granted, since if you weren’t able to compute several things at once you would have crazy slow loading times… really not sure. I know that implementing your own custom c++ saves you a lot of trouble.
I think we all agree that the system built by epic could be improved upon - one thing everyone complains about and even released games have is the texture streaming causing visible pops after/during initial load.
like you said, there is no way to know how long a delay should last ad the time it takes for the proper textures to pop up will vary depending on the PC or system in use (can always bench the lowest end you have and go with that time delay though. People with better pcs just wait).
Re the manual loading. It’s kind of important and you should poke around with it.
mostly, as I mentioned, you use it to load interiors. Generally with a streaming volume or some such. Depending on things occlusion is just not enough to get rid of stuff you don’t see. So being able to load/unload the clutter and insides of a house can be a good performance improvement. Would all depend on your mem/cpu budget too, and it is something you can and should refine once the level has been setup properly… though setting up the underlying system for it and just building into it might end up saving you time.
And on doing the world composicomp’s job. Yes, well, if you want to optimize things you’ll have to anyway. In fact, whatever you write may end up being far more reliable then the built in system since it would be specific to your use case. That’s why I mentioned that you can literally take the code from Epic and re-work it for your needs…
My suggestion is to store the current level name at load. You can then easily perform other operations as well as check if it is loaded.
your code works for finding a name, but just committing the name to memory in the first place would be better.
Again, can epic produce better ways to do this? Yes.
Will they? Probably not…
I think you should drop that part of the argument and just figure out what best works for your project (not you, each project will need different load/i/o handling).