Shooter Gun System

Won’t that make the aiming less accurate?

That’s a good question and that’s why I haven’t decided yet if I should implement this or not. From a realism perspective, I can claim it won’t be less accurate because shots will always be going where they would IRL while the sights will also always be pointing where they would IRL, considering I make the dot move to where it would IRL when the sight moves. For ironsights I don’t even have to do anything. It’s going to be harder to aim with ironsights, since the front post won’t serve as marker for the impact point anymore when the gun is swaying, but I will claim that this is exactly how ironsights work IRL and any deviation between the impact point and your sight point will be the same deviation that would happen IRL. Another thing that will make it harder to aim for both ironsights and dot sights is that aiming will no longer be 1:1 with mouse movement, since it will be decoupled from the camera. That’s why I’ll have to think of another kind of sway, because the current sway would make it feel like your aim is mouse accelerated.

Now this kind of change would make this asset less appropriate for skill-based flick shooters. For those, you really want some reliable marker on the screen all the time that will move 1:1 with your mouse. So that kinda holds me back when I think about implementing this, but honestly I’m gravitating more about taking the more realistic/tactical route than an arcade flick shooter route with this asset. I would really like to hear feedback, specially from owners of this asset, would they feel ok with this, because I personally feel the gains would outweight the losses.

Saw your auto align asset and then your gun. Decided to drop in and see what you had planned then saw your questions.

As someone who is a firearm junkie, and a developer who sells assets for UE4 I will give my advice here. Arcade style “games” are practically dead. Even COD uses more realistic gun handling now. I have never had a customer ask for more arcade features but constantly get requests for more sim features.

In modern games, bullets should ALWAYS fire from the muzzle as it keeps people from being able to just barely aim the camera (sight) over an object and fire safely while the actual muzzle is buried in a box or wall or something. This brings complications as you have to use zeroing. For raytraced bullets this isn’t such a huge deal as you can adjust the zero based on the cameras line trace and then fire the bullet from the muzzle to that point. But with projectiles people think they run into issues but in reality they don’t. Guns in the real world use projectiles and are only accurate at point blank and their zero. They shouldn’t be accurate at all distances.

The systems I have always designed worked like this.

Line traced bullets: Initial line cast comes from the camera and goes out to the hit point, As long as that hit point is greater than 2M then you align the muzzle to this point blank and fire the bullet in that direction from the muzzle. If it is less than 2m you just fire straight from the muzzle with no offset. This isn’t 100% realistic but its simple. In other words, aim the muzzle where the sight’s zero currently is and then apply your spread.

Projectile bullets: Initial line cast comes from the camera and goes out to the “Point Blank”, then you align the muzzle to this point blank and fire the bullet in that direction from the muzzle. Again its not realistic but in the real world guns are actually held aiming slightly upwards to align with the sight. For games we need to swap that for simplicity. In other words, aim the muzzle where the sight’s zero currently is and then apply your spread.

Hybrid System: Within 30m use hitscan method, if not hit then use projectile. This is great to lower network issues as you are firing less projectiles in CQC combat. There is also no reason to use a projectile <30m.

I uploaded an attachment that shows what I do. Yes I use the Red X method simply because its much easier and requires less hassle. The player will never notice the difference as the amount the muzzle gets canted upwards is relatively small (that image is an exaggeration). The first place the projectile crosses the “Line of Sight” is called point blank, the second is the zero point. For this example a scope zeroed at 200 will only be accurate at 50 and 200 using a correct projectile system.


I also use dynamic zeroing based on the type of sight. Hipfire I change the zero between 15m and 30m based on what the camera trace hits (hipfire zero is a **** shoot because of the horizontal offset). Ironsights and Red dots/holo sights I zero at 50/200m. Scopes I zero at 100m. You can allow the player to do their own zeroing but even in games that have it (BF and PUBG) people almost never change their zero. You could zero everything at 100 but you will always be shooting low <100m with Red dot sights in that case. Its up to you to decide that trade off. General public knowledge of how guns work is so low that some people flat don’t understand why their 50m zero is shooting over the enemy’s head at 100m. Pubg got around this by zeroing everything at 100m i think.

The most annoying thing with zeroing and projectiles is that you have to manually zero your weapon sometimes. Though if you have your drag, speed, weight and gravity settings right the “Point blank” zeroing method gets you really close (still might have to do some manual muzzle tweaking). The issue you will find with point blank zeroing is a 100m zero pretty much has no point blank due to the trajectories flatness (top zero in the following image is 100m for an example).


Its fine to have a small amount of animation sway in the idle animations but the actual sway system should move the CAMERA not just the gun. It should be script based and not animation based. Look at PUBG or COD for sway systems.

Anyways my long winded answer with way too much information to your question is to always try to make your guns as realistic as possible. Unless you flat don’t want to which is fine too :P.

Quick question though. If I use your gun align system on a tps character with no FPS mesh and used per bone blending for just the arms would it work? If I recall I also need to switch from tps camera to the FPS camera BEFORE allowing your system to aim for it to align correctly?

Good luck with your asset, I really dig your auto align system. Very cool.

