Which normally are the best by using the viewport editor / foliage tool.
However, each design will function more like a block, which I will spawn as a Blueprint so I can create an endless camera ride of sorts. (and in general I can’t have it being a level, rather an object that needs to be spawned/destroyed/)
So all the design has to be collected into a single blueprint.
Until now I doing each block already as a Blueprint actor to begin with, but that takes longer and is less intuitive (also I can’t use the foliage tool)
Is there a better way?
Meaning to somehow design everything in the main editor, then convert it properly to a blueprint, maintaining foliage as instances etc?
What you can do, is just use the provided world partition system, which will automatically load and unload things as the camera flys over.
Or you could use level streaming with similar effect. You can load instances of streaming levels, at any transform. So you could piece together a random type of world.
If by blueprint, you mean you want to automatically create varying terrain, you’ve really got your work cut out.
By blueprint, I just mean to design a “piece of jungle”,
so mixing a floor mesh/various trees/rock meshes etc
I currently do that manually with
1- manually places instances in a blueprint
2- automatically creating instances in the construction script
3- adding instances along a spline
But the foliage tool is way quicker with these types of things,
also the whole placement is via Blueprints so I can’t see the final result until I am in play mode.
My whole approach here is not very game-like, that’s why I have to find workarounds.
The user is switching between various designs, so I do that with Spawn/Destroy.
Therefore it has to sit in a blueprint, also since each jungle-block (or each design in general) is normally spawned along the horizon to create an endless drive.
The speed a blueprint loads, depends on the complexity of the blueprint.
A streamed level will load more slowly, the more items it contains. It can take anything from .1 sec to 30 secs or more to stream a level. It really depends what you’ve put in it. Smaller levels will generally stream faster.
You have to control it yourself. You can’t communicate with anything in the level until you’ve streamed it. It’s not a blueprint, it’s a level.
■■■■, so that cancels this approach.
Too bad because it’s so much easier to design within the level, but I have to access parameters/arrays/etc in order to control things in realtime.
You can access that stuff, just not through the level reference.
What do you want to get?
If you have a blueprint in the level, once you’ve streamed it, you can do a ‘get actor of class’ and boom - you have the reference.
And before anyone says anything, yes, you could write that blueprint so it registers it’s own reference with the game instance, and then just pick it up from there. Blahblahblah…
I thought that ‘get actor of class’ isn’t super cost-effective.
That’s why I used “make array” to gather the actors (for example in this case they are LED screens) into an array (in the correct order that I want)
Then, from the main level, I want to call the screens and run events within them, like control the emission intensity.
Some actions I do with Event Binding, but some with Arrays + for each loop
Some of the things I need to control within the sub-level’s elements
1- Those rock-screens are Blueprints and they open/close
2- Each screen has intensity/material parameters
3- triggering Niagra’s systems within the level on/off
4- turning lights on/off
