Changing Projectile Movement mid air / Ballistics Mod

[Ravuth]

I am in the process of making a simple ballistics mod for FNV featuring a basic velocity decrease, bullet drop and wind deflection but I need some help as I am farely new to scripting. If you see any errors in my code (just segments will be portrayed here) please let me know. Skip to "QUESTIONS" if you just want to see the part where I need help and don't need to see my long explanation.

 

I use precalculated Drag Coefficients (saved in an ini file) for velocity decrease which is used for a linear velocity model as it is easy to implement. The velocity decrease will then be applied as following:

set fProjDistance to rProj.GetProjectileRefDistanceTraveled/70
set fProjSpeedMult to (1-fProjVelCoefficient*fProjDistance)
rProj.SetProjectileRefSpeedMult fProjSpeedMult

As you can see I used SetProjectileRefSpeedMult to achieve a velocity decrease and GetProjectileRefDistanceTraveled instead of something time related as I have poor hardware and therefore need consistency and what can I say, it works splendid ingame showing consistent results and little to no fps drops regardless of how many bullets are rendered.

The scripting could've almost ended here so I headed to the second part of the mod, bullet drop. I thought that'll be easy and nothing more but changing the Gravity in the Projectile Tab to a precalculated value, mostly smaller than 0.9. Oh boy was I wrong. When I was testing and shooting I noticed an excessive bullet drop exceeding like 2m at 150m which is far from what I expected or would've been the case in the game without my script. So I tested it with a different Gravity Value of 0.1. No change, still noticing a drop of at least 2m at 150m. Same goes for a value of 0.01, 0.001 and so on. After all those results I set the Gravity Value to 0 and tried a different approach adding Movement Functions and precalculated Gravity Coefficients:

;Bullet Drop
set fProjFallHeight to (fProjGravCoefficient*fProjDistance*fProjDistance)
;Vertical Line of Sight
set fProjStartAngleX to rProj.GetStartingAngle X
set fProjStartAngleSinX to fSin fProjStartAngleX
set fProjStartPosZ to rProj.GetStartingPos Z
;Vertical Line of Sight - Bullet Drop
set fProjPosZ to (fProjStartPosZ - (fProjDistance*fProjStartAngleSinX + fProjFallHeight)*70)
rProj.SetPos Z fProjPosZ

The Bullet Drop section should be pretty self explanatory, like fProjSpeedMult fProjFallHeight is hardcoded to the fly distance of the projectile for the reason of consistency. fProjFallHeight will then be subtracted from the Vertical Line of Sight. However this method is somewhat broken as well. While it works just fine and as expected when hipfiring or aiming through a scope, it is completely unusable with iron sights and it does not work with every projectile. The Projectile is either off center and/or spawning far below the barrel.

 

QUESTIONS

Either:

How do I change the Projectile Speed mid air without using SetProjectileRefSpeedMult ?

Or:

Is there a way to implement bullet drop without changing the Gravity Value to >0 ?

Or:

Are there better methods of giving projectiles ballistic properties, changing the movement without radically teleporting the projectile etc. ?

 

PS: If any of you want to know how the bullet trajectory is modelled in my mod, you can use 0.00108 for fProjVelCoefficient and 0.000009168 for fProjGravCoefficient and put it in "v=930*(1-fProjVelCoefficient*fProjDistance)" and "h=fProjGravCoefficient*fProjDistance²". This is an example for the 5.56x45mm NATO M855 cartridge: v0=930m/s | m=62gr | G7 BC=.151, with a seight height of 0cm and a zero of 1m. You can use this data in your Ballistic Calculator of choice and compare it.

[Mktavish]

Well I'm not going to pretend to understand all that math. But I do have a vague picture of what you're doing in it.

 

First to say , what you're doing is suppose to be approximated in the Speed & Gravity settings on the projectile in my understanding. And I'm guessing it's a pre-calculated bullet path , not something figured out with the frame per frame moment of bullet travel. Because with the speed being how many game units it travels in 1 sec ( not sure just my guess ) . The engine at a frame rate of 60 , only gets 60 spots in 1 sec to act upon it.

So for example : "556mmRifleBulletProjectile" has a speed of 40640 , with it's range at 10000 ( 10k units , is the average distance with uGridsToLoad=5 ) Therefore it only got roughly 15 spots along it's path to check and adjust if the path were not pre-calculated. And even less with a lower frame rate.