Hey, thanks for all your suggestions and taking the time to post them with pics and all… From interactions with customers, I have the same impression as you, people seem to dig more the realism/tactical side of shooting than the arcade side. Now regarding the implementation, I have to say I wouldn’t do things like hybrid trace/projectile systems or auto-zeroing… I prefer a more direct approach: only projectiles and fixed or manual zero, or for a more arcade style, traces only…

Now, regarding your questions:

It’s hard to say without testing in your specific setup. I think it wouldn’t break the alignment, but that really wouldn’t mean much. I have experimented a little with this asset on a whole body mesh, and I can say that, while it’s relatively easy to preserve alignment and everything looks good while you’re in FP view, from an outside view the pose is broken and unusable. And it will take a good amount of time and effort to make it usable. And yes, you’d have to first move the camera to FP position before starting to aim (because an outsider would see your arms chasing the camera while it’s moving still), but that would be the least of your problems. It’s safe to say this asset, in its current state, doesn’t work for third person games and you should only try to work around this if you’re really willing to put a good amount of effort.

This is a recurring request from customers (which I think goes back to the point of most people preferring a realistic/tactical approach), so I feel tempted to actually take the time needed to include that in both my assets, it would probably boost the sales. But right now I can’t.

Thanks for your kind words… I don’t own a VR set yet, but it’s in my wish list. As soon as I get one, I’ll check your asset!

Updated to v1.3.2

Change log:

  • Fixed a bug included in the last version (1.3.1) where using other anims instead of the provided ones would make the transition form hip to aiming down sights very jumpy. It was due to an accidental unchecking of a checkbox in one of the CopyBone nodes in the anim blueprint.

  • Other minor fixes like text tips on screen, etc.

  • Included, in the product page, a link to download a playable demo

Updated to v1.3.3

Change log:

  • All first person anim sequeces were reimported. The new sequences have the hand IK bones (ik_hand_gun, ik_hand_r and ik_hand_l) stationary at the default position (Epic’s default pose). The old sequences had ik_hand_gun and ik_hand_r match hand_r position, and ik_hand_l match hand_l position every frame. This change was made to avoid blending problems when adding user custom animations. It makes no difference if you use all sequences with the IKs in the default position or all sequences with the IKs matching the hand bones, but a mix of sequences of the two styles gives blending problems. Since most custom sequences out there leave these IK bones stationary at the default position, now they can be mixed with the asset’s own sequences without blending problems.

  • Removed custom object channels and trace channels (collision) presets from the Project Settings, because they were unecessarty.

  • Not all CopyBone checkboxes were fixed in the last update, which was meant to fix them. Now they all were fixed.

Updated to v1.3.4

Change log:

  • The cosmetic gun rotations (sway) due to player input now only use the aimpoint as pivot when aiming down sights. When not aiming, the rotations use the hand_r bone as pivot, like it was before v1.3.1, because it looks better when not aiming.

  • Fixed an issue that would prevent animations from being played correcly if the semi-auto mode was set as the starting fire mode.

Hello, did you have an tip for me how two create that weapon swinging with the animation movement? I bought youre Kit on the Marketplace but need some more explanations how i could set this in a first person project in (The blank Project from Ue4 First Person). Which code is only two built for that ? An how could i Implement a Weapon Reload Animation for the Weapon? I am trying two juse other weapons like one from Ironbelly. It Would help me a lot. Youre code is very good but hard two understand.
Please write me back.

When aiming, the gun position at each frame is determined by the two variables IkLocationAiming and IkRotationAiming (in the 1st person anim blueprint). IkLocationAiming is the exact location of your sight and IkRotationAiming is the exact rotation of your sight. They are calculated each frame in the event graph of the anim blueprint, from the camera position, and applied to the gun (actually to the character’s hand) in the anim graphs of the idle and walking states (the only two states in which you can aim). If you want to make the gun swing, I would first try generating an offset (a vector variable) each frame to add to IkLocationAiming in the event graph. But from your question, I think what you want is a sway that’s not calculated, but comes from the underlying anim sequence instead? I think you will have to try using a CopyBoneDelta node, to copy the original movement from some bone to the hand or hand IK bone. Since I never implemented these kind of sways before, I’m sure they will require a good amount of testing and work.

This question I did not understand…

You mean animating the gun bones or the character bones? For the character, you just go to the gun’s blueprint and change the ReloadEmptySequence and the ReloadLoadedSequence variables (in the “Customization - Animations” category) so they point to your own anim sequences. If you want to animate the gun bones instead, currently the project doesn’t have good support for that. That’s because the gun actor component is currently treated as PoseableMesh instead of SkeletalMesh (but the gun mesh is still a skeletal mesh). This will be changed in the near future. With the PoseableMesh replaced by a SkeletalMesh component, a reload anim could be implemented by importing a reload sequence to the gun’s skeleton and playing it when the character plays it’s own reload sequence.

Hello, i have another Question. How the Character run with a server. I read about it in the AnimBP from the First Person? What i have to do to set an BP_Character with the running from a server on it? Sorry for my bad english but the logic only confuseing me a bit.:o

