I have 4x6 World Partition world with 2x2 km cells and some functionality in my game is critical to loading the actual number of actors on the proper cells (of course, only 9 cells are loaded, on the edge cell - even 6, not the whole world). Here is the logic how the game waits this loading:
But this macro takes a very long time, in my relatively fast computer - several minutes.
@ClockworkOcean @Everynone, which can be the problem, at least what to start check from?
EDIT: at first, I thought that the problem was in the heat, but when I directed a powerful fan right to the GPU, the loading time did not reduce. Does this mean that the heat is not the root of the problem?
1 Like
Sorry, I have no idea what is happening there 
Maybe lay it out in a more obvious way, then you might see a problem?
Hello @ClockworkOcean! Has now become fewer spaghetti?
But I doubt that the problem is in this macro. I think some actors brake the loading of the game world via the huge loops in the BeginPlay. Is it credible?
1 Like
Thanks for un-spaghetti-fi-ing a bit 
But I still donât get it. It looks like youâre loading 3 things? ( there are 3 bools ), but if itâs not all loaded, you wait a second, then mark the bools as false again?
Can you explain what this macro is supposed to do? How itâs supposed to work?
It checks if there are loaded three key actors (they serve as markers of loading the world). If they arenât, the macro checks the same after a second of delay, then again and again with a second interval. But it is NOT actually loading the actors. I have accelerated loading the actors by near 9% via merging some actors. Is this not an illusion since those actors did NOT have logic and were just the static meshes. Can the reducing of the number of the actors actually accelerate the world loading if the quantity of the triangles and the logic remains the same? Or is this just a fluctuation?
1 Like
OK, with you.
I assume thereâs only a small number of grid actors, but a large number of âgeneralâ actors.
I would change that âget all actors of class( actor )â, and give it a specific class to look for. Something that there is, ideally, only one of in each level.
âGet all actorsâ is well know for slowing everything down. But if you specify a class, the system uses a hash, and can find them immediately.
What means âgrid actorsâ and ââgeneralâ actorsâ?
I donât think this will change the situation significantly, because âGetAllActorsOfClassâ checks all the actors in the world regardless of the specified class.
1 Like
This difference
Thatâs the point, it doesnât, if you specify a class.
But how do you imagine getting the actors of the specified class without checking all the actors? Does the engine store the maps âclass - actors listâ? Or is there some other way?
1 Like
If you look at the source code, part of the level data is a hashed list of actor types. Its like an index for actor types.
Try it
Hello again @ClockworkOcean! I have figured out that the problem has been in the Navmesh, removing it accelerates the loading uncomparably. I have Navmesh 8x8 km, maybe it is huge? How to improve its performance? Or, maybe, it is possible to generate Navmesh in runtime, only in the necessary cells (since it is something like building space which has 1600 potential cells but only several actually occupied)?
1 Like
Ah, good
I know pretty much nothing about navmesh, sorry 
I found a way to destroy the navmesh in the playing modes where it is not necessary (if who is interested - check for the appropriate mode, get actor of class RecastNavMesh, destroy it, then get actor of class NavMeshBoundsVolume and destroy it, too). The world is now loading much faster.
1 Like
