Download

Actor hierarchy

I need some advice about structuring my actors in a level

I am trying to make a spaceship cockpit, with lots of buttons, which do lots of different things. So far I have tried two approaches… the first was to create a Spaceship, ControlPanel and Button actors. Using Child Actor Components to put them one under another. I then made a ButtonTarget interface with Pressed and Released functions, and the button calls this interface with its ID. I added a light bulb actor to the spaceship, with the light bulb implementing the interface, turning itself on and off, but I start to run into problems around here since the button needs a reference to the buttontarget interface to call the function. Neither the button nor its parent, controlpanel, know anything about the lightbulb. I have gotten this working, but it was complex to pass the buttontarget reference to the button, and involved a bunch of get child actor and casting every time i wanted to do something.

My second approach was to make the ship, panel, and button as Actors, and drag and drop them into the level. Then I put them in a hierarchy using the world outliner. Same stuff with the interface, but this time when it came to giving the button the butontarget reference, i was able to do this very easily in the level blueprint, just by selecting the button in the world outliner, then in the level blueprint creating a Reference to it, and the same for the lightbulb. This solution is about 20 blueprint nodes simpler than the first approach, and I avoided a lot of casting and reference passing.

The only thing that is worrying with this is that construction of the spaceship occurs in the level blueprint construction graph and would get pretty long eventually. Any thoughts on either approach?

Eventually I would like to do things such as dock with an airlock, use level streaming to load the interior of a space station, and unload the spaceship as the astronaut goes inside the station, loading and restoring the spaceship state when he returns the other way. In addition, I might want to allow the player to choose upgrades, which would mean swapping out a control panel with a newer version (with more buttons which can access deeper functionality). I have not approached either of these areas yet, but can you comment on how it’d impact both of the architectures sketched out above?

53 views and no one knows how to put a few actors together?

  1. Start by making spaceship cockpit out of UMG solely etc.
  2. Make spaceship cockpit out of Actors / Meshes added to Level (construction script).
  3. Drag Actors into a Spaceship Blueprint Class (no construction script, Parented or using Sockets).
  4. Drag UMG into a Spaceship Blueprint Class (no construction script but Parented).
  5. Hybrid1: Drag UMG / Actor-Meshes into dedicated Spaceship Blueprint Class (not level).
  6. Hybrid2: Drag UMG / Actor-Meshes / RenderTargets (projected mini-screens) into Spaceship Blueprint…

You did 1 & 2 if I understood right. Maybe look at 5 or 6 and maybe even try to PM this developer.
I think the key is Quality here… How high will the bar be set??? Along with your own expectations…
The other issue is, which parts of the UMG UI require direct interaction. How complex will that be?

Thanks for the response… I don’t see where quality, my expectations, or UMG interaction feature in this question to be honest. It’s a question about dealing with references between actors and actor components, so they can call interface functions on each other.

My issue is how to best distribute and manage references from these to Actor Components which carry out the functionality, and from Actor Components to the UI elements, while still being able to create the ship or parts of it during runtime.

I’m still open for ideas…

Sounded like you were asking about how to structure the visuals before but ok…
Interfaces and Direct Comms ‘seem’ to be best the most popular for UI / UMG.
But without knowing more about your game / code set-up how can anyone say…

The 2 threads below might offer some insights, approaches…
But it all boils down to the specific game you’re working on.
For example. take a single-player or local-multiplayer game.
It probably makes sense to use Gamemode, Pawn, UI-HUDS…

Gamemode drives master logic, Pawn controls movement-weapons.
Since HUD Widget can access Pawn / Player directly leverage that…
Otherwise avoid Direct Comms, have UI_UMG_HUDs use Interfaces.
But keep game logic out of UI-HUDS-Widget just use it to Message.

#1.
General Blueprint Questions
Q: Due to casting, are there any tangible benefits to interfaces or is it better to rely on casting for inter-blueprint interaction?

#2.