Jump to content
Sign in to follow this  
Spartan0536

Marksmen DLC wanted changes

Recommended Posts

As for the airfriction issue,

I have not noticed the airfriction implemented as STATIC code, but dynamic code, I have seen this from using Bakermans Community Ballistics Calculator by taking all of my known and converted ballistics data and plugging it into his "range card" simulation to match real range card ballistics calculators, this is the exact reason why I claim to be within 3-5% as there is deviation and I am not sure what barometric pressure, altitiude airdensity, and humidity levels BIS uses by default for the ArmA III engine, if I knew them I would adjust all of my ballistics to match those conditions as best as possible and I could get the profiles down to a 1% or less most likely.

Share this post


Link to post
Share on other sites

Addendum: I take it that you would propose that in the event of a weapon not having airFriction, audibleFire, and visibleFire defined, that they all default to the ammo's in the same manner that initSpeed currently does for weapon and magazine? Because if I recall correctly the relationship of weapon config to ammo config is "through" the magazine config... or should this all be in the magazine config?

Share this post


Link to post
Share on other sites
Addendum: I take it that you would propose that in the event of a weapon not having airFriction, audibleFire, and visibleFire defined, that they all default to the ammo's in the same manner that initSpeed currently does for weapon and magazine? Because if I recall correctly the relationship of weapon config to ammo config is "through" the magazine config... or should this all be in the magazine config?

Currently its all in the magazine init config, the new code allows for an override in the weapon config, right now for different ammunition and barrel lengths I have to write individual unique magazine configs per weapon, with my suggestion there would only be 1 magazine config per bullet per weapon, the changes are then overridden in the weapon inits. As I said all these variables have been in ArmA III this whole time, I just want to streamline the hell out of it which will make it easier for modders and also allow BIS to deliver a more accurate ballistic representation for "whitelisted" server that do not allow mods.

Pros of my suggestion:

1. Less messy code structure and less code to write and possibly screw up

2. 0 additional frame rate impact as its all BIS default

3. more realistic ballistic behavior for default weapons thus increasing immersion and authenticity

4. With the multiple aliasing option modders can have a single weapon use different types of ammo in the same firearm with unique ballistic properties thus increasing immersion and giving the players more options.

Cons of my suggestion:

1. BIS has to do more work before releasing their Marksman DLC pack.

Edited by Spartan0536

Share this post


Link to post
Share on other sites

Cons of my suggestion:

1. BIS has to do more work before releasing their Marksman DLC pack.

That is not a con.

Delay it 2-3-4 months whatever it takes but get it right.

I know I personally would not mind waiting 6 months for the marksmen dlc if it included wind and mil turrets.

Share this post


Link to post
Share on other sites

The point Spartan makes about cleaning up config code is noted, but unless points are made in a request which pertain to and benefit vanilla content, I don't see why BIS would even pay attention. Requests to a developer in an attempt to make things more streamlined for 3rd party are a dime a dozen. To get a developer to do something which benefits you/your content, it would be a good idea to first convince the developer that it benefits them/their content.

I do like the armor idea, and .408 animations, YES! It's silly at this point when a vanilla rifle still feels as if it's part of some early WIP release.

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

I know the utmost in ballistic simulation is beyond the scope of the original requests, but I don't think they are in a difficult spot at all. Most of the small group doesn't even push for ballistic simulation because we already have a mod that does it damn near perfectly. On the other hand there is another large group of people to consider. To suddenly require a well rounded understanding of ballistics and how to use various tools for effective long range shooting would be to throw the vast majority of players under the bus. Even then, among the small remaining group who are maybe recreational long range shooters, military/LE trained or those with general interest, there would be an unhappy percentage that simply don't wish to exercise the same level of discipline in a video game. Am I for ballistic realism by default? Hell yea, but it'll never happen. Video games of the last couple decades have an entire generation thinking they are "snipers" and I'm afraid it's a bit too late to shatter that delusion without also shattering your customer base.

