From a purely organisational perspective I really don’t want to have an open world containing all my props and assets because I feel like it will become a nightmare to manage in the future.
To this end I want to be able to split large chunks of the map (e.g., buildings with interiors) into separate Level Instances and then drag them into the open world level. To make it more performant and add quests stuff I was planning to use Data Layers defined in the Level Instance. I wanted the data layer to be defined in the level instance because that’s where the assets are stored so it makes sense to have the toggling logic there too.
However, from my research i’ve found that the engine can’t see the data layers from level instances and from testing I can’t toggle them, it just throws an error saying the data layer can’t be found. Additionally, the on-load logic to hide/show the data layer isn’t honoured by the engine.
Is there anyway to do this or am I forced to create the data layer in the outer world instead of the level instance?
You would probably be better off making your own custom ** And Async ** loading system that loads up levels pre-packed with whatever you need.
To load assets within a sub level you would need a different something in place that manages that portion specifically.
If you were to build out a recursice class, then the class type could be re-used to generate whatever loadong events you want to curate - if you make it into an interface, then you can implement the interface into whatever object (like an actor that contains other actors) and load stuff in clusters.
Its preferrable to letting Epic dictate how things load. Since usually its a good example of what not to do.
But its also overkill on like 90% of the projects you deal with day to day. Which is partially why epic isn’t releally interested in fixing the loading system(s) or anythjng that isn’t expressly for fortnite.
Used to be, you just had to make your own thing anyway because there is generally no guarantee that the level finished loading and has collisions in place unless you test that they exist and delay the loading screen removal until you know for a fact.
As an extention to that, you’d usually set up distance based loading via custom triggers (fill a room with props when near enough).
Data layers were a decent way to hijack something that was partially working into something that worked at the time.
You could just extract their cose and fix it up for your nesting needs…