The default uGridsToLoad=5 is why most projectiles have a range of 10000 , they simply set it at the distance it will no longer render on average. (actual 8k - 12k)

But looking at "308BulletProjectile" It has a speed of 53000 and range 53000 , the typical sniper rifle projectile.

So that says to me , the calculated bullet path can be done irrespective of the actual render distance. And they did this to improve it's accuracy because the lazy input distance matching render distance (hold over from fo3) is causing limitations in calculating the path. But they were hardly ever using gravity in Fo3 so probably non issue compared to NV implementing it.

 

Which second , I would like to quickly mention "Spread / Min Spread" on the weapon. And my understanding was this is only effecting a flat plane horizontally (left/right of center) But I wouldn't be surprised if it also has some up/down in actual pathing. So in case you didn't think about it for your testing , I would set your weap to 0 for purposes of ruling it out in causing mixed results. Also any player side statistics , get them set so as not to introduce reductions & random elements.

 

On those JIP functions , I never noticed those before , and had no idea you could adjust the projectile in flight.

Coolies :thumbsup:

BUT! I have to say their intended use for something meaningful in game play. Would have to be more for artillery shell type projectiles. Something having a rather pronounced curve. Reaching a zenith (slowing down) then radically changing direction in a short distance , and speeding up on the path down.

Which I would guess the pre-calculated path from speed/gravity/distance that existed in vanilla. Just couldn't render that realistically enough , hence they added it. ( not sure if Lobber projectiles have the same problem ?)

That's just my seems to me opinion though ... so don't let me discourage your effort towards your vision.

 

I would just say for your testing effort ... set the distance to match the speed for a starting point of adjustment.

And if you possibly can , bump your "uGridsToLoad" up to 7 , giving you a 12k-16k render distance. Which I am just guessing you will be able to get more refined results (more frames to act upon the ProjectileRef)

Also to make sure you are getting the maximum distance ... In geck place some objects to mark a cell border in your testing area. So you can step slightly past it in the direction you are shooting , thus gaining all the distance of the players center cell in the uGridsToLoad. Also something I just thought of , maybe try a diagonal trajectory relative to cell orientation to gain more render distance , giving you nearly 17k at a uGridsToLoad=5 ?

 

But now I just remembered , duh ... there is interior cell testing you could do. So in theory , no limits of uGridsToLoad ? I've made a few interior cell shooting ranges , but no where near the 10000 unit distance.

So IDK what kind of limitations they may have for testing your bullets ?

 

I guess I'm gona stop my ramble here , I hope something in there might help .

 

Add edit : sorry I forgot about your mention of iron sites for projectile launching point.

I'm not well versed in .nifs err versed much at all. But that is going to be a problem only fixable on the model. Or it may even be something introduced from the view swapping action. Like the projectile node doesn't update properly. Because I know you can move models in the world , but yet some of their elements stay behind ^shrug^ .

A mention on scope display , I don't know if this is relevant . But I recently did some testing trying to see when actors stop running their AI execution in pathing. Which they would stop at the uGridsToLoad . But in scope display , it seemed I was getting an extra 2000 units roughly (1/2 a cell) . Which toggling between regular and scope ... they would teleport back to the shorter distance , then re-travel the extra distance. Every time in scope display.

Might only be an actor fade thing , but thought it kind of quirky .

[Mktavish]

 

The scripting could've almost ended here so I headed to the second part of the mod, bullet drop. I thought that'll be easy and nothing more but changing the Gravity in the Projectile Tab to a precalculated value, mostly smaller than 0.9. Oh boy was I wrong. When I was testing and shooting I noticed an excessive bullet drop exceeding like 2m at 150m which is far from what I expected or would've been the case in the game without my script. So I tested it with a different Gravity Value of 0.1. No change, still noticing a drop of at least 2m at 150m. Same goes for a value of 0.01, 0.001 and so on. After all those results I set the Gravity Value to 0 and tried a different approach adding Movement Functions and precalculated Gravity Coefficients:

 

Sorry I missed the implication of this. In which case I would say make sure you are toggling archive invalidation every time you change something in geck to then test in game.

Meaning ... looking at your load order launch screen ... Turn off Archive Invalidation , Then turn it on again (reapply) Then launch with NVSE .

It may not be a problem , but worth a try to rule it out.

