i’m creating level instances on an overlap trigger to give the illusion of an infinite world, but how do u talk to the level blueprint of those levels? is it even possible?
It’s much easier to just put an actor in the level, and talk to that 
But isn’t that gonna affect all levels? It’s gonna be an infinite train.
If it’s an infinite level, you will be streaming sublevels. That means you can keep the actor in the persistent level.
obvioisly not, im just looking for a way to manipulate those levels which are spawned at runtime, is there any other way i can do that?
like for example turning off some lights which is an actor in the level or moving stuff in the level that the player is CURRENTLY in and not the previous one or the next one. which I cant do that with the level streaming reference.
The Level Blueprint shouldn’t exist.
Avoid to use it unless you’re working on cinematics, not games.
1 Like
I don’t disagree, but I’d like some more info on why it shouldn’t exist?
@bumbumgoesnuts
Literally the second answer.
Make an actor, call it “manager” when the level loads, look for all actors of class. find it. cast to it. and change what variables you need changed.
It’s much cleaner in the end.
1 Like
Side-question: I use BP-interfaces in all my stuff, with a standard one being to simply return a reference to the object itself so I can use that vs casting.
I was of the understanding that casting is most-expensive vs an object-reference, hence my use of object-references as much as I can. I this still considered a best practice? I mean, I can see where sometimes you can cast once and grab a reference, but I was always of the opinion that not casting at all was ‘most optimal’.
As for the level-blueprint, my 2cents was to use an actor distinct from the level. eg: the level doesn’t have a skyphere, skylight, etc; I have a weather-controller actor that spawns what I need for a given level based on parameters I feed it. I have a basic collection of ‘environmental-actors’ to control the sun, sky, fog, etc and they self-initialize on start; pulling their settings from a data-table based on a level identifier.
Thoughts?
Yes.
Not necessarily. you’d have to bench performance of the interface system and it would vary system by system.
We use interfaces for ease of use rather than performance.
It’s also access via a “call” vs Direct Access. Direct access can be faster. It depends on how the interface system is actually implemented (never really looked at it).
Yes. make it one actor that controls everything.
There will eventually be a limit to how many actors you can have on the scene depending on the hardware and it’s memory.
Having too many of those actors could end up compromising things some day that you want to release a Switch build or a Mobile one.
So, there’s no reason not to aggregate the actors into one. (and you could even do that and release it as a marketplace asset since there isn’t many out there that do it. and even less that do it right).
Clockwork Ocean slightly explains to us how to think about world references.
This is a matter of understanding how communication works in the world. A persistent level should only communicate with persistent actors, not other levels. Other levels exist to communicate with the actors that are within their own levels. There is no reason for a persistent level to communicate with other levels. When you stream in a level, the other one can be unloaded and it its existence no longer matters.
A level automatically has a reference to every actor placed within the level, so the persistent level does not need to know anything about that stuff.
1 Like
A persistent level actor can communicate with streamed actors, as long as they both aware of this
1 Like
Yes, that would be the cherry on top. Actors in the persistent level can communicate with streamed actors, so the persistent level doesn’t need to. The persistent level really doesn’t need to do anything besides initialize the game.
Good luck finding the correct actor reference XD
That’s exactly why Interfaces make for ease of use here.
Otherwise you need to recursively check outer - total waste of computational power too.
The only other decent alternative is gamplay tags. Basically limiting the number of actors you get a response from by using a level named gamplay tag on them…
No, that’s not necessary. A level has a reference to every placed actor. You don’t need tags to reference them because you can click on an actor, enter the level blueprint and create a reference of it. I made that mistake of tagging things when first trying to understand level design. FInding references to level actors is incredibly easy.
We are talking about coding.
Getting the reference from Get all actors of class or similar within another instanced actor.
Because as stated “level blueprints shouldn’t exist” even if I want an elaboration as to why.
I think we’ve all been talking about coding for the entire time. I’m wondering why level blueprints should not exist when the designers of the engine made it the primary way to get references to actors without the need to use the get all actors of class node. The level blueprint is probably one of the best things that you can use to do anything within a level, lol.
@BrUnO_XaVIeR
Hear that?
Lol
Honestly never looked under the hood of level BP, but fairly sure there’s other reasons aside from this:
It’s lazy and prone to breaking, as well as it leads to bad practices.
Self contained actors are really the way to go when it comes to reusability.
A prime example would be deleting an actor you put a reference to in level BP.
All the code using that actor will error out and need to be escaped…
Please do add more cons.
Like I say, there’s a lot of utube rubbish out there, all about:
-
Level BP
-
Tick
-
Cast
-
…
Lazy? I’d say no, but it may lead to bad practices, sure; it’s so easy to get a reference in the LB even though you’ve yet to wrap your mind around OOP - so tempting to just plop a node down.
A prime example would be deleting an actor you put a reference to in level BP.
Go ahead and destroy them. Dispatchers care very little about that. But, obviously, the logic is encapsulated in the actors. Nothing stops one from having the LB instantiate dynamically without storing hard references, bind what’s needed and forget about them. When the level goes away, so do the actors.
Also, very little actually stops you from talking to the LB using the framework:
Also, I hate LB. There I said. Avoid it if you can. It has its uses, sure. Just put stuff in the actors.