I’m not sure how to solve this problem correctly, and documentation and searching are not helping me.
Let’s say I have a door actor blueprint. Door actors can be opened and closed. In one level, I’d like to use these door actors in pairs where I can flip flop which door is open and which door is closed.
It would initially be easy to create references to each of the doors in the level blueprint and maybe wrap them in a simple object that exposes a FlipFlop() method to make it easier.
What if I have 50 of these pairs of doors? Am I expected to have 100 actor references in my level blueprint, or is it possible to somehow encapsulate these pairs such that I only have 50 references to pairs of doors to deal with? Would C++ somehow help with this?
While the tradeoff of 100 vs. 50 references seems meaningless, this is a simple example that I’d like to use to boil down hundreds of actors into only a few references (e.g. X branches of Y hallways each of Z pairs of doors each).
Child actors initially seemed like a good idea, but they don’t allow for the child actors to be positioned differently from instance to instance as far as I can tell.
The level blueprint is your most basic working method. It’s almost like procedural programming. Somehow, you need to encapsulate this idea, in an object.
It sounds like here, you either need to write your door, so it understands it will have a ‘paired’ door. Or, you could make a sort of ‘double door’ blueprint, which manages both doors using the same code.
What sort of blueprint would a hypothetical “double door”/door pair blueprint be?
Maybe a dummy actor blueprint with no physical appearance and arbitrary location with two ADoor actor reference properties? If so, would I have to hard-code these actor references in the door pair actor’s blueprint?
Before I accidentally lead you waste time, if the static meshes were all inside it, could the meshes be placed different on a door pair by door pair basis, or would they always be fixed relatively to each other? If they’d be fixed, then that would be too restrictive.
Thanks a ton for your help by the way. This is a significant problem for a game I’m prototyping.
Is each door’s reference to the other hard-coded? Is it possible to instead somehow automatically generate the reference by putting both doors in a folder and programmatically fetching a relative reference maybe?
If that code controlling both actors need to be done in something that wasn’t one of the doors itself, would you just create a dummy actor that holds the code? For example, if there were five doors and you wanted to be able to call Open(nthDoor) and Close(nthDoor).
Do not use level blueprint. IMO epic should remove that, yes it has it uses, but it confuses most of people.
For door and such stuff (lights, pickups switches). Create parent actor that has all code in, then create child blueprint (inherit from that parent) and add variation like different doors, trigger methods etc.
This way you will have base object that is just door (with all logic needed) and then double door, rotating doo, cat door etc as child blueprints.
Then you place tham all in level.
And if you need some extra logic, like for eg. locking certain doors, linking them and such, that is place to use level blueprint.
Makes no sense. It’s only one blueprint. They are two instances of the same BP, so there’s only one blueprint in the folder. You can, however, easily write a BP to assign references based on distance or some other criteria.
You could put the code in a dummy actor, and give it references to both doors, but they you have more ‘stuff’… You do get the advantage of ‘overview’ this way, though.
Sorry, I meant folder in the world outline I believe it was called (or whatever the tree view of all actors is). Being able to get such relative reference to neighboring objects in that tree view comes to mind because of my time with ROBLOX, but it sounds like this isn’t a thing in UE unless I’m missing something.
One slight bug with this BTW. You’ll find, sometimes you click on a door, and nothing happens. That’s flipflop for you. If you open Door A from Door B, Door A still hasn’t used it’s flipflop node yet, and so, might generate an open event, when it should call ‘close’.
The way around that, is to not use flipflop
It will cause you other problems, if you use a save game, for instance…
Talking about removing the level BP, I was thinking another mod that could really help is disabling the tick node, until you’ve been using the engine for six months
