Marksmen DLC wanted changes

[Spartan0536 189]

Ok so here are my issues thus far.....

1. For the new ballistics code resource, us modders need a resource that not only allows you to set initspeed in the weapon but also the airfriction, and hit values as they change with barrel length, if these were allowed to be aliased it would make it sssooo much easier for mod makers to use accurate ballistics without cluttering the ammunition library. Example provided below...

example:

M4A1 SOPMOD;

[M855A1 EPR]; - (Aliased from ballistics)

initspeed = xxx.xx;

hit = x.xx;

airfrciton = x.xxxxxxxx;

};

[Mk262 Mod 1]; - (Aliased from ballistics)

initspeed = xxx.xx;

hit = x.xx;

airfriciton = x.xxxxxxxx;

The main reason why I ask for this is that all 3 of those variables change with barrel length, not just initspeed like you are currently implementing on devbranch, this is unless a BIS dev can tell me if the in game "ballistics calculations" are automatically calculated based off of initspeed, but I highly doubt this. In either case allowing for MULTIPLE initspeeds based on the ballistics per weapon would be great as it allows people to use different bullets to react to different threats accordingly.

2. Personal body armor.... PLEASE BIS make body armor work correctly, this flat damage negation thing is kinda laughable as it makes hollow points / frangible rounds the king of combat, give the vests a HP system based on penetration and damage once that HP system is down to 0 its effectiveness is reduced greatly, also with this should be a correct density profile just like your environment densities so that HP's cant penetrate body armor or nearly as effectively as ball ammo, however if a round penetrates the body armor then the bullets current ballistic profile after the penetration results in the damage profile, thus making it a fairly realistic simulation without all the BS.

3. PROPER BOLT ACTION ANIMATIONS, there are TONS of people asking for this for a modders resource, please BIS, if you are not adding in any more bolt actions to ArmA III for the foreseeable future, please update the bolt animation on the .408 Rifle so that others can properly use this as a "stepping stone" of sorts.

4. If you plan on adding another 5.56 NATO rifle, or even as part of the ballistics update, please please look at my ballistics thread at my M855A1 EPR ballistics and get some ideas from it or use it; it is by far more realistic that your current values, I did not spend over 20 hours of research to BS people, this would really make combat in modes like King of the Hill more interesting especially for new players.

Thanks,

Spartan0536

[da12thMonkey 1943]

this is unless a BIS dev can tell me if the in game "ballistics calculations" are automatically calculated based off of initspeed, but I highly doubt this.

What's so doubtful about that?

*N.B. references to actual config parameters in the bellow paragraphs are in italics*

initSpeed is the speed at which the simulated bullet is initialised into the game world (i.e initSpeed = muzzle velocity). After that the bullet is moving in free space and starts decelerating due to the simulated "drag". It also experiences a vertical force due to gravity.

The game's "drag" model is a simple as heck deceleration = airFriction * velocity² plot derived from rearranging -F = ma = ½C_DÏAv² to a = - (C_DÏA/2m) * v². Please note therefore that the airFriction parameter in the config isn't directly comparable to any single real-life property of the bullet but is a sort of amalgam of C_DÏA/2m.

This has been written on the biki by BIS for ages:

Bullet simulation is not kinematic (trajectory based), but dynamic (force based). Two basic forces are considered - drag (air friction) and gravity.

Vector3 accel=_speed*(_speed.Size()*_airFriction);
// add gravity
accel[1]-= _coefGravity * G_CONST;

Initial speed of the bullet degrades over distance, so HIT value.

...

airFriction = -0.0005; // modifies speed degradation, the biger negative value, the more it slows down.

Can be calculated as:

_airFriction = accel / speed^2

using real world acceleration and speed of the bullet from balistic tables.

Makes perfect sense to me looking only at the effect of the air friction in the slowing of the bullet's flight Distance travelled = vt + ½at², so every frame the game can do an iterative position calculation to determine where a bullet should have moved to: distance travelled = vt - ½ * airFriction * (vt)². For calculation in the very first frame after the player pulls the trigger, the v₀ value used would be the initspeed value, and every frame after that would be the current speed of the bullet.

It says hit falls off based on velocity once v_TOTAL < typicalSpeed, but I'm not 100% sure what the formula for hit calculations is once the bullet speed drops below the typicalSpeed threshold. It's probably a hit * (v_TOTAL/typicalSpeed) type relationship such that the damage dealt tends to zero when velocity tends to zero.

Edited March 2, 2015 by da12thMonkey

[Brisse 78]

airfriction, and hit values as they change with barrel length