Brisse, you paint a really solid picture of the reality of where the ballistics in this game currently stand, (namely post #3) which should hit home for those who want to see BIS bring in realistic ballistics of their own and those who continue to piss into the wind, trying to match BIS trajectories to reality. It should be perfectly clear to everyone that we don't need the ballistics code to be patched up, built on, repaired or reconditioned, because the foundation itself is simplified and inaccurate. We'd be fools to think BIS isn't aware of this. They know a complete overhaul would be required and the only way to move forward is for us to acknowledge this as well and form an appropriate demand.

From my point of view, adding a priority to weapon-defined parameters as opposed to the magazine only adds a realistic concept; that some things change weapon to weapon, even with the same ammo, but until the parameters themselves are redefined and capable of producing real-life projectile behavior, adding this concept does nothing in the way of actually bringing more realism to the core ballistic simulation.

Share this post


Link to post
Share on other sites

Glad the message came through to at least one person :)

Edited by Brisse

Share this post


Link to post
Share on other sites
Glad the message came through to at least one person :)

Its interesting to note that BIS wanted to tackle the ballistics issue "once and for all" according to one of their dev's which is why they are implementing the initspeed in the weapon parameter, well by allowing what I suggested it would from their simple standpoint fix their issue. BIS dev's have no reason to give ArmA players a full ballistics simulation when they well know there are people like Ruthberg and myself who will take the time to do the research and improve the ballistics in the game either by making their own mod or providing the most realistic ballistics capable within the default parameters so that there is little to no frame impact. I love Ruthberg's work, its great, but I have ran it on my server and when sh** hits the fan, FPS goes down the drain fast, this is the inherent nature of the beast and I am quite sure that BIS is very aware of this. Yes the BIS system for ballistics is not 100% real, its decent, and its most certainly better than 95% of games out there, but it works decently and with the proper code allowances they can at least refine the rough edges to enhance gameplay slightly and provide the community with a much better option than spamming code all over an .cfg file.

Just a note, any of this code altering will not make MY work any more accurate, I am limited by BIS's ballistic design, but it will make writing the code for modders much easier and for BIS it will vastly improve on their current default simulation with no FPS impact. For anyone interested, the reason why my ballistics numbers are so freaking detailed (I get about 3 messages a week about this), its because I use Bakermans Community Ballistics Calculator which computes the data to a very exact point based on the data I input from real ballistics calculators and research gathered.

Edited by Spartan0536

Share this post


Link to post
Share on other sites
Its interesting to note that BIS wanted to tackle the ballistics issue "once and for all" according to one of their dev's which is why they are implementing the initspeed in the weapon parameter

Clearly they did not want to raise the bar too high :)

Yes the BIS system for ballistics is not 100% real, its decent, and its most certainly better than 95% of games out there

Can't argue against that :)

For anyone interested, the reason why my ballistics numbers are so freaking detailed (I get about 3 messages a week about this), its because I use Bakermans Community Ballistics Calculator which computes the data to a very exact point based on the data I input from real ballistics calculators and research gathered.

Better too have one more significant figure, than one less.

Share this post


Link to post
Share on other sites

I just wanted to voice a little bit of my frustration about this portion of the patch notes.

"Added: Weapon muzzle velocities are now correctly defined per weapon and not per magazine as before (backward compatibility is maintained as magazine initSpeed is now considered when there is no initSpeed defined in the weapon, while a weapon defined initSpeed overrides the magazine defined value)"

Now the reason I'm a little irked about this is because it seems to be an "either or" style approach to muzzle velocity (please correct me if wrong). The problem with this is that muzzle velocities per barrel length will only be correct for one type of ammunition per weapon. If the velocity of a mag is overwritten by the velocity of the weapon, an m855 would end up having the same MV as a 262. If we just use the mags to determine muzzle velocity were left in the situation we were a short time ago where muzzle velocities across multiple types of ammo will be correct, but only for one particular barrel length.