[Ravuth]

Thank you so much for your detailed replies Mktavish ! I will definitely try to turn on/off the "Archive Invalidation". I still need to get used to working in GECK as I working mostly with FNVEdit for non-script related stuff.

 

You are spot on with your guess that the calculation is not made with framerate though I have to say that it unfortunately, like most scripts, depends on it. However the framerate has far less of an effect using my method. I made custom projectiles for my mod using vanilla models. I was so confident in my script that I pre-calculated Gravity and Velocity Coefficients for over 70 projectiles before actually testing it. Here my 5.56 M855 has a speed of 65100 with a range of 56000. 15 spots over 10000 units are actually more than what I've counted ingame and are more than sufficient to portray a usable trajectory. This is my current line to get information about a live-projectile:

print fProjFallHeight + "@" + $fProjDistance + "m" + strVar

Just made it so that I have a clue of what is going on. This line is only meant for projectiles with a Gravity Value of 0 and a Gravity Coefficient of non-zero and of course you'll loose track if you fire too many bullets at once.

 

I set the "Min Spread" setting to 0.01 but I will set it to 0 next time. Also about Lobber, yeah it only really works with Missile types so in order to avoid errors I used this line to filter out any projectiles that are not declared in my ini file:

if TestExpr arrProjVelCoefficients[strVar]
....
endif

I made an ini-file so everyone with little to no knowledge about scripting (like I was 4 months ago) can safely tweak the behaviour of any given projectile or add their own custom ones. I initially planned to release the Mod on Nexus once I am satisfied with the results and quality. Sadly this isn't the case yet.

 

Generally when testing I set the Global Time Multiplier to 0.1 or lower so the projectile gets more updates but I'll try to test it with a higher "uGridsToLoad" setting, hopefully my 2012 Notebook won't dislike me for that. "sgtm" is very useful if you want to see how the projectile flies through the air. As I stated and you pointed out, the projectile gets its updates on a range scale instead in a scale of time or framerate. The advantage here is that the trajectory will always be the same on any given range but can be a little bit harder to deal with such as "lag time" for Wind Deflection (lag time here is a term used in the realm of external ballistics) but then again: I used range as a bloody time scale instead of actual time :huh: so it should barely be an inconvenience.

 

Again, thank you so much for taking time giving me so many ideas and hints ! It seems like that I have to invest a lot more time in GECK in order to understand it and use its full potential. I still have so much to learn but I am optimistic about it !

 

If you're interested in how I made the Coefficients here is how it works (make sure that velocity and range have the same base e.g. I will use meters but it also works in feet):

1.

Go to https://www.jbmballistics.com/cgi-bin/jbmtraj-5.1.cgi (any other Ballistic Calculator will work too if you know the input, I'm just most familiar with this one). ->Type in your Bullet Data ->Set Muzzle Velocity to m/s, Sight height to 0, Range Increment and Zero Range to 1 ->Set one column unit to "cm" (you have to convert it into meter later as there is no meter unit) -> Additionally tick "Ranges in Meters" ->Leave everthing else alone as it already has ICAO Standard Atmosphere typed in at 0m. The Maximum Point Blank Range is dependent on Target height which is set to 5in (Vital Zone Radius). ->Press "Calculate"

2.

(1-vMaxPBR/v0)/sMaxPBR = fProjVelCoefficient /// vMaxPBR = Velocity at Maximum Point Blank Range // v0 = Muzzle Velocity // sMaxPBR = Maximum Point Blank Range

h2MaxPBR/s2MaxPBR^2 = fProjGravCoefficient /// h2MaxPBR = Bullet Drop at double Maximum Point Blank Range // s2MaxPBR = Double Maximum Point Blank Range

e.g.

The 5.56x45mm NATO M855 has a Muzzle Velocity of v0=930m/s and a velocity of v254=675m/s at 254m whereas the bullet drop at 508m is h508=2.366m.

fProjVelCoefficient = (1-675/930)/254 = 0.00108

fProjGravCoefficient = 2.366/508^2 = 0.000009168

 

I am not a math-savvy so this formula is kept simple for me as well as everyone else. The approach of my calculation is, in my opinion, kinda lazy as I've used the Ballistic Calculator to do all the heavy thought process and math wizardry. This formula however works greatly with only 1% to 5% deviation from reality but the deviation starts getting worse beyond s2MaxPBR which luckily is most of the time outside physical render distance anyways :cool:.

