How does one go about constructing this in unreal 4? I’m aware on how to target friendly players, but I have no idea how to link a beam emitter to two players, and how to add health to whoever is connected to the beam… Any help with this would be greatly appreciated! Thank you!
I would go about it like this. You can do this with the same third person template in ue4 with the same pawn blueprint for the friendly character also.
-
Add a socket to the skeletal mesh of the friendly character. This socket’s location is where the beam will be target once you establish the link. Name it anything you like, for example, “BeamReceiveEnd”.
-
Add a function or a custom event in the friendly player’s blueprint that will incrementally add a health variable, say “AddHealth”.
-
Use the LineTraceByChannel node to make a single line trace from the weapon’s muzzle to the friendly player. This will give you two vector points - start point(which is your weapon’s muzzle) and the end point(where you’re line trace ends).
-
Break the hit result, get the hit actor and cast it to the blueprint of the other friendly character you are targeting.
-
This cast node will return a reference to the actor. Using this reference variable, you can do two things.
-
You can call the AddHealth function which will keep adding health. This will take care of the health bit.
-
For the beam, you will need to use a particle beam system, with variable source and target points. Search for ue4 laser beam particle weapon or something and you’ll find plenty of tutorials covering the beam particle system.
-
The beam particle system takes two vectors, source and target which can be specified during run time.
You can use any beam particle system. There are plenty of tutorials on making targeted lighting weapons and variations of laser beams which would serve the purpose.
-
Once the particle system is setup, you have to specify the source and target vectors. For the source vector, get the location of the weapon’s muzzle, mostly using the GetSocketLocation node. Use this vector location to set the beam’s source using the SetSource node of the particle system.
-
Now, from the reference variable you got from casting the hit actor(friendly player) in step 5, use a GetSocketLocation and specify the name of the socket “BeamReceiveEnd” from step 1. This node will return a vector, which will be our particle beams target point. Set the beam’s target point using SetTarget node of the particle system.
Once all that’s done, hook up the system to your main fire input or any alternate input of your choice.
So the other end of the beam is called the Target. It’s a module in the particle system, similar to the Source. The same way that you set source using a set source node, you can set the Target also.
Although, now that I think of it, it may not update as the other player moves. Because the setting of the source and target happens when the input for the fire is given, so you’d have to find a way to set the target for the beam dynamically during runtime.
I haven’t tried this of course, but I can suggest a few ways to do that.
After the 5th step,
5.1. Promote the returning reference variable of the player into a local variable. This way you’ll be able to access the friendly player’s location and such anytime after you’ve fired the beam once.
5.2. Add in a custom event and have it do the runtime updating of the target vector of the beam. To do that, access the reference variable of the friendly player, get his skeletal mesh component or something, get the socket location using name, and this would be the target location.
5.3. Use the Set Target node of the particle, and set the location from the previous step.
In your event tick, add in a boolean if condition to check if you’ve currently fired the weapon and if the beam is active(say using a bBeamIsActive that gets set to true if fire input is active), if it is, then call in the custom event from step 5.2 to update the target location of the beam.
Once you release the fire input, assuming it’s the left mouse button, set the BeamIsActive bool to false to not call the custom event cause it would get heavy on a tick function to do it unnecessarily.
I’m happy to help of course, but if you still get stuck, I’d suggest checking any lightning weapon tutorials on YouTube. Lightning or even laser beam weapons. I’ve tried a similar mechanism in the past and these are the steps I recalled from doing that. Good luck! 
No, sorry. I haven’t experimented with navmesh a lot yet. Only used it to make some primitive AI’s move about the level but that’s just it.
Thank you for responding! I followed your directions, but got stuck on step 4/5. I’m not sure why, but I’m unable to attach the end of the beam to the players specific socket. I’m not sure why. I’m casting to the specific player, and connecting to the socket name, but I still can’t seem to get the end of the line trace to connect. 
Perfect! I’ll look into it when I get home. Much appreciated! On a side note, you wouldn’t happen to know much about moving actors in a straight line through space (Both X,Y, and Z [Disregarding the Nav Mesh]), do you?
I got the staff working! Thanks a ton! Here are the results…
[Caduceus Staff Progress][1]
Though I am able to heal friendly players now and draw a beam to the player that’s being healed, there’s still a bit of functionality with the beam itself. Once I break the hit with the actor, the beam stops healing. I have an idea as to why this could be happening… I think it’s just the order of the logic within blueprint… I’ll post it here so you can have a look at it.
Thanks again for all your help!
I’m happy to help!
It looks really good and pretty interesting. I took a look at the blueprints and the functionality you described it was lacking. I guess you’re talking about this particular issue Mercy Debugging - YouTube in your video?
In that case, what is the order of event calls you’re making from EventTick?
From what I could deduce from the blueprints, I think that the line trace is happening once and not every frame. And your beam is probably set to a duration of 3 seconds(I sort of approximated it from the video every time you broke hit with the friendly character). So every time you break the hit, the previous beams take about 3 seconds to time out and disappear. So it looks like the beam is active and it should continue healing, whereas it isn’t active and the healing function is probably not called. I can’t be certain about what I’m saying here without actually debugging it step by step though.
So if the beam’s duration is set to be visible only for one frame, it would probably be easier to debug knowing visually when the beam is active and when it isn’t.
Assuming that is the case, I think what needs to be done is this.
-
Once the lock has been established, we need to check if the input fire or input alt fire is still active and being pressed by the player.
-
If it is being pressed, and if the player breaks the hit, then we need to set a new source point of the beam every Tick call. So that even if you break the hit, or move to a different position, the source point will be updated every frame. If it is not pressed, then you can deactivate the beam of course.
-
Furthermore, if the other player moves, I think right now with the setup you currently have, the beam might be broken unless you continuously aim at the player and establish the hit again.
-
So along with the mechanism in Step 2, you can additionally update the target point of the beam also to update every frame.
I think you can do the above steps using a custom event called by EventTick which would check all the bool variables you already have, and if the input is being held down and then set the source and target dynamically. I sort of pointed out where I think the custom event could be in the blueprint screenshot, but of course, I am not aware of the order of events called by the EventTick so that’s really up to you.
Let me know how it comes along. I’ll be glad to see it functioning fully! 
Ran out of characters in this comment so I just posted it as an answer instead.
Once a user has established a connection with a friendly player (Unit A), the only things that should break the beam is if the player releases the input trigger, dies, or is an “x” amount of distance from the friendly player(Unit A). If the player is looking directly at another friendly(Unit B), but still has the initial connection with Unit A, the beam will remain connected to Unit A. I’ll try implementing your recommendations when I get home!
Sure. Looking forward to it.