Download

Simple help needed on actor and component hierarchy

I need some basic suggestions on how to build a hierarchy of actor and components.

I want to have a cockpit, with controls which the user can interact with. The player will move their motion controller to hold the joystick and throttle, then let go to press a button or pull a lever on the control panel.

So far, I have a Pawn, which contains the cockpit mesh as the root node, a camera (locked to HMD) and two motion controllers with collision spheres:

9d478b3a9973a9e4352072f7beb0f9dfc1f59d61.png

(The VR Recenter and HMD Default Position are just to allow a “Re-center camera” function)

As you can see, I have also added a joystick too. But here my problems begin. I could do with some suggestions on the best way to organize this.
At the moment, I have an OnCollisionOverlapBegin in the EventGraph for the Pawn, and I cast to BP_Joystick to see if the collision sphere is intersecting the joystick. This doesn’t seem right, since I’ll end up having to cast for every interactable object just to find which one it is. It seems smarter to have the target object detect when the collision sphere is overlapping it, and respond appropriately… thing is, in the Joystick EventGraph I don’t know how to get a reference to the collision sphere. Maybe my VR hand should be a Scene Component or Actor Component blueprint since I’ll need to make it more complex later anyway (with meshes and different grips and so on). Another problem I see looming soon is that I’ll want to grab the joystick, and move it, so the motions of the motion controller need to go to the joystick somehow. It seems best to have that logic in the joystick rather than the pawn, no?

I could really do with just some basic suggestions on how to organize the fundamentals of interactions between my hands/motion controllers and component blueprints for my cockpit controls
Thanks!

I don’t understand why to keep joysticks as a child actors? I’d bind Overlap Events to LCollisionSphere and RCollisionSphere components and cast overlapping actors to your BP_Joystick and keep it in a ref variable.

But the better way to do it is an interface. Create an interface with functions like BeginOverlap(Hand Component), EndOverlap(Hand Component), ControllerButtonEvent(Button) and inherit it on joysticks and any other actors you need. Then on (L/R)CollisionSphere overlap events cast overlapping actor to this interface and call a corresponding function. And, of course, override it in BP_Joystick. On this way you’ll be able to add many interactable objects without changing your player pawn blueprint. I also usually add ‘left’ or ‘right’ tag to hand colliders.

Ok, thanks. I will experiment with interfaces, sounds reasonable.

Why would I not keep the joysticks as child actors? It keeps everything tidy. What is the alternative, having everything as components in the pawn? I would end up with tons of functions and variables in the pawn which shouldn’t really be there… Have I misunderstood the point of child actors somehow?
My ultimate goal is to have lots of interactable controls making up the control panel, and I would like to very easily reuse them between vessels, so I thought making child actors was a tidy way to do this. I cant tell if this will scale well or not yet…

If I understand the idea correctly, the alternative is to keep them as an absolutely independent actors attached to your cockpit, not a pawn. You can keep references to this actors in blueprint variables.

The pawn IS the cockpit (really, the entire ship, pilots chair, controls, external mesh, engines…).