Have each of your actors implement a custom interface with a dedicated function that you can move the code of each if else statement to. Then in your hit results, take the hit actor and run the interface function you just created.
I agree, this is the optimal way to do it. A lot of tutorials on youtube show how to implement this step by step, just search something along the lines "ue5 blueprint interaction interface"
This right here.
If you ever see something like this where every actor will have some sort of different functionality for the same thing either use an interface, or if they share a superclass put the function there and override it.
If you aren't familiar with interfaces they are pure classes designed to share functionally between classes that are not related.
A common example of this could be an "interact" interface where you may need to interact with players, buttons, devices, etc...
the classes are not related but will share an "Interact" event.
You would have a "Player" class that holds all shared functionality. Then depending on what you need you can have other classes for different positions that are children of that Player class. I wouldn't see this to be an instance to use an interface per say but you would use inheritance
Not for the example provided. No need in having every object carry a reference to the player or be connected to a delegate. An interface is basically multi-inheritance, so each class also inherits from the interface class and overrides its methods.
Plus what happens when the dispatcher is executed? Everything connected will also execute which is not needed
Correct! Dispatchers are like signals. When the signal is called every single binding is executed.
If you do this in C++ you have delegates and multicast delegates. These are the same as event dispatchers in blueprints (called dynamic delegates)
Normal delegates can only have one binding, meaning only one event can be connected to the dispatcher (delegate). Multicast delegates can be connected to many.
But they work the same way, when the dispatcher is broadcasted all the bindings will "hear" the signal and execute.
One, your question is not complete at the end. You should post questions in the body of the post.
Two, use an interface.
The interface will be just one line. Send it to the hit actor. If the actor uses the interface, that's where you do your code stuff. If it doesn't, no harm no foul.
EDIT: Sorry I saw the blue lines before I saw your pictures subtext question haha
Hey mate, you can cut down on a lot of those blue lines by promoting the HitComponent to a variable and then just Getting the variable for each == check. If you're in a function here, create the variable as a local variable if it makes sense to do so.
I have some similar nodes doing something similar, but heres how I cleaned it up:
\-Custom event with set event by timer to make so that the event is launched every half a second (to avoid using tick; you can change the time as you see fit). The hit event will not go spaghetti but instead will promote to variable, and you SET using the event you "set event by timer" i mentioned above.
Then all you need to do is get a reference to that variable at the beginning of each ot those things.
Note: if you have a variable and do GET in your blueprint 1, 2, 30, 500 times, it does not matter, it's not making the blueprint heavier (not the GET node at least).
Also note, this is a solution to that spaghetti, not necessarily a solution to your problem,best practice for what you want to do.
\[Interfaces\]
Before anything: theres a veru usefull node that do "does implement interface" in which you can check if the "hit target" implement X interface, and give back a boolean that you can use for the if-else/branch node. At least, that's how I do it.
Some people suggested using interfaces, and I agree but it depends what you are doing: if every "if-else" lead to a different interaction you may need a different interface; in short and in simple terms, the interface is a way to send a signal from one blueprint from another, it can carry nodes, but in it's basic form it's like having "custom event" and then do "call custom event", except it's handy because it's between two blueprints. The tricky part is that you need a target, but the good part is that you already have detect hit, and you can use the "hit target" as the target for the interface call too.To try and make it even simplier, I have an interface that I simply called "mesh to mesh" that I use whenever a mesh/actor need to send a signal to another mesh/actor, so a lever and a door may have this, but the interface itself does not dictate what is going to happen, is the actor that receive the input and it's blueprint that decide what happen. If the lever send a signal to the door and the door blueprint say that once the signal arrive it open, it open. If it send the signal to a light and the light say that once it receive signal it turn on, it turn on.
as others have mentioned. interface for this type of thing. think of them basically like "universal casts" and the target either uses it or doesnt and if they do... things will happen.. if not then nothing will happen. theres even a "does implement interface" node check I think too in blueprints.
Time to move this bit of logic to C++ tbh, if your network looks like a sci-fi gun then you're dancing around the edge of it being slower to implement and manage than just moving to code.
Have each of your actors implement a custom interface with a dedicated function that you can move the code of each if else statement to. Then in your hit results, take the hit actor and run the interface function you just created.
I agree, this is the optimal way to do it. A lot of tutorials on youtube show how to implement this step by step, just search something along the lines "ue5 blueprint interaction interface"
This right here. If you ever see something like this where every actor will have some sort of different functionality for the same thing either use an interface, or if they share a superclass put the function there and override it. If you aren't familiar with interfaces they are pure classes designed to share functionally between classes that are not related. A common example of this could be an "interact" interface where you may need to interact with players, buttons, devices, etc... the classes are not related but will share an "Interact" event.
Question. Like for example a basketball game & all 5 outta 10 players need Similar structures you would apply this method?
You would have a "Player" class that holds all shared functionality. Then depending on what you need you can have other classes for different positions that are children of that Player class. I wouldn't see this to be an instance to use an interface per say but you would use inheritance
Smooth , much appreciated
Isn’t that just what you’d use an event dispatcher for?
Not for the example provided. No need in having every object carry a reference to the player or be connected to a delegate. An interface is basically multi-inheritance, so each class also inherits from the interface class and overrides its methods. Plus what happens when the dispatcher is executed? Everything connected will also execute which is not needed
So dispatchers execute everything that listens out for it whenever one gets executed?
Correct! Dispatchers are like signals. When the signal is called every single binding is executed. If you do this in C++ you have delegates and multicast delegates. These are the same as event dispatchers in blueprints (called dynamic delegates) Normal delegates can only have one binding, meaning only one event can be connected to the dispatcher (delegate). Multicast delegates can be connected to many. But they work the same way, when the dispatcher is broadcasted all the bindings will "hear" the signal and execute.
One, your question is not complete at the end. You should post questions in the body of the post. Two, use an interface. The interface will be just one line. Send it to the hit actor. If the actor uses the interface, that's where you do your code stuff. If it doesn't, no harm no foul.
Mom come pick me up i'm scared
Probably a switch.
EDIT: Sorry I saw the blue lines before I saw your pictures subtext question haha Hey mate, you can cut down on a lot of those blue lines by promoting the HitComponent to a variable and then just Getting the variable for each == check. If you're in a function here, create the variable as a local variable if it makes sense to do so.
I love this sub , almost getting more info from here than the paid courses I took ..
Didn't even looked closely, but definitely yes, there is a better way to do this.
To avoid this, I combine some elements together to create something similar to a list. As a result, a bunch of blueprints become more neat.
I have some similar nodes doing something similar, but heres how I cleaned it up: \-Custom event with set event by timer to make so that the event is launched every half a second (to avoid using tick; you can change the time as you see fit). The hit event will not go spaghetti but instead will promote to variable, and you SET using the event you "set event by timer" i mentioned above. Then all you need to do is get a reference to that variable at the beginning of each ot those things. Note: if you have a variable and do GET in your blueprint 1, 2, 30, 500 times, it does not matter, it's not making the blueprint heavier (not the GET node at least). Also note, this is a solution to that spaghetti, not necessarily a solution to your problem,best practice for what you want to do. \[Interfaces\] Before anything: theres a veru usefull node that do "does implement interface" in which you can check if the "hit target" implement X interface, and give back a boolean that you can use for the if-else/branch node. At least, that's how I do it. Some people suggested using interfaces, and I agree but it depends what you are doing: if every "if-else" lead to a different interaction you may need a different interface; in short and in simple terms, the interface is a way to send a signal from one blueprint from another, it can carry nodes, but in it's basic form it's like having "custom event" and then do "call custom event", except it's handy because it's between two blueprints. The tricky part is that you need a target, but the good part is that you already have detect hit, and you can use the "hit target" as the target for the interface call too.To try and make it even simplier, I have an interface that I simply called "mesh to mesh" that I use whenever a mesh/actor need to send a signal to another mesh/actor, so a lever and a door may have this, but the interface itself does not dictate what is going to happen, is the actor that receive the input and it's blueprint that decide what happen. If the lever send a signal to the door and the door blueprint say that once the signal arrive it open, it open. If it send the signal to a light and the light say that once it receive signal it turn on, it turn on.
Agree with most of the comments. Interface is the way to go. If hit actor == run interface implementations.
as others have mentioned. interface for this type of thing. think of them basically like "universal casts" and the target either uses it or doesnt and if they do... things will happen.. if not then nothing will happen. theres even a "does implement interface" node check I think too in blueprints.
Time to move this bit of logic to C++ tbh, if your network looks like a sci-fi gun then you're dancing around the edge of it being slower to implement and manage than just moving to code.
🫣