Level Blueprints make everything harder on the long run (for games).
Even testing becomes harder, even automated testing, because the way teams are used to work…
I consider Level Blueprint as bad as using “Dont Destroy on Load” on Unity objects;
Seems fine at first, but it will come to bite you later on…
Anyway, instead of writing a bible in these forums, I think it’s better to just drop these links here:
Certainly. Actors who do their own thing should have their own logic. On the other hand, if a static mesh or point light in a level needs to be played with, the static mesh or point light are not really worthy of becoming actors that do stuff on their own, so the level blueprint is plenty enough to manipulate them into whatever state they need to be in.
And when you delete a referenced actor from a level blueprint, the reference becomes unknown and are easily removed on compiler warning. It’s not that big of a deal.
But somehow, people end up on here, with a bee in their bonnet about talking to the level BP. They must get it from youtube, I’m assuming.
And even when you say, ‘don’t do it’, they will just wait until someone shows them how… and then later, come back with a nightmare on blueprint street problem… 
Well now there is a quite a bit of information here that can be useful to our homie who originally asked the question. That’s what counts.
easy as pie
My thoughts on the offtopic part
Sometimes Over engineered is just as dangerous as doing quick things, especially in the prototype phase.
After you can return here in production and if necessary create a class in C ++ that inherits a BP that has use an interface that has a plugin that looks for references in assembler. Or you could get bored of playing the game or be a boring pain in the ■■■ game and at least you save yourself some time that you could have used for something else.
Wrong
They are already Static Mesh Actors.
So making them Actors that contain a Static Mesh Component changes nothing.
Try deleting one of those actors at runtime 
There’s doing things wrong and there’s doing things right.
Knowing which is which doesn’t mean you overengineered anything, it just means you aren’t a greenhorn and knew what was right…
So that when you go back and look at it a year from now you don’t feel the sudden urge to invent a teleport machine to go back in time and ask your past self whatever the ■■■■ he was thinking…
guys sorry, i wasn’t home for a few days so I couldn’t keep up with the replies.
so it looks like in the end there was no definitive answer, once a level instance is loaded, its information is lost forever. any changes to the LevelBP of that level will affect all of those instances. which is totally incorrect.
this is the only thing that the open level instance gives u. a level streaming dynamic object reference which i dont even know what this is useful for, other than being able to unload it of course.
but why is unreal built like this? i feel like they should give u access to the level instance itself when its loaded instead of loading it and forgetting about it.
guys after digging through a bit i found a function which returns the level instance name, does anybody know if i can get a reference to the level via its name?
You can’t. those nodes didn’t exist in engine, it was submitted as source code change by Rama.
If not for that, those nodes wouldn’t be there either.
huh, that is something i see quite often in open source softwares like blender and unreal. things get added without any proper support or compatibility with the rest of the engine.
anyway regardless of that, this whole level blueprint system seems to be totally broken and unfinished in unreal imo, talking to a levelBP is only possible with event dispatchers which just makes things overcomplicated, and as far as I know this did not change or even improve in UE5.
so what other options do i have to create an infinite loop, and also have access to actors in the loop,
i wanna try portals this time, but it looks like the render quality on these render targets is quite cra*p and it just doesnt look realistic, so im curious to know if there’s any other option.
talking to the levelbp is not really a problem for me.
the combination of game mode or game instance with event dispatchers allows me to talk to any blueprint anywhere.
the problem is with the way level streaming is set up in unreal, u simply cannot talk to a level instance that was loaded at runtime, cuz if you go ahead and make some changes to LevelBP of those instances, it will affect all of those instances instead of a specific one.
imagine how horrible it would be to program in c++ without taking advantage of OOP. that’s exactly whats going on here.
they are separate its just u don’t have access to them… u can only unload them later on but that’s about it.