[Mktavish]

you are more math savy than me ,,, thats for sure !

 

I look forward to more modding discussions with you .

 

We'll leave this first one as a test , :cool:

[Ravuth]

Ok, I turned "Archive Invalidation" on/off but unfortunately it didn't solve the problem. During some range testing I shot diagonal as you suggested to get some extra range and got some interesting results which would be otherwise hard to notice at short ranges:

I decided to use the script that does not utilize the fProjGravCoefficient-method (so in other words my original concept) as I am unfamiliar with models, nodes etc. and even if I do know how to change them I would'nt because this Mod needs to be absolutely user friendly and I don't want to edit every single weapon model or adjust other Mod Authors weapons.

 

Anyways back to my results... When I was shooting at powder gangers I was standing on a hill which means I was shooting at an angle. I noticed that the further the target was the smaller the bullet drop became, relatively speaking that is as the bullet drop is still smaller on shorter ranges, just not as low as I expected. Still, on all ranges, the bullet drop was excessive. This was weird. Why would the further target have a (relatively) smaller bullet drop than the near one ? I thought that maybe it has something to do with the scope issue you mentioned or maybe that the projectile still acts like a hitscan wannabe, scanning the point of impact in front of it but then adjust its trajectory to some hidden formula.

 

It turns out that none of that is true ! The bullet's flightpath, if it is used with SetProjectileRefSpeedMult and a Gravity Value of >0 (here: 1), will always get exaggerated when shooting at an angle ! Thats why the projectile at the more distant target has relatively less bullet drop, the angle is just smaller. To confirm this I set the angle (X) of the projectile to 0°, 5°, 10° and -10°. At 0° angle the bullet drop was quite close to what the Ballistic Calculator printed out, especially at longer distances. To put it simple: the trajectory was normal. It was everything I could've hoped for. At 5° however the bullet drop was like 5 times bigger and at 10°/-10° its almost 10 times the ammount of the anticipated bullet drop.

 

It seems that SetProjectileRefSpeedMult messes with the gravity-vector or the z-axis big time when shooting at an angle that is non-zero. I have to test more to find out if it is a steady change or a result of multiple live-updates applied to projectiles during flight. To see the drop I used this line but it is very buggy on longer distances:

set fBulletDrop to (fProjStartPosZ - fProjDistance*fProjStartAngleSinX*70 - fProjPosZ)/70
print $fBulletDrop + "@" + $fProjDistance + "m" + strVar

Thats why I use this line for an angle of 0°:

set fBulletDrop to (fProjStartPosZ - fProjPosZ)/70

One note I might to add is that the projectile will actually be rendered outside physical render distance but won't obviously hit anything and, depending on its angle and/or bullet drop, it can fall below the map. Some (vanilla-)weapons are buggy as well e.g. the ".44 Magnum revolver" shoots projectiles into infinity when aimining down sights despite the fact that I set its and the projectiles range to 21000 units. This means that, due to my mod, at some range the projectiles will stop moving and unnecessarily eat perfomance. So I used this line to get rid of said projectiles:

if fProjSpeedMult < 0.1
   rProj.Disable
   rProj.MarkForDelete
endif

Edited May 13, 2020 by Ravuth

[Mktavish]

 

Ok, I turned "Archive Invalidation" on/off but unfortunately it didn't solve the problem.

 

I kinda figured Archive Invalidation wouldn't do anything in this case , but in testing to build foundational data upon. Ruling things out methodically I have found is a must. Which in my experience it has cleared up more than asset swaps. Actor AI most notably. But is that a typo up there with on/off ? It should be reversed , Off then On (reapply)

 

During some range testing I shot diagonal as you suggested to get some extra range and got some interesting results which would be otherwise hard to notice at short ranges:

 

To be clear , saying you should extend the rendered range , is just so you can get a better peek under the hood of what is going on. Because obviously in most game play , it won't be happening. But later mentions in your thread suggest the uGridsToLoad setting doesn't matter , and the distance on the projectile is all that matters ?

So , for better performance of your machine to avoid hiccups in getting results. I would keep the default setting , and you might even want to drop "Grass Fade" & "Tree Lod fade" for testing. Which they give the biggest boost to performance imo. By the way , you cannot revert a save to a lower uGridsToLoad setting. Just to let you know , so keep back ups , or don't save. If you don't want to bork the save for lower settings.

 

