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…
In order to control your Level Instance Data Layers, from within your Main Level, you will just need to drag your Data Layer from the content browser to the Data Layer Tab of your Main Level manually, and, again manually, recreate your hierarcky from the LI inside the Main Level. Doing so, you will be able to control your Data Layer inside the Level Instance, from the main level.
Unfortunately this is a manual operation. So if you use multiple Level Instances for you chunks, each with its data layer hierarchy, you will have to recreate it inside the Main Level Manually.
I hope Epic will make it easier one day.
this also means if you add more data layers in your level instances, or change their behaviour, you will have to do that operation twice. Once in the level instance, once in your Main level.
Another thing you could do is to turn on World Partition Data Layer Filter in within your editor settings, turn on Support Actor Filter in all your Data Layer (you can do it all at once using Property matrix on your data layer selected in your content browser). Doing so, you will see in the detail of your Level Instance, once dragged in the Main level, under the tab Filters, all your data layers inside.
I do prefer the first step, although it’s a pain in the a** to have to re-create manually in main level the data layer hierarchy from the level instances.