The AnimBP only does the animation. When you press Shift, the InputActionRun in the B_DemoCharacter blueprint is called on your machine, and this sends an RPC to the server (ServerRun). In the server, this RPC changes the MaxWalkSpeed of the character movement component. The MaxWalkSpeed is a variable that comes already with the Unreal Engine’s character and is automatically replicated, which means that when we change its value in the server, the new value is sent back to our client. The RPC also changes our variable IsRunPressed to True on the server, and this variable is also replicated back to the client. But this is a RepNotify variable, which means that every time it changes, the function OnRep_IsRunPressed is called (on server and clients) and inside this function you will see the code that tells the AnimBP (1st person and 3rd person) that IsRunPressed is now True. The AnimBP will then enter the state “Running” if the character is moving while IsRunPressed is True.

But on the client we don’t wait for these two values to arrive from the server, we go ahead and change them on the client before they arrive, so our character doesn’t feel laggy. When they arrive, they are set again but you don’t feel it because the values are the same. It’s just that the server must have the final decision. So please tell me if this answers your question.

It is. I be one of the types how wanna learn from these codes i sell on the Marketplace. I create a clean Project an wanna set it up as you code it. But my endresult is confuseing me.Look at the pic. I dont know why the character an the weapon aint communicate with eachother so that the weapon Spawn in the Hands an the animation get played from the anim_bp.

Look in the B_DemoCharacter blueprint, there is a macro called EquipWeapon. It’s called every time the variable CurrentWeapon changes (OnRep_CurrentWeapon is the function that calls it) and inside of it you will see the code that attaches the weapon mesh to the character’s socket and the code that tells the AnimBP which anims it should use inside the state machine.

You mean ‘purchase’ instead of ‘sell’, right?

Sorry for my bad english. Thank you for the help. Thank you.:o

In response to a question by Ctrl in the product page:

As a quick and dirty test, I’ve done this in the character blueprint. Z makes you instant lean left and X makes you instant lean right:

This is the result:

Updated to v1.3.5

Change log:

  • Updated to Unreal Engine v4.24

  • Small change in the method of calculation of ironsights. It now uses the node FindLookAtRotation followed by roll adjustment, instead of the dot products, RotationFromAxisAndAngle and CombineRotators nodes to find the direction from rear sight to front sight. The new method works better with the change implemented in v1.3.1 (since v1.3.1, the old method would let the rear sight a bit off depending on its location on the gun in relation to the front sight)

Updated to v1.4.0

Change log:

  • The name of the product was changed from “BP FPS Assault Rifle” to “Gun Assembly System”, to reflect the fact that the asset now allows building other guns too instead of being restricted to the original assault rifle

  • Implemented an UI widget (WB_Armory) that allows players to build guns with parts provided by you

  • Guns are now made of individual actors attached together, instead of components of one single actor

  • The gun mesh component isn’t a ‘PoseableMesh’ component anymore. It’s now a ‘SkeletalMesh’ component, with it’s own anim blueprint. This means the gun blueprint now can be used with any mesh, since it now doesn’t need to have the bone names hardcoded in it

  • Removed the option to use a HUD optic reticle as if it was the gun sight reticle. Now only reticles placed on the gun sights themselves are used, which avoids the need to set individual movement limits for each gun in order to prevent reticle being drawn in the air outside the gun sight. HUD reticles are not needed anyway, since the sight auto alignment already centralizes the sight’s aimpoint in front of the camera

  • The HUD widget functions that get the player input keys (for showing them on screen as tips) now don’t execute every tick anymore. Instead, they now only execute once at game start

  • Replaced the 3rd person anim montages with 3rd person anim sequences

  • UnEquip and Equip anims won’t play anymore when player tries to switch weapons if there are no weapons to switch to

Hi @PeaceSells_

I am wondering what kind of animations are you using for ADS? Have you done it in Maya/Blender?

Hey @bigfatblunt,

No, there are no ADS anim sequences. The anim blueprint gets the idle anim and procedurally move the hand bones to the right place, so the sights get aligned. This gives us the freedom to use virtually any gun and place virtually any sights anywhere on the gun, without having to make ADS anim sequences in Maya/Blender, etc. for each of them. You just need to make a normal idle anim for each gun.

Updated to v1.4.1

Change log:

  • Fixed: lack of smoothness when cycling between sights while aiming. Before, the interpolations were done through a Timeline in the character and the resulting values were applied in the EventBlueprintUpdateAnimation of the anim bp. Now everything is done in the anim bp, which fixed the lack of smoothness.

  • Deconflicted keys for rotating the gun and opening the customization menus in the Armory. Rotations are now done with the right or middle mouse buttons, while opening the menu is done with the left mouse button. This prevents opening menus accidentally while trying to rotate the gun.

  • Implemented an interface in the HUD for developers to adjust on the fly the max angle allowed for gun sights to be used for aiming (Developer Tools widget). Some guns have rails underneath (and in other places) that allow the placement of sights, but sights in those places yeld ugly arms poses when aiming.