I decided to use the script that does not utilize the fProjGravCoefficient-method (so in other words my original concept) as I am unfamiliar with models, nodes etc. and even if I do know how to change them I would'nt because this Mod needs to be absolutely user friendly and I don't want to edit every single weapon model or adjust other Mod Authors weapons.

 

I had a thought later about how you might fix the projectile node discrepancy in Iron sites easily game wide.

Simply disable/enable the model once it reaches the center screen position. This is the remedy for fixing other models that get moved in the world. But maybe not though , just thought it worth a try , and maybe not all will be fixable like that if it works for some ?

 

Anyways back to my results... When I was shooting at powder gangers I was standing on a hill which means I was shooting at an angle. I noticed that the further the target was the smaller the bullet drop became, relatively speaking that is as the bullet drop is still smaller on shorter ranges, just not as low as I expected. Still, on all ranges, the bullet drop was excessive. This was weird. Why would the further target have a (relatively) smaller bullet drop than the near one ? I thought that maybe it has something to do with the scope issue you mentioned or maybe that the projectile still acts like a hitscan wannabe, scanning the point of impact in front of it but then adjust its trajectory to some hidden formula.

 

It turns out that none of that is true ! The bullet's flightpath, if it is used with SetProjectileRefSpeedMult and a Gravity Value of >0 (here: 1), will always get exaggerated when shooting at an angle ! Thats why the projectile at the more distant target has relatively less bullet drop, the angle is just smaller. To confirm this I set the angle (X) of the projectile to 0°, 5°, 10° and -10°. At 0° angle the bullet drop was quite close to what the Ballistic Calculator printed out, especially at longer distances. To put it simple: the trajectory was normal. It was everything I could've hoped for. At 5° however the bullet drop was like 5 times bigger and at 10°/-10° its almost 10 times the ammount of the anticipated bullet drop.

 

It seems that SetProjectileRefSpeedMult messes with the gravity-vector or the z-axis big time when shooting at an angle that is non-zero. I have to test more to find out if it is a steady change or a result of multiple live-updates applied to projectiles during flight. To see the drop I used this line but it is very buggy on longer distances:

set fBulletDrop to (fProjStartPosZ - fProjDistance*fProjStartAngleSinX*70 - fProjPosZ)/70
print $fBulletDrop + "@" + $fProjDistance + "m" + strVar

Thats why I use this line for an angle of 0°:

set fBulletDrop to (fProjStartPosZ - fProjPosZ)/70

So you floored the angle , which worked ? Am I understanding that correctly ?

 

One note I might to add is that the projectile will actually be rendered outside physical render distance but won't obviously hit anything and, depending on its angle and/or bullet drop, it can fall below the map. Some (vanilla-)weapons are buggy as well e.g. the ".44 Magnum revolver" shoots projectiles into infinity when aimining down sights despite the fact that I set its and the projectiles range to 21000 units. This means that, due to my mod, at some range the projectiles will stop moving and unnecessarily eat perfomance. So I used this line to get rid of said projectiles:

if fProjSpeedMult < 0.1
   rProj.Disable
   rProj.MarkForDelete
endif

Is it possible to modify the distance in flight ?

Not that I think it matters much for better performance . Since likely bullets are being cleaned up similarly hard coded wise.

Although some extended game time testing will tell you from save bloat , were the Deletion not happening soon enough.

 

I'm curious since this is to simulate wind ... does the player have some way to gauge the wind ?

Also wondering with those dust devil static effects ... if there is a way to bring those into play with your formula ?

[Ravuth]

I kinda figured Archive Invalidation wouldn't do anything in this case , but in testing to build foundational data upon. Ruling things out methodically I have found is a must. Which in my experience it has cleared up more than asset swaps. Actor AI most notably. But is that a typo up there with on/off ? It should be reversed , Off then On (reapply)

 

Just a typo, it's on per default so I switched it off first.

 

I had a thought later about how you might fix the projectile node discrepancy in Iron sites easily game wide.

Simply disable/enable the model once it reaches the center screen position. This is the remedy for fixing other models that get moved in the world. But maybe not though , just thought it worth a try , and maybe not all will be fixable like that if it works for some ?

 