Not 100% true. Barrel length changes the muzzle velocity. Airfriction changes with the velocity of the projectile, not just the muzzle velocity, but the velocity all the way along the trajectory. This is an inherent problem with the airfriction parameter and is the major limitation of this ballistic simulation in the vanilla game in my opinion.

When calibrating the airfriction parameter, there are three things to keep in mind along the trajectory of the projectile. Bullet drop, velocity and time of flight. With the airfriction parameter you can only calibrate one of these to be correct at a certain fixed distance and muzzle velocity. So you see, this problem goes much further than just barrel length. For example, if you calibrate airfriction so that the velocity at 400m is correct, the time of flight, and bullet drop will be wrong. Also, the velocity will be wrong at all distances, except at the muzzle and at 400m.

So what we really need is a more advanced simulation using ballistic coefficients instead, as they don't change as much with the velocity. If we had that, then there would be no need for separate airfriction depending on barrel length and such, which will never get the accuracy we want anyway.

Edit: Another flaw with having different airfriction depending on barrel length, is that internal ballistics are mixed with external, in a way that is not true to real life physics. Internal ballistics should be one simulation, external should be another. Once that projectile has left the barrel and the gases leaving the muzzle, it does not care what weapon it was fired from. This proposed solution kind of assumes that it does care, but that's not real physics.

We need to draw a line between internal, external, and terminal ballistics. Internal ballistics code should only provide the starting point for the external ballistics, but once it does that, it's done. That excludes having different airfriction depending on barrel lengths. External ballistics should provide the starting point of terminal ballistics, but once it has reached the terminal phase, it should stay out of it's way. We can also excludes having different hit values depending on barrel lengths, because then you mixed up internal ballistics and terminal ballistics. Terminal ballistics does not care about the muzzle velocity, but it does care about the velocity just as the projectile enters the terminal phase, and that is what it uses in the current system, and it works.

Edited March 2, 2015 by Brisse

[da12thMonkey 1943]

With the airfriction parameter you can only calibrate one of these to be correct at a certain fixed distance and muzzle velocity. So you see, this problem goes much further than just barrel length. For example, if you calibrate airfriction so that the velocity at 400m is correct, the time of flight, and bullet drop will be wrong. Also, the velocity will be wrong at all distances, except at the muzzle and at 400m.

Is it because most ballistic charts handle velocity as a kinematic component where it is the distance travelled between the shooter and the target in the horizontal plane over time (downrange velocity), and don't include the vertical velocity vector? BIS's ballistics model uses speed in the dynamic sense, where it's a directionless scalar quantity - the sum of the magnitudes of velocity in the x, y and z axis.

cosine angle from weapon zeroing ingame could also have an impact on time of flight and downrange velocity.

Edited March 2, 2015 by da12thMonkey

[five_seven5-7 56]

Can the engine handle to much variables? We have the same struggles in Fixed-wing aircraft.

[twisted 128]

Ok so here are my issues thus far.....

3. PROPER BOLT ACTION ANIMATIONS, there are TONS of people asking for this for a modders resource, please BIS, if you are not adding in any more bolt actions to ArmA III for the foreseeable future, please update the bolt animation on the .408 Rifle so that others can properly use this as a "stepping stone" of sorts.

Thanks,

Spartan0536

this very much so. including the feature that the bolt action wont be cycled until you release the mouse button/tirgger. this way you can call you shot and watch it impact before disturbing your sight impact by cycling the bolt.

[Brisse 78]

Is it because most ballistic charts handle velocity as a kinematic component where it is the distance travelled between the shooter and the target in the horizontal plane over time (downrange velocity), and don't include the vertical velocity vector? BIS's ballistics model uses speed in the dynamic sense, where it's a directionless scalar quantity - the sum of the magnitudes of velocity in the x, y and z axis.

cosine angle from weapon zeroing ingame could also have an impact on time of flight and downrange velocity.

I wish I could answer that, but the only thing I know is that when I calibrate ammo using Ruthberg's Advanced Ballistics I can get velocity, time of flight, and drop to match a real ballistics chart exactly, at any distance, but doing the same with vanilla ballistics just using airfriction and initspeed is impossible. In-game testing has proven to me that any situation, except the one you calibrated airfriction for is going to be wildly inaccurate. Set initspeed to it's real life value, and then tweak airfriction so that it is correct at 400m. Fire up the game and test it at 400m and you will see realistic velocity at impact. Now try to engage a target at 200m at you will see that velocity is slightly off, maybe 20m/s for a 5.56x45 NATO. Now try at 800m and you will see that it is way off, perhaps as much as 100m/s. Go back into configs and set airfriction so that you achieve correct velocity at 800m, and it will be off at 400m. I wish I knew mathematically why this is, but I don't.