What I suggest is that the weapon "initspeed" value actually become a % modifier. As an example a weapon would start with a modifier of lets say 1.0 meaning that it will use the exact MV assigned to the magazine. In the case of m855, the mag initspeed could be set to 930ms. With a weapon initspeed modifier of 1.0, this would simulate the mv of a m855 out of a 20 in 1/7 twist barrel. To simulate the MV of a 14.5in 1/7 twist barrel the init speed modifier would need to be .95. This way you can have a wide variety of muzzle velocities based on barrel length for a wide variety of ammunition types per caliber.

Edited by taco86

Share this post


Link to post
Share on other sites

What I suggest is that the weapon "initspeed" value actually become a % modifier. As an example a weapon would start with a modifier of lets say 1.0 meaning that it will use the exact MV assigned to the magazine. In the case of m855, the mag initspeed could be set to 930ms. With a weapon initspeed modifier of 1.0, this would simulate the mv of a m855 out of a 20 in 1/7 twist barrel. To simulate the MV of a 14.5in 1/7 twist barrel the init speed modifier would need to be .95. This way you can have a wide variety of muzzle velocities based on barrel length for a wide variety of ammunition types per caliber.

I believe this is how it works currently. I.e. the weapon's initspeed modifies the value defined for the magazine.

Share this post


Link to post
Share on other sites

taco86: What you are proposing was proposed day one in the dev-branch thread when the first change was released there. BI listened and they changed the behaviour to accomodate both their own need and that of addon makers.

The way it works now is:

initSpeed in cfgWeapon with positive value overrides cfgMagazines

initSpeed in cfgWeapon with value of zero inherits initSpeed from cfgMagazines

initSpeed in cfgWeapon with negative value is treated as a multiplier, for example initSpeed = -0.8; means you will have 80% of initSpeed in cfgMagazines

Share this post


Link to post
Share on other sites

Does it modify it or replace it?

The wording in the patch notes indicates that it replaces it, "while a weapon defined initSpeed overrides the magazine defined value".

---------- Post added at 14:55 ---------- Previous post was at 14:54 ----------

Wow, that's just fantastic brisse! I'm very very excited to hear that. I was freaking out over the manner in which the patch notes worded it.

I can now breathe easy, thanks again.

Share this post


Link to post
Share on other sites
Wow, that's just fantastic brisse! I'm very very excited to hear that. I was freaking out over the manner in which the patch notes worded it.

Actually, if you scroll down in the patch notes you will see the second iteration of the feature. It's because BI just copy/paste their change-log from dev-branch so if something is changed twice, it will appear at two different places in the changelog. It's always been like that.

Share this post


Link to post
Share on other sites

Disclaimer: Apparently it had to be -0.x to be a modifier, as -1 is treated as of it were 0.

Share this post


Link to post
Share on other sites
Disclaimer: Apparently it had to be -0.x to be a modifier, as -1 is treated as of it were 0.

Actually, it's the other way around, 0 is treated as -1 :icon_twisted:

Share this post


Link to post
Share on other sites

With both (or the omission of a weapon config initSpeed parameter) resulting in "use the magazine's initSpeed"?

Share this post


Link to post
Share on other sites
With both (or the omission of a weapon config initSpeed parameter) resulting in "use the magazine's initSpeed"?

Engine sets the value to -1 as default if there is no value in config, so yes, both values and no value at all result in using initSpeed from the magazine :icon_twisted:

Share this post


Link to post
Share on other sites
I hope we will get working bipods, does anyone know if we will get that?

Apparently the technology is just not there. I'm hoping for ArmA 4.

Share this post


Link to post
Share on other sites

Well now that a BI Dev is viewing this thread actively, perhaps he/she can relay my suggestion, considering that the ground work for initspeed can be set in the weapon init section it should in theory not be very difficult to allow additional parameters to be set within that same bracket. Again allowing aliasing of additional magazines would greatly help the community and could even be played into an additional expansion where either AP or OTM BIS bullets could be offered, just a thought.