I'll try this someday and keep it in mind as a last resort. It may fix the issue with the projectile node but some vanilla-projectiles are imo still too buggy to be fixed. In my mod those vanilla-projectiles are far off regardless of iron sights, scopes etc. whereas normally it would just be off iron sights. But I bet they are fixed with custom projectile models like in CaliberX.

 

So you floored the angle , which worked ? Am I understanding that correctly ?

 

Yes, my mod unfortunately only works flawlessly if the x-angle is 0 which will never be the case in normal gameplay.

 

Is it possible to modify the distance in flight ?

Not that I think it matters much for better performance . Since likely bullets are being cleaned up similarly hard coded wise.

Although some extended game time testing will tell you from save bloat , were the Deletion not happening soon enough.

 

Due to the script, projectiles will loose speed, eventually hitting a speed multiplier of 0 wich means that some projectiles may never reach maximum range and therefore won't be deleted automatically unless reloading the game. Normally this isn't the case if you don't exaggerate with range settings but FNV is a rushed game with a lot of bugs so some projectiles won't care about how long or short its max range really is. I think your'e right about the performance but I'll better keep this in the mod as otherwise there would be too much going on in the console, updating dozens of projectiles at once despite already having passed max range.

 

I'm curious since this is to simulate wind ... does the player have some way to gauge the wind ?

 

Once I have dealt with my current problem I can concentrate on the last part, wind. There are thankfully wind values ingame which I can use but my script will only read it, not change it. That is up to weather modders (which they probably already have included in their mods but I can't tell since I don't have any weather mods installed). When it comes to gauging, I am still open to suggestions. I'll plan to do something similar to the Sniper Elite series which have a little crosswind indicator on top of the screen though in order to do so I have to learn how to do HUD-things. Maybe I'll incorparate a mini weather station and ballistic calculator like the Kestrel 5700, who knows ? But right now I'll leave those thoughts to future-me.

 

Also wondering with those dust devil static effects ... if there is a way to bring those into play with your formula ?

 

That'd be too much for me right now. I'll try to concentrate on Velocity decrease, Gravity and Wind first which would create the core function of my mod. This is after all my first mod involving a script and therefore rather simple in structure.

I still havn't provided details on how this mod actually works ingame so here is a tasty screenshot :turned:

 

On the left side you'll see the console. As long as ther is a PC-projectile in the air, it will update and print the stats to the console. On the right side there is a section of a ballistic table for comparison. You have to multiply the SpeedMultiplier with the Muzzle Velocity (here: 930m/s) in order to get the current projectiles velocity. This mod is oversimplifying things so the results are somewhat off the ballistic table. One can tell that this mod is orientated towards players who like a degree of realism and possibly have a high uGridsToLoad setting so it's perhaps not everyones taste.

 

Status quo:

• Velocity decrease - solved
• Gravity - needs to be fixed / buggy in conjunction with SetProjectileRefSpeedMult and an angled projectile
• Custom Gravity model - needs to be fixed / switching models off while aiming as a last resort / still needs further testing / open to different solutions and approaches
• Wind - unsolved / will be prioritized if the Gravity issue is either solved or stays completely unsolvable

Regarding SetProjectileRefSpeedMult : Since this is a JIP function do you think if it's worth to leave jazzisparis a PM regarding this bug ? I don't want to unnecessarily waste someones time or be yet another one of possibly dozens asking him daily for this and that.

[dubiousintent]

If you believe you have found a bug to something he has already implemented, any author would want to hear about it. Please provide details as to how to reproduce the problem. (If it can't be reliably reproduced, then it probably can't be fixed. But if never informed about it, it will definitely not get fixed unless they happen to stumble upon it for themselves.) The Nexus download page for JIP LN NVSE has a "Forums" tab where you can post your issue.

 

-Dubious-

[Mktavish]

No wouldn't be a waste of time at all imo. You're probably one of the few to get some use out of those functions.

I'll bet they would enjoy your feed back and hopefully could fix the angle issue.

 

Add edit : LOL dubious got me with a ninja :ninja:

 

On the dust devil , or other static effects. I'll see if I can capture when the projectile intersects them. But me not knowing how your formula works , would just have to leave what to do with it up to you.

 

And maybe an easy way to disable/enable the gun model for hopefully fixing the projectile node position with Iron sites.

Is there a particular rifle that is bad with this I should look at attempting that with ?

Also , what type of script(s) are you running ?