[da12thMonkey 1943]

I wish I knew mathematically why this is, but I don't.

I kind of get the feeling it may be based on discrepancies between how velocity is calculated between frames of measurement and used in the drag model. Differences between one source measuring downrange velocity, another using true 3-dimesional velocity modelling with infinite datapoints, and a sort of per-frame average velocity calculation where it's based on linear distance between Cartesian coordinates. And how that carries over along subsequent iterations.

Somet like the path lengths in this diagram demonstrate:

Obviously there's some exaggeration in scale

Edited March 2, 2015 by da12thMonkey

[Brisse 78]

Alright. That could be part of the problem, but I don't think it's the whole story.

The Arma simulation is just too simple. It assumes that airfriction is a constant number along the entire path of the projectile. That's far from how reality works though.

Arma: acceleration = airFriction * velocity{m/s} ^ 2

Just have a look at this graph. It shows the drag coefficient varying with the velocity, and deceleration will depend on the drag coefficient. Look at how much it changes.

https://upload.wikimedia.org/wikipedia/commons/a/a1/GB528_CD.jpg (187 kB)

As long as we are using just the airfriction parameter, there's no way we can account for stuff like that.

[das attorney 858]

Does anyone have any idea of the impact of improving the simulation?

I feel it would involve more calculations and add to the burden of the CPU.

I would like to see improved realism, but I suspect the system we have now is a compromise between realism and keeping the framerate acceptable.

[Brisse 78]

Das Attorney: I absolutely agree. The current system is good enough for short and medium range engagements. It only becomes a problem once you try long range shooting using ballistics charts. Most players would probably be happy if BI were just to throw in some approximate semi realistic wind drift.

It is an interesting discussion though, escpecially as a user of Ruthberg's Advanced Ballistics. Yes, it does have a noticeable performance impact, and I only use the mod when I do long range shooting :)

[Spartan0536 189]

Ok so my issue with AirFriction for barrel length....

As ArmA uses an airfriciton calculation that yes works through the entire flight path, it also needs to be calibrated correctly at the muzzle otherwise the bullet will have the same drag coefficient as if it were moving faster, this makes the round much less effective especially at range and creates way too much falloff.

The reason why I am asking for airfriciton and hit additions plus the ability to alias multiple rounds is that it uses the default ballistics calculations but enhances them to make things more streamlined instead of cluttering configs with stacks of code where 1 wrong decimal point or bracket can cause a cascading failure.

[Dirtylarry 10]

I hope we will get working bipods, does anyone know if we will get that?

[Brisse 78]

That's unrelated to this thread, but yes, we will get working bipods.

[CaptainAzimuth 714]

I suggest you guys wait until you've played with the actual DLC and all of it's glorious features before having such a thread that is almost 100% irrelevant, considering there's nothing to change, if it's not even out yet.

[toysoldier 35]

Switching weapons while moving, not launchers.

Side rolling with binocular.

Bullet in chamber. (31 bullets)

Empty ammo not selectable as Infantry (GL) and Vehicles.

[old_painless 182]

As spotter, we need to be able to visually spot impacts at, say, 1200m. That does not happen today. Without impact, the role as spotter makes no sense

[Spartan0536 189]

I suggest you guys wait until you've played with the actual DLC and all of it's glorious features before having such a thread that is almost 100% irrelevant, considering there's nothing to change, if it's not even out yet.

So, its stupid to ask for suggestions while a DLC is in development because you can expect massive changes after release right?

[stoffl 13]

As spotter, we need to be able to visually spot impacts at, say, 1200m. That does not happen today. Without impact, the role as spotter makes no sense

this x 100. Just tie it to the object draw distance an we're good. Playing as spotter is so damn frustrating atm.

plus everything the ballistics nerds are talking about. I don't understand half the things they say but I want them to have better starting point for their great addons and less frustration,so just give it to them :D

[chortles 263]

Yes, it does have a noticeable performance impact

Almost certainly the reason why BI doesn't adopt it 1:1 -- considering the performance complaints about the game without it -- though BI seemingly not being inspired by it is certainly a valid critique...

[Brisse 78]

BI is in a difficult spot. There's one small group asking for better ballistic simulation, which most likely takes up slightly more CPU power, and there's another much larger group of people asking for performance optimizations. I think they will prioritize the latter in this case, although it saddens me a little. I guess I will have to keep using Ruthberg's Advanced Ballistics for a while :)