Share this post


Link to post
Share on other sites
Apparently the technology is just not there. I'm hoping for ArmA 4.

I'm sorry, but are you drunk? :)

Working bipods will be part of the Marksmen update. It's been official news for a while now.

Share this post


Link to post
Share on other sites
Well now that a BI Dev is viewing this thread actively, perhaps he/she can relay my suggestion, considering that the ground work for initspeed can be set in the weapon init section it should in theory not be very difficult to allow additional parameters to be set within that same bracket. Again allowing aliasing of additional magazines would greatly help the community and could even be played into an additional expansion where either AP or OTM BIS bullets could be offered, just a thought.

I still dont understand why you need to set other parameters in weapon config. Check first reply in this thread.

airFriction is constant for a projectile, it does not change with speed.

hit is calculated depending on velocity of a bullet. Lower initspeed -> lower hit.

Share this post


Link to post
Share on other sites
airFriction is constant for a projectile, it does not change with speed.

hit is calculated depending on velocity of a bullet. Lower initspeed -> lower hit.

Sadly, airfriction is not constant. The way it's currently implemented, it is treated as constant, but for full realism, it would need to change dynamically as the velocity decreases all along the projectiles trajectory, not just at the muzzle. This is a flaw in spartan's proposed workaround, because it should keep changing after the projectile leaves the barrel. That would not be very practical to configure though, and that's why I like Ruthberg's Advanced Ballistics so much. It throws airfriction out of the window and lets you set a ballistic coefficient instead, which is much more constant with velocity so there's no need to define it more than once for every projectile, and the trajectory is much more accurate to reality.

Lower initspeed is not necessarily equal to lower hit. It depends on how it's set up. I think this is how it works. Let me illustrate it with Micro$oft Paint :)

r9ij3a.jpg

So you see, as long as initSpeed is above typicalSpeed, it does not affect hit at the muzzle.

Edited by Brisse

Share this post


Link to post
Share on other sites
Sadly, airfriction is not constant. The way it's currently implemented, it is treated as constant, but for full realism, it would need to change dynamically as the velocity decreases all along the projectiles trajectory, not just at the muzzle.

Looking at a lot of Drag Coefficient graphs using older ballistic models rather than doppler measurements CD is pretty constant below Mach 1 (~340 ms-1) so you could likely get away with using the standard airFriction parameter below that speed. Mach 1 is where the drag reaches a maximum before dropping off sharply towards the lower value. Above Mach 1 there seems to be an exponential decay in the drag coefficient as velocity increases, which tends towards the same sub-Mach value.

300px-Dragcoeff.gif

Since the other real life factors that effect airFriction as an approximation of CDÏA/2m are constant, you could plot that sort of curve of supersonic behaviour with as little as three parameters: airFriction (the basline value) airFrictionMax (the maximum airFriction when velocity is = 340 ms-1) and a single constant (I'll denote it as KB) that defines the rate of decay in the airFriction value once it goes over Mach 1.

This is a plot of f(v) = (airFrictionMax-airFriction)*e-(v-340)/KB + airFriction where airFrictionMax = 0.45, airFriction = 0.1, blue line has KB = 1100 and red line has KB = 400 for a faster decay towards airFriction = 1. You can see it exhibits the same sort of behaviour as the graphs showing drag coefficient plots at supersonic speed in the Mach 1 to Mach 3 region, with airFrictionMax at Mach 1 and decaying towards the basline value as velocity increases.

FQAfWzi.png

One would need a way of modulating the additional exponential when v < 340ms-1, so that only the baseline constant airFriction value was used in the drag calculations below that speed.

Share this post


Link to post
Share on other sites

Common calibers like 5.56x45 and 7.62x51 go transsonic (mach 1) at around 800m which is beyond their effective range, so realistic portrayal of supersonic ballistics is way more important than subsonic.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

×