Ravuth

I have worked a little bit on the Wind part and actually managed to work out a functioning formula without any bugs or glitches for once :happy:. See for yourself (10m/s crosswind at 90°): The method is to change the projectile's z-angle over time so it results in a curved shot instead of a unrealistic triangle when the angle is fixed. Positive values means that the wind deflects the projectile to the right and negative ones to the left. The script section looks as follows: set fProjStartAngleZ to rProj.GetStartingAngle Z set fCrossWindAngle to GetWindDirection - fProjStartAngleZ set fCrossWindComponent to Fsin fCrossWindAngle set fProjAngleZ to (fProjWindCoefficient*fProjDistance*fCrossWindComponent*GetWindSpeed + fProjStartAngleZ) rProj.SetAngle Z fProjAngleZAs always I saved the fProjWindCoefficient value in an ini file. It is dependend on the Wind Speed which I still have to decide how big its max value should be (1.0 -> 20m/s or 1.0 -> 30m/s or ... ?). fProjWindCoefficient can be calculated by using this formula (d2MaxPBR = deflection at double maximum point blank range): fProjWindCoefficient = 2*atan(d2MaxPBR/s2MaxPBR^2) All I have to do now is to calculate those coefficients for over 70 custom projectiles... yay Status quo: Velocity decrease - solvedWind - solvedGravity - needs to be fixed / buggy in conjunction with SetProjectileRefSpeedMult and an angled projectileCustom Gravity model - needs to be fixed / switching models off while aiming as a last resort / glitchy / open to different solutions and approaches

Ok, I'm going to drop a detailed report on the JIP LN NVSE forum page with information on how to reproduce this bug. Since I don't know when this fix will be applied or if this bug is fixable at all, I'll try to focus on the wind part of my mod instead.

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 - solvedGravity - needs to be fixed / buggy in conjunction with SetProjectileRefSpeedMult and an angled projectileCustom Gravity model - needs to be fixed / switching models off while aiming as a last resort / still needs further testing / open to different solutions and approachesWind - unsolved / will be prioritized if the Gravity issue is either solved or stays completely unsolvableRegarding 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.

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

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] .... endifI 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:.

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