[DancZer 65]

I think in long term it would be better to have as much realistic ballistics as possible.

[petek 62]

BI is in a difficult spot. There's one small group asking for better ballistic simulation, which most likely takes up slightly more CPU power, and there's another much larger group of people asking for performance optimizations. I think they will prioritize the latter in this case, although it saddens me a little. I guess I will have to keep using Ruthberg's Advanced Ballistics for a while :)

Agree re the difficult position BIS is (always) in re performance optimisation. Guess the best approach is to have advanced ballistics optional if it makes it in (like the Heli advanced flight model)

[Spartan0536 189]

This is why I am asking for these code edits, it uses the same BIS calculations, all the edits allow for is the aliasing to the weapon for ballistic parameters ensuring a much more correct ballistic simulation while cutting excess coding down, its a win-win and should have absolutely 0 FPS impact.

OK so here is exactly what I mean by Ballistics to Weapon Aliasing.....

Current BETA for Ballistics....

(Ballistics Area)

M855A1 EPR;

Hit: xxxx;

Airfriction: xxxx;

typicalspeed: xxxx;

Caliber: xxxx;

VisibleFire: xxxx;

AudibleFire: xxxx;

(Weapon Area)

M4A1;

initspeed: xxxx;

The issue here is that initspeed while very important does not affect airfriction values, thus meaning that the bullet will have the higher AF value even if it is at lower velocity thus giving it way too much drag, greatly limiting its realistic performance.

My Suggestion:

(Ballistics Area)

M855A1 EPR;

Hit: xxxx;

Airfriction: xxxx;

typicalspeed: xxxx;

Caliber: xxxx;

VisibleFire: xxxx;

AudibleFire: xxxx;

(Weapon Area)

M4A1;

{M855A1 Aliased}

initspeed: xxxx;

AirFriction: xxxx;

VisibleFire: xxxx;

AudibleFire: xxxx;

};

{Mk262 Mod 1 Aliased}

initspeed: xxxx;

AirFriction: xxxx;

VisibleFire: xxxx;

AudibleFire: xxxx;

Why these changes?

Well for one allowing multiple aliasing in the code allows modders to give players the choice of ammunition to match the situation or SOP for some clans. Now Hit value is calculated by taking the projectiles form factor, weight, and speed, the only variable to change between these from a different barrel is the speed so therefore aliasing a hit value is not entirey necessary even though I do it to ensure accuracy in my work. Now the AirFriciton variable is CRICITAL as that does change the rate of drag at the muzzle and until the bullet stops, having a higher/lower airfriction than the projectile should reduces the realistic properties of the in game ballistics. As for the VisibleFire and AudibleFire lines, they should change with the firearms barrel length as the shorter the barrel usually the louder the report and the bigger the "fireball" as there is not as much barrel length to burn all the powder. Caliber is calculated by using speed and the caliber number to achieve penetration, this does not need an alias as the initspeed covers this issue.

Please note visiblefire and audiblefire are only used for AI DETECTION, for people running games with AI this is critical to gameplay, for people in PVP like in Sa-Matra's KOTH it has no effect.

Addendum: This aliasing uses default ArmA III BIS code, and should have 0 FPS impact as its not calculating extra external ballistics, its merely overriding the magazine values thus adjusting the ballistic profile. So we get more realistic ballistics with less code writing and no long are 20 different magazines needed in the init configs for the same guns, and we get no frame rate impact, its a win-win-win, I fail to see the issue of this suggestion here.

Edited March 4, 2015 by Spartan0536

[chortles 263]

BI is in a difficult spot. There's one small group asking for better ballistic simulation, which most likely takes up slightly more CPU power, and there's another much larger group of people asking for performance optimizations. I think they will prioritize the latter in this case, although it saddens me a little. I guess I will have to keep using Ruthberg's Advanced Ballistics for a while :)

The difference is that you can choose to eat a performance hit with a third-party thing, whereas BI's evidently keeping that in mind and presumably weighing one against the other. Again, one can want BI to be inspired by the community-made mod, but then a native engine implementation had better outdo that mod!

Agree re the difficult position BIS is (always) in re performance optimisation. Guess the best approach is to have advanced ballistics optional if it makes it in (like the Heli advanced flight model)

I don't recall the AFM having noticed widely reported performance impact though? Because that was probably key... and "optional" ballistics differences (which can affect TvT way more directly than AFM does if mismatched) is probably a step further than BI's willing to go. At least the OP's clearly considered performance impact and its priority vs. "realism" before coming up with his proposal.