I made my own GunBase so I could have multiple child actors from it so i could swap between different weapons. But now I’m not sure how to make it shoot the direction the player is facing.
Hi @swagriley25,
Try use GetActorForwardVector . This will give you the facing direction of an actor.
I did that and now im pretty sure its just spawning at 0,0,0
Is your projectile (PMC) using Initial Speed or Velocity?
The spawn location and rotation of your projectile takes quite a bit of calculation ahead of time before you spawn it. Otherwise, it just spawns seemingly arbitrarily in the default location and rotations.
With that being said it depends a lot on how you are configuring your player/actor setup to fire. Are you doing first person? Third person? First person is a lot easier than third person. 3rd person takes 2 or more different line traces to get the right directions and results depending on how crazy you want to go with it.
On a basic level you can split that Spawn Transform pin and use a location of a component on your pawn for the start point.
The X, Y, Z values would come from something like Find Look at Rotation with a start location of a scene component on your player. The target would be another vector variable you can set from a line trace.
Getting the line trace to fire straight out from the player isn’t easily explained through text and I wouldn’t be able to explain it here without writing a short book lol.
There are loads of tutorials on how to do that easily on YouTube though.
Only takes 1 for 3rd person. It’s the same as hip firing for 1st person.
Try a “Make transform” node connected to your firing socket’s location and plug the rotation into a “get socket rotation” node so that your projectile fires forward out of your gun. If your gun is oriented in the direction the player is facing, that’ll work fine. If not, you’ll want to use the “get player camera manager” node and branch off of that with a “get camera rotation” or something of that regard and put that in the make transform node instead.
Try a “Make transform” node connected to your firing socket’s location and plug the rotation into a “get socket rotation” node so that your projectile fires forward out of your gun. If your gun is oriented in the direction the player is facing, that’ll work fine. If not, you’ll want to use the “get player camera manager” node and branch off of that with a “get camera rotation” or something of that regard and put that in the make transform node instead.
You need Base Aim rotation and Camera manager → camera location for Server (multiplayer).
I guess I do mine a little differently in 3rd person. I could see it being done with one when using projectiles only.
I usually sequence a line trace drawing from the middle of the viewport forward a certain distance to create a vector and then fire another from the player’s muzzle forward to that first vector so the crosshair and the character’s muzzle point of view line up correctly and the weapon doesn’t fire out of the viewport but directly in front of the muzzle.
I have a hybrid projectile/line trace system setup so that’s not really applicable here.
This is pretty much what mine does. Projectiles spawn at the muzzle. All shots intersect with the crosshair.
Seq Then 0 gets the base vectors etc to project a forward position down range. Then adjust it to come from the muzzle to that point.
That is a pretty clean setup. I’m not using the player camera manager in my case. My projectile/line trace setups are different than some of my others, but for one case here in this picture I use this to setup the transforms and rotations and feed then into the spawning logic for my projectiles.
For multiplayer Base Aim Rotation and Camera Manager camera location are needed on the server for accurate positioning (sync).
None of my projectiles are replicated. I do client-fakey server auth with projectile pooling. Each Proxy of the simulation fires its own projectile. Basically a client-side prediction approach.
Clients does a local only, server does an authoritative for hit detection/dmg/destruction and multicasts the aim velocity vector to sims to have them fire a local.
Each proxy handles animation, fx etc. Each has it’s own projectile class and Obj Pool.
Complicated, but the bandwidth is extremely low and its client/server performant. Hardest part is handling floating point precision errors.
It’s very cool to hear other approaches to firing mechanisms as I don’t see it discussed thoroughly in the forums especially in multiplayer. It sounds pretty similar to my approach with the client/server side of things.
It sounds like I have rotations and pitch replicated a bit differently and separately from the firing since I’m not using base aim rotation, but it generally seems to arrive at the same point.
To keep the server load down, I basically allow the player to decide all of the firing directions and line traces using the replicated pitch and rotation values and validate the hits from the hit point back to the player to prevent cheating. There is a caveat to this as I am at an impasse with the validation as I have large player counts in my game. The server is already loaded with replicated physics-based pawns and calculations like aircraft and vehicles also so I generally have to sacrifice some validation so I can reduce the server hardware footprint and save money. However a beefy dedicated server can handle pretty much anything, but with a cost deficiency lol.
But referring back to the projectiles and not digressing too much from the topic, I use this firing setup to feed the values into the spawn actor function on both run on owning client and server/multicast so the start points and projectiles are in sync.
I spawn two separate copies of the projectile with a parent child relationship with identical projectile movement properties. The location, pitch and rotation values are fed in with the values from my function above.
The server-side copy is simply a multicast visual with a mesh and particle effects, audio and stuff.
The client-side copy is where the damage magic and calculations occur. It’s an empty invisible collision with the same server projectile movement that basically communicates back to the player to fire a separate damage system at the hit location when it hits wherever.
It’s bandwidth requirements are nearly nonexistent as the server is really just spawning a very simple actor executed by the client that gets destroyed upon impact with a particle effect and a client executed server/multicast explosion at the hit location. That is with an “explosive” projectile.
The bullet projectiles are a lot less intensive as it’s just a mesh and an impact particle and decal devoid of an elaborate explosion particle system.
I use a number of client-side requests since I’m tracking a ton of different stats and things in real time and use the server to validate parameters such as projectile types, damage values, damage types and other stuff. Essentially like the teacher at school asking students to show their work instead of simple answers, but I digress lol.
Cheers!
Sounds good. 
I pass a client data bullet config to the server. The server determines its own values for the shot and compares against clients. If legit (within margin of error) the server requests a projectile from the pool.
Dmg apply hit detection is 100% server. It’s all managed in the Servers Bullet Pool to offload the logic from the projectile. Same applies for Penetration.
All great information and I like the bullet pool approach. I will be adding a similar function in the near future and could certainly benefit from the cleanliness of passing a structure along for the projectile requests. Especially when it relates to easily balancing weapons and making small changes to all the properties of the requests. It does get tedious without the consolidation.
