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).
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.
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.
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 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
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:
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.
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 thank you so much, let me know if I’m doing it correctly
