Parent actor and child specific actions?

Hi, I have a Parent actor for my interactable objects, which has a bunch of functions in it, such as a trigger box volume for showing the interaction widget, etc.

However, each child (for example a Door and a Wardrobe) should have different actions associated (for example, “Open” and “Change clothes”.

the interaction widget is generic, it’s just a 2d widget placed in the world on top of the interactable object (image 1), and the labels are based on exposed variables, set when the child actor is placed into the level (image 2).

The widget’s option button will call an event in the parent actor (ignore the “option number” thing)

image

So my question is, how do I execute the different functions/events depending on what child object I’m interacting with? should I code this in the child actor blueprint? if so, how do I send the clicked event from the parent to the child since they’re the same world object? Is there a better way of doing what I want?

When you say ‘child’, do you mean ‘instance in the level’, or do you mean you right clicked on the parent in the content browser and made a child actor?

The latter, is what you need.

You can do what you have so far, with one blueprint, and changing the variables when you drop an instance in the level. But, as you’ve discovered, that’s no good when it comes to implementation of the click call.

So when you make the child blueprint, you can set the default variable values. So every time you drag a door onto the level, it knows it’s a door, and you don’t have to set it up.

The missing concept for the actions is a blueprint interface.

So the parent needs to implement a blueprint interface. All this does in the parent is have your click event and the parameter, and nothing else.

In the children, you can override and implement a different piece of code for each child’s click event. That’s your missing piece.

BPIs can be called on any kind of actor ( you can call it on the sky ), and don’t need to know anything about how the actor works.

Yeah it’s the latter, the child actor inherits from the parent interactable actor class.

So I imagined interfaces would be adequate, but I’m not familiar with implementing them.

Should I call the interface function from the widget button click? does this look right?

widget bp:

door bp:

wardrobe bp:

I mean, apparently it works :slight_smile: so thank you so much, let me know if I’m doing it correctly

Not quite. The yellow pin means the interface is being called from inside the blueprint. Which means you might as well use a custom event.

I typed a whole load of stuff here, and had to bin it, because I need to rethink your widget stuff. Gimme 5…

And the moment I typed that, I figured it out, of course… :-/

You don’t actually need BPIs. You COULD do it with them, but you’d need to separate the widget and everything else. Not worth it.

All you need is parent and child.

So the parent has an empty custom event for each param, and the widget can call the custom events.

When you make the child, you get to implement the events. Does that make sense?

It’s generally a terrible idea to use inheritance this way. You have functionality that belongs to many different objects which don’t necessarily have much to do with each other. And at some point you may not even be able to reuse that functionality in a way that makes sense - think of interacting with a car to drive it. Now you’d have to create a separate inheritance hierarchy for that pawn to get interactions.

And it’s usually even worse than that because to drive a car you’d generally want your character to be at a location near the car that makes it possible to drive it, not just near the trunk or something. Which again shows a problem; what if an actor has multiple interactable components?

Instead, you can create an interface for interactions, and then add the necessary functions to that interface, and let the objects decide what happens when they’ve been interacted with.

That way you could also add the functionality to actor components, so you could have actors with multiple interactable parts.

1 Like

( I can drop some code in if you like… )

that was my initial logic, but that’s precisely what I don’t know how to do, how to call a child custom event from the parent (or from the widget for that matter.)

so if I create an empty custom event in the parent BP, how do I execute it within the child BP? I can’t create an event with the same name

yeah if you could give an example that would help

Gimme 5…

1 Like

yeah the inheritance is just because all interactable actors have the same sort of basic interaction, like hovering the mouse on them will show their outlines, their names (spawn the widget) and so on, but their functionality is completely different, which is what I’m trying to figure out here.

using a BPI is what I did just above, not sure if that’s exactly what you mean

So, in my parent

image

In the child:

image

image

Now the child can do something different. You don’t have to keep the parent call…

It is clicking?

Indeed! I guess that’s about what I imagined at first, I just didn’t know about overriding parent functions. It works just the same as the BPI without the need for it.

I just don’t see the brown parent function node when I create the function override, I only see the main red node, I hope I’m not doing something so trivial wrong lol:

image

I think that might be your engine version. Are you on 4.27?

Like I say, you don’t need the parent call, because it’s empty :slight_smile:

1 Like

The parent node only calls the parent implementation, much like Super:: in C++.

It’s a “fair game” to have a GenericInteractable base class for interactables if it significantly lowers your workload for highlighting interactions, it has some benefits to it like bulk editing them, and as long as the calls are still made in interface it leaves the ability to do more complicated interactable objects and the objects it is used for are generic enough.

1 Like

righ yeah, just googled it and realized how to get it back and what’s it for

so I guess it’s working all good now, without the need for interfaces, and I still have the option to use them should the need for them arise in the future when I have multiple actions per object.

so thanks again! :smiley:

1 Like