Hi everyone, I’m a self-taught beginner. I’ve been working for about a year on a small project of mine and I came across a problem that I can’t figure out how to solve.
I have a system of interaction with objects through a line trace by channel and an interface that recalls the action when the actor is hit. I would like to be able to interact with actors who have multiple meshes that move individually inside it, for example: a table with 2 drawers, a wardrobe with 2 doors, a keypad with 12 button.
For now, I make it work by creating an individual actor for everything I want to move,
(For example two actors drawers leaning against a mesh desk) but when you get to the push-button panel with 12 actors buttons and a display created with a widget I think my method leads to an excessive waste of resources.
Is there a way to get my line trace buttons hit inside my blueprint actor individually?
yes, in that hit return struct where you get the hit actor, you also get a “hit component”. Plug a print string on that and you’ll see that you are able to identify individual components within an actor.
Then you just need a way to identify these components. Perhaps you give them a tag or map them with an enum. Then you could say, “on hit → get hit component → get tags”, or “on hit → get hit component → find this component in a map and get the associated enum → switch on enum”
the benefit of enum versus a tag is that you are protected from typos.
If you use interface, you probably have each component implement a function in the interface that returns some way to identify them. Like a function called “GetComponentType” and maybe you have an enum that is returned for each type of component that you are looking for.
Tags is less setup but you just have to be careful to type the same exact string, and if you change it one place have to remember to update elsewhere.
If you have some collision sphere or something like that which is larger than all the other components, you might always hit it first. In that case you have to use custom trace channels to filter out what you don’t want. But first thing you can do it just use print string to report the Overlapped Component and test to see if that is working as you expect.
What you see in the video is the result I would like to obtain using a single blueprint actor.
Currently it works well (as you can see) but they are 2 drawer actors placed on a static mesh table.
As I said previously this is not bad as long as there are 2 drawers or 2 doors, the problem is when there are 12 buttons as in the video below.
Are the buttons static meshes? If so, extend a static mesh, give it data, dispatch it back to the keypad. You could do it without extending with tags but you may want something more elaborate.
Yes I press them with a trace.
No, they are not SM, this is the problem, I can only make the pressure execute and send the command to the widget if I use them as single actors.
Let me show you the part of blueprint of the keypad
I know it shouldn’t work like this but it’s the only way I’ve managed. (everything works, dial the number, if wrong it notifies you and if correct it carries out the action, such as unlocking a door or something else)
Now you have a single actor, with a bunch of buttons, each reporting something else. You can script behaviour into each button. Animations for example. Do note that components cannot own other components - you cannot have a timeline inside each button, for example, or text render.
Hence me asking the questions to determine the scope of what is needed.
You can attach those smart static mesh comps to anything in the world. The actor these are attached to may not even know about it. If you fire a BPI that return data at this comp, you can communicate with it directly.
These are somewhat crude, things can be scripted better providing we know what features are needed.
Definitely a less cumbersome approach than using Child Actor Components who are rather horrible to work with. Much smaller memory footprint, I believe. If you combine a timer with a curve, you can get a pretty smooth frame-independent animation without using a heavy-duty timeline. But you can have one or more in the actor, ofc.
Do note, that you can do the same with Skeletal Mesh Components - each can have sophisticated animation(s) it can play. Perhaps there’s is kitchen drawer that gets stuck and rattles. We all have one. You can do the same to widget components, too.
Think of these as of modular pieces you build actors out of. Each component contains extra data and logic inside. It has its limitations but is much lighter than an actor. And much more versatile.
Inheritance is supported here, too. You can build a bunch of default BPI behaviours into a base interactive component, and then extend that further, thus minimising the amount of script needed.
Thank you, thank you so much! You were very good at explaining everything and I was able to put it into practice in a short time. I didn’t know about Static mesh components, which I will now also use on other actors.
Below is the implementation of what you taught me. (even if rudimentary and without graphic details)
The chest of drawers can have any number of these drawers: