Materials and textures redone for the main mesh and the handguard mesh - the new material has customizable wear and dirt, separated masks for metal and polymer parts, etc. (the other meshes will also get updated materials of this new standard on future updates). A few examples of what can be done now with the new material (these instances are included with the update):
Incorporated the sight alignment code from the Gun Sight Auto-Aligner, which means now there’s no need for the Aim anim sequence and the AimFire (fire while aiming) anim sequence. (The previous alignment method used was the precursor of the Gun Sight Auto-Aligner asset).
An IK was added to the right hand, so now both hands have an IK.
Added a debug external camera for checking hands/arms position.
Changed method of identifying the gun’s main mesh. Now, instead of giving the component a specific name, you give it a specific tag.
Material and textures for the FlipSightRear were redone in the new standard.
Fixed: if weapon had different fire rates for different fire modes, changing fire mode would change fire rate but not play rate of the fire anim.
Fixed: on-screen tip about input keys for jump and fire (WB_DemoHud blueprint) were missing their respective keys (this would generate message log errors when playing in “New Editor Window”).
Added: Suppressor attachment.
Known current issue: crosshair will not hide properly when the aim down sights button is pressed during a very short period of time (a few milliseconds) while blending at the end of the Equip anim sequence. This is due to the respective transition notifies in the State Machine not getting fired in this situation. This will be fixed.
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.
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!
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
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.
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.