Download

Shooter Gun System

This reply refers to v1.2.2 of the asset, which was before the implementation of replication. So, for v1.3.0 and forward, this reply is outdated!

In reply to Harri665 from the asset page in the Marketplace:

Add all the code highlighted in blue. This will insert another gun in the Inventory when you press T. It is added to the last position in the Inventory.

Updated to v1.3.0

Change log:

  • Implemented replication (1st iteration)

  • Included Epic’s SK_Mannequin (entire body) with animations, aim offsets, etc. for the purpose of testing replication

  • Implemented simple crouch mechanics (1st iteration) for the purpose of testing replication

  • Included simple shot impacts and gun muzzle effects (particles) for the purpose of testing replication

  • Generated LODs inside the Unreal Editor for the parts of the gun that are static meshes (not yet for skeletal meshes)

  • Added angle limits for the cosmetic gun rotations, to avoid the HUD dot reticle being drawn out of the sight lens at extreme rotations

  • Updated to UE4 v4.23

In reply to Harri665 from the Marketplace questions section:

Find this code in the B_GunProjectile blueprint:

If you want all cubes, make this modification:

If you want only some cubes in the map, click on each of them them in the map, go to the Details panel, Tag section and add the tag “Hitmarker”:

Then go back to the B_GunProjectile blueprint and do this modification instead:

I suspect that these cubes are not what you really want, so please tell me if you have something more specific in mind!

Is the character class contain 2 meshes one for fps view for owner and one for multiplayer or its running on a single mesh?

Currenlty it’s running two meshes, one for 1st person view and one for multiplayer. In the future this might be changed, but it wouldn’t be in a near future though…

Check this thread in the future, every change log is posted here, with links in the first post.

Updated to v1.3.1

Change log:

  • Tweaked the auto-aligning and cosmetic gun rotations method. It now uses less nodes and is easier to control, since now the location/rotation of the sight’s aimpoint is directly controlled by a bone (sight’s location/rotation is the same of the bone).

  • Aiming is no longer a separete state in the state machine. In order to allow for variable aiming down sights speed, aiming is now implemented through BlendPosesByBool nodes inside other states.

  • Added customization variables for aiming down sights speed and cycle between sights speed.

  • Added customization variables for the amplitude of the procedural animation for firing while aiming down sights.

  • Fixed the issue of crosshair not hiding properly if the aim down sights button was pressed during a very short period of time (a few milliseconds) while blending at the end of the Equip anim sequence.

In reponse to Schytheron from the Marketplace page:

This asset has, besides, auto-aligning, much more stuff: fire modes, reloading (with animations), switching weapons (with animations), inventory, sprinting (with animation), customizeable gun materials, etc. It’s a weapon system, so it’s much more complex. The Gun Sight Auto Aligner has just the auto aligning part of this asset, so it’s aimed at those who already have their own weapon system and only need a solution for aligning sights. It’s not that much cheaper if you consider proportional amount of content (the BP FPS Assault Rifle has much more stuff), but its lower complexity will probably make your life easier if all you want is a gun sight aligning solution.

The only customization included out of the box for recoil is the amount. It works by adding pitch to the controller (thus, the camera) at each shot, then removing all the pitch it added once you stop firing. The amount added per shot is the customizeable variable and it doesn’t include any randomization (all randomization is in the spread). In order to create more complex recoil, I suppose you’d have to include some randomization and duplicate the code to yaw/roll too. You’d have to try on your end… That said, I can help through Discord, support thread, etc., if you encouter problems.

This is because it currently lacks any code to check fire button pressing intervals. It’s something that I might implement in the future (not near though), and I can’t promise…

You are able to adjust the sway for hip-fire and ADS individually and per axis for each one. You had the impression that they were the same in the demo because the values for hip-fire and ADS were left indeed very similar, but they are actually slightly different and separately configurable. But you actually never need to worry about moving the mouse too fast, because the ADS sway intentionally keeps the front post of the iron sight always in the center of the screen to serve as aiming reference 100% of the time. If it’s a dot sight, it’s the dot that’s kept in the center of the screen 100% of the time. Since shots come off from the center of the screen, you are always able to aim regardless of how fast you move the mouse and regardless of if it’s an ironsight or not.

In the future, I might change to shots that come off from the actual barrel, but if I do, the gun sway system and specially the dot placement will be revised to also behave realistically.

If there’s anything more you want to know, don’t hesitate to ask.

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.

image_174700.jpg

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).

mainqimg54a6d253d83ee2159d258ded42ec95a3.png

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?