I actually used that recoil webpage to help with some of the last batch of code changes I worked on after Headrock turned the NCTH project over to me. Unfortunately, while the calculator is cool, the problem is converting the results into something the game can use. For intance, if you look at the ".308 Win" sample inputs, you get outputs like:
Momentum: 93.7 lb-fps
Velocity: 11.7 fps
Velocity (at exit): 9.6 fps
Energy: 17.0 ft-lb
Energy (at exit): 11.4 ft-lb

But how does that equate to a mercs attributes? How much Strength (STR), training (MRK) and experience (LVL) does it take to "overcome" 93.7 lb-fps.

Next, the recoil calculator can't take weapon configuration or equipment into consideration. For instance, take a look at images of most big bore hunting/sniper rifles. Most of them include something on the rifle butt which is meant to help compensate for recoil. Watch some videos of a .338 sniper rifle being fired (15.4fps velocity) compared to videos of a .223 assault rifle being fired (5.8fps velocity). The .223 has only about 1/3 the velocity of a .338 but you won't see three times as much recoil because that .338 has built in recoil compensation.

I'm not considering attachments which would modify the results of any built in calculator we might put into the code. I'm just talking about recoil comensation that should be factored into the weapon itself. An M16 or AK often has just a simple, ridgid butt because there's relatively little recoil in these rounds. But a big .50cal Barret or .338 AI AWM have things like piston barrels and heavily padded stocks specifically to help absorb the recoil so that the weapon remain controlable after a shot. These are factors that we don't currently track so they would be holes in any recoil calculator we tried to add to the code.

Not saying this is a bad idea. But it would require adding a ton of data that we don't currently track. I'd much rather see an external formula we could use to setup the recoil (and even ubShotsPer4Turns) tags that already exist. Unfortuantely, coming up with that formula has so far been beyond me. If you can come up with a system, I'd love to hear about it. If it works, I'll do what I can to help get it put into the game.

Logisteric, normally I would use kg-mps (Kilogram-meters per second) but the calculator Cell presented defaulted to lb-fps for me. It's just just for demonstration purposes anyway. Regardless of whether I use metric or Imperial, the issue is the same: How do we equate the values a calculator like this presents with the attributes we use in the game.

Well of course that's true JMich. If you want to setup your bipod and stabilized it than you need even more APs to ready in prone than in any other positions. In that case i was wrong. In the end would make sense don't you think? Positive or negative is another story.

If that's implemented there should be an option to let the bipod swing freely, taking away the draw-penalty but with a small risk of damaging it when going prone.

I don't think new tags is the way to go. As I said, even if you added a recoil calculator to the code, that calculator wouldn't be able to take every weapon characteristic into account. Not unless you added even more tags. You'd not only have to account for weapon and bullet weight, muzzle energy and all that, but you'd also have to account for where the firing chamber is in relation to where the shooter interacts with the weapon and all weapon modifications that might impact recoil (like piston barrels, padded stocks and other forms of recoil compensation). And even if you added all these new tags, you'd be making the recoil system very complicated to modify AND taking some control out of modders hands because now instead of telling the game what a weapons recoil should be, you're letting the game tell you.

Yes, we need some kind of equation or calculation that can be used to setup recoil values for the weapons (existing and future), but I don't think that should be an internal, game manufactured value. We need an external process that we can use on every weapon. Something better then what we have now which is basically, "I think the M16 should have this and the AK should have this but I have no real data to back it up with other then my opinion".

As for the rest, I suppose that, yes, it could be possible to make the tag (and others) into stance specific modifiers. I'm not talking about whether your bipod example is plausible or not. Simply that it is possible to make the tag stance specific. We'd simply have to re-arrange some of the variables in the item structure and update the code so that it included a stance check when calling these variables.

Ah, not everyone in the modding community will agrees with the influence, proportions or for that matter inclusion of real-world characteristic X being translated into the turn based game mechanics of JA2 v1.13.

I agree that given perfect knowledge of weapon characteristics there should be a systematic approach to weapon stats (in this guns and gaming utopia I suppose we'd all agree on one system too), but:

1) we do not have the a lot of the necessary information for a system - meaning we need to fudge the results somehow (better to hide it away from in-game files)

2) there is disagreement over how much of an abstraction from real world stats are needed to balance this into a worthwhile gaming experience. ie. fun vs. "realism" (I question how much adherence to "realism" is possible in what is essentially a turn based game with an AI of questionable ability ten years ago) Direct in-game use of real world characteristics would limit different interpretations of how JA2 v1.13 can be modded.

No, the game doesn't determine recoil right now. It simply determines the results of the recoil values that are specified in the xml files. What you're talking about would be removing the RecoilX and RecoilY values and replacing them with tags that then allow the code to calculate RecoilX/Y for itself. The results being, if a modder wanted to change the recoil of a weapon he'd have to change multiple tags to get the desired result.

And ultimately whether we used an internal or external equation, we still need the equation first. You could add tags to hold weapon data to calculate a recoil value with, but until we have some idea how to equate the resulting feet/meters per second (or lb-fps/kg-mps) results to the statisics we use for mercs (strength, marksmenship, level, etc), those tags don't do us any more good then we have right now. I mean, I can calculate these values right now. To be honest, I have, repeatedly. But the results don't mean anything. Sure, they tell me the velocity, momentum and energy created when firing a gun, but since I have no idea how much velocity/momentum/energy a STR 50, MRK 50, LVL 5 merc can control, the resulting values are little more then gibberish. A .223 round fired from a 7.5lb weapon results in 43.6lb-fps of momentum, 5.8fps of velocity and 3.9 ft-lb of energy, but so what? These values don't do anything in the game unless I have some way to "compare" them to a mercs statistics.

In other words, it's not the velocity/momentum/energy created by the weapon that I need an equation for. It's the amount of velocity/momentum/energy that a merc can deal with that needs to be calculated. Once there is some kind of conversion (X strength/marksmenship/level negates Y velocity/momentum/energy), then resolving the problems with the existing recoil system should be pretty straight forward.

For starters, I don't think it would make it "very modder-/userfriendly" to have lots of different tags that get used by the code to determine RecoilX/Y factors. Not only would modders and users have to fully understand the implications of every tag to make a valid decision as to how to alter them, it's just more work having to change 4+ tags to get a desired recoil result. At least as compared to the existing system which simply involves a modder/user chaning up to 2 tags. I want a good equation that we can use to create valid, initial RecoilX/Y values, but I don't want the code making those calculations itself because that will only make it harder for users/modders to make changes down the road. The purpose of the external equation is simply to come up with recoil values that have some kind of logical basis as opposed to me simply picking values out of thin air.

The examples you used for stats are for the CTH system. Not the recoil system. Recoil is part of NCTH but it handles it's own calculations. Max Counterforce (CFM) is calculated based on a mercs STR, AGL and Level. Counterforce Accuracy (CFA) is calculated based on a mercs DEX, WIS, AGL, Level and traits.

Stance is handled as a modifier to CFM. So we calculate base CFM first on the assumption that a merc is standing and without factoring attachments and such. Once we have the base CFM, we modify it based on stance and any attachments a weapon has. So if a merc is crouching, his CFM goes up. If a weapon has a retractable/folding stock, a merc's CFM goes down. And being prone gives even greater counter force then standing or crouching. A standing shooter has to rely more on his own strength to control the weapon and compensate for recoil. A crouching shooter is more stable and therefore can use more of his body mass to help deal with the effects of recoil. And a prone shooter gets to use all is body mass to help deal with recoil.

Keep in mind that recoil and stability aren't the same thing. Weapons with long barrels are heavier and therefore the weapon will move less when firing the same round as a weapon with a shorter barrel. Also, the greatest impact of recoil occurs when the expanding gasses actually leave the barrel. The further those gasses are from the firing chamber, the less overall recoil compensation is needed. So longer barreled weapons will ultimatly have less recoil then shorter barrel weapons. Take a 10ga shotgun and fire it. Now saw off 6 inches of that barrel and fire it again. You're going to feel significantly more recoil from the sawed off variant because the escaping gases are closer to the firing chamber.
Stability, on the other hand, would less for a long barreled weapon.
In the code, recoil is handled by RecoilX/Y tags while weapon stability is handled by the Handling tag. Recoil (as we're currently discussing it) only effects automatic weapons because all we're trying to determine is how much the barrel moves between one bullet and the next (though part of recoil compensation is built in to the ShotsPer4Turn tag). Stability/Handling, on the other hand, effects every weapon.

Some of your attribute discussion doesn't make sense are far as recoil is concerned. Or did I misunderstand and you're trying to comment on the entire system at once. NCTH is a pretty complicated system, especially if you don't break it down into smaller pieces. The firing sequence of the code works, in my opinion, and therefore doesn't need alot of messing with. The recoil compensation system in the code also works (again, IMO) but you know the saying, 'Garbage in, Garbage out'. Well, we're throwing in recoil values that have been all but pulled out of my ass, then comparing them to stats like they are apples and oranges, and expecting the result to make sense. In other words, we're tossing garbage into the code and expecting to get something other then garbage back out of the code. We need an equation we can use to generate RecoilX/Y values for every weapon AND we need a way to compare a merc's in-game stats with the weapon's RecoilX/Y values. Once we have both of those, the recoil system will work just fine. In other words, if we know that a STR50/AGL50/LvL5 merc generates a base CFM = 5.0 (which is what the code currently generates), and we know that an M16 produces 6.8fps Velocity, all we need to know is how many fps does that 5.0 CFM compensate for. And before you consider a 1:1 ratio, consider that an FN FAL produces around 9.5fps velocity which means a merc with STR97/AGL95/LvL9 (resulting in a base CFM=9.5) could fire the FAL with no worries about recoil. Of course, maybe that's exactly what we do want.

CounterForce Frequency (CFF) is a value that we haven't really worked with yet. It's certainly a functino that needs to be fixed since, right now, it's solely based on the weapons rate of fire. A merc's stats have no baring at this point. That said, CFF is a vary tiny consideration compared to the rest of the recoil system. I'd much rather get CFM calculated and working correctly. Then we can take a look at the CFF system.

The equation that generates CFM is the same one that Headrock originally wrote. The only real change I made to CFM was to remove the upper limit. Originally Headrock had CFM result in a 0.0-10.0 value, with 10.0 being possible by any merc with STR100/AGL100/LvL10, which is perfectly possible in the game. But that also means that a 100/100/10 merc gets absolutely no alteration in CFM based on stance or attachments. In other words, a 100/100/10 merc who goes prone has exactly the same CFM as if he were standing. A 100/100/10 merc has exactly the same CFM whether he fits his weapon with a foregrip or not. Etc. This made no sense to me. Fitting a foregrip should increase CFM regardless of the mercs stats. That doesn't mean a foregrip is necessarily needed. For instance, it's a pretty safe bet that a 100/100/10 merc who tried to fire a fully automatic .22LR SMG is not going to need a foregrip to have more then enough CFM to compensate for whatever recoil the weapon could produce. But that doesn't change the fact that adding a foregrip would increase the merc's CFM. So I removed that limitation. But other then that, the equation that calculates CFM is the same one Headrock originally wrote. I don't believe that is where the problem currently exists. The problem we have right now is, how many lb-fps (or kg-mps) does CFM1.0 actually compensate for?
Should it be 1:1? Should a M16A1 (2.9kg or 6.4lb) which produces 6.8fps velocity be completely compensated by a CFM=6.8? That same weapon also produces 4.6ft-lb of energy and 43.6lb-fps of momentum. Should any of those values be used with or instead of velocity? And if so, how do they equate to CFM?
Keeping in mind that even if you negate all the recoil with CFM, there is still your ability to accuratly apply counterforce which has built in minimum values. So even that 100/100/10 example merc firing a .22LR SMG can't put every round into the exact same spot simply because no matter how good you are, you're still human and therefore can't be completely perfect.

The code has three seperate components for dealing with the results of recoil:
1- The amount of recoil that a merc can compensate for (CFM)
2- The accuracy with which a merc can apply that counterforce (CFA)
3- The speed with which the merc can make adjustments in the amount of counterforce he's applying (CFF)
All three of these values work together to determine the overall results of recoil. A really strong merc may be physically able to counter the effects of recoil, but he may not be able to counter it accurately enough to hit with every round. On the other hand, a weak merc may not be able to really control the recoil in his weapon, but he may be very accurate in the control that he has to still have a chance to hit with a few of the rounds fired. But, again, I think the calculations we make that generate these values, and the way these values work together works fine. My problem is coming up with RecoilX/Y values for the weapons that I can compare with CFM in a meaningfull way. It does me no good to say a merc has a CFM=13.5 if I don't know what that means for the weapon. And it does me no good to say a weapon has RecoilX/Y=11 if I don't know what that means for the merc.

I'm confused. I thought we were talking about the problems that currently exist in the recoil system (specifically in how counterforce is being handled versus the recoil of a weapon). Alot of what you're commenting on doesn't have anything to do with any of that. For that matter, some of what you're questioning doesn't technically have anything to do with NCTH at all.

Cell

How fast a bullet can fly is it the weapon, the bullet itself or both?

This has nothing to do with how NCTH works so I don't understand what we're talking aboutCell

Have different cartridges, different effects for the weapon?

This has nothing to do with how NCTH works so I don't understand what we're talking aboutCell

Muzzle velocity is defined by the cartridge, by the weapon or by both?

Both but I don't see how this has anything to with how NCTH works. Muzzle velocity ultimately has a bearing on weapon recoil, which means it would have an effect on the ShotsPer4Turn and RecoilX/Y tags, but you don't use muzzle velocity directly in any of the NCTH calculations.Cell

What is responsible for accuracy?

This is part of the actual NCTH calculation but has nothing to do with recoil or counterforce which is what I thought we were discussing. Accuracy of a weapon is based on the real life effective range of the weapon and a few other variables as laid out in a spreadsheet that Headrock built when originally designing NCTH.Cell

What is responsible for muzzle climb?

Muzzle "climb" is dealt with by the RecoilX/Y tags and the way counterforce is applied. This is all part of the NCTH-recoil subsystem which is the one part of NCTH that still needs tweeking because the existing RecoilX/Y values have no validity.Cell

What does ROF mean for our merc?

Huh? ROF doesn't really have anything to do with NCTH. ROF is used to generate the bAutofireShotsPerFiveAP tag but that's not really directly related to NCTH. NCTH is the chance to hit when a bullet is fired. It doesn't really care if you for 1 bullet or 100. Each is handled seperately.Cell

Barrel length affect what?

I expect barrel length would effect accuracy (both nAccuracy and bAccuracy) plus the ReadyAP cost. it would also indirectly effect whatever calculations are eventually used to generate valid RecoilX/Y values. Also it would have an effect on the Handling tag. But it's not really a direct NCTH value. It simply relates to have tags would be generated (if that makes sense).Cell

The aiming skills of a shooter depend of?

I don't understand what you're asking. A merc's Marksmenship skill has a direct baring on how NCTH works.Cell

Why is there no difference in amount of amining level between a MRK 50 to a MRK 100?

Why would a MRK 100 merc get to aim more/less then a MRK 50 merc? In NCTH, aiming levels represent the amount of time it takes to fully aim a weapon. Small, light weight weapons take relatively little time to reach "maxAim" as compared with large, heavy weapons. The shooters skill has nothing directly to do with that (though indirectly, mercs with high stats have more APs to spend resulting in each aim click taking less "time"). The shooters skill simply determines (along with numerous other variables) what the "maxAim" value can be.

Anyway, help me out here. If we're talking about NCTH as a whole system, then either pick one part of NCTH to talk about or get ready for excessivly long posts cause there are tons of "pieces" to NCTH. If we're just talking about the recoil subsystem (which is what I thought we were discussing) then help me understand where all the rest of this is coming from.

Um, no. ROF has nothing to do with recoil. You'll get the exact same recoil firing a .223 round from a 2.9kg M16 regardless of whether the weapon fires 200rnds per minute or 2000. With a very few exceptions (like the G11) it's not like you pull the trigger, 5 rounds leave the barrel AND THEN you feel recoil. Every bullet that leaves the barrel causes it's own, seperate recoil. And the existing NCTH recoil system DOES take that into account. Every bullet that gets fired offsets the previous bullet trajectory by the weapons RecoilX/Y tags (modified by CFM and CFA).

The G11 and AN-94 are special case weapons. In both of these cases, a certain number of rounds actually do leave the weapon before the shooter actually feels the effects of recoil. And this functionality is ALSO already built into the recoil system. ubRecoilDelay is the tag that determines how many bullets get fired before the effects of recoil are considered.

Higher rates of fire (bAutofireShotsPerFiveAP is the tag that reflects this) are factored into the CFF calculation. Actually, right now bAutofireShotsPerFiveAP is the ONLY factor for determining CFF. CFF determines how many rounds have to fire before a shooter can alter his counterforce. So a relatively slow weapon like the RPK74 (bAutofireShotsPerFiveAP=3) gets a CFF of 2 while a fairly high ROF weapon like the Minimi (bAutofireShotsPerFiveAP=5) gets a CFF of 3. This means when a shooter starts firing he initially tries to compensate for what he expects the recoil to be like. This is called "preRecoil". The shooter knows there is going to be recoil and tries to compensate based on what he expect the recoil to be. Then after CFF number of rounds have fired, he can alter the amount (and direction) of counterforce being applied to try and more accurately compensate. This compensation amount will be used until the next CFF sequence. So, a merc shots a 7rnd burst from a Minimi:
0) Before he actually squeezes the trigger he automatically tries to guess how much recoil there is going to be (this guess is also based on the mercs various stats).
1-2) These first two shots get compensation amounts based on the initial guess.
3) Since the Minimi gets a CFF=3, this is when our merc can recognize that he's over/under compensating for recoil and alter the amount (and direction) of compensation being applied
4-5) The same amount of compensation from shot 3 is applied for the next 2 rounds
6) This is the next round where the shooter is able to try to adjust his compensation
7) The final round of the burst will apply the same amount of compensation as what was determined during the 6th round.

You don't need barrel length, overall length, speed or any of these other values. Yes, they are all part of equation we should use to generate the RecoilX/Y values. And that equation should be made available to modders once a good equation is generated. But you factor them in when you create the RecoilX/Y values. The code doesn't use them. There's alot more potential for confusion, not to mention more work for modders, if the code calculates the RecoilX/Y values for itself. Modders want to say, "this weapon has THIS recoil". With a simple pair of RecoilX/Y tags, they can easily do that. If the code calculates RecoilX/Y for itself, the modder has to figure out what combination of values results in the RecoilX/Y values that he ultimately wants.

As I know I've mentioned before, the only thing that the recoil system needs at this moment is a valid equation I can use to generate legitmate RecoilX/Y values that have relevence to the way the code calculates Maximum Counterforce. Once we have valid RecoilX/Y numbers, if there are still concerns with the recoil system I'll be happy to look into them. But right now any tweeks I make to the recoil system don't create a understandable results because the existing recoil values are pretty much bogus.
M16A1 has a recoil factor of 6. AK47 has a recoil factor of 15. AK is a heavier weapon that fires a round with with a lower muzzle velocity (715m/s vs M16 at 948m/s) which means the AK should have a lower recoil factor yet it's currently 2.5 times higher (worse) then the M16.
The Minimi fires the same round as the M16 yet weighs over twice what the M16A1 does. But both weapons have the same recoil factor of 6. The heavier Minimi should really have a lower recoil factor then the M16 because the weapons weight has a direct impact on the amount of recoil energy produced.
Until the existing recoil values get corrected, there isn't a whole lot I can do with the recoil code. I need legitimate recoil values that can be legitimately compared to the CFM values the game produces. Until I can get legitimate recoil values, there isn't anything more I can do with the recoil system.

Cell, you seem to believe that each and every weapon with a barrel of, let's say 5.5 in (140mm), a weight of 5,6lb (2.5kg) using 9mm bullets should have the same recoil. What about Kriss V that uses a different recoil path for the bolt? What about bolt-action vs automatic, which the bolt-action handles recoil differently? What about a myriad other things during design that can change how recoil is felt (see Mag-na-port).
While a function (or equation if you prefer) that takes statistics of the weapon into account would help with getting real recoil values, the game shouldn't compute them itself.
And what about a Sci-Fi gun that propels bullets through electromagnetism, like the Gauss Guns, or railguns, or any other weapon one would like to introduce that doesn't have recoil (again, probably Sci-Fi ones, but not sure if we won't see any of those in our lifetimes).

As ChrisL has told you before, if you do have such an equation, write it for us, so the modders can use it as a base. There should be 2 equations though, one for the recoil and one for the force a merc would be able to exert, since the recoil isn't a factor of the person carrying.

And finally, so far only one modder has given any real thought to the NCTH values (all of them, not just recoil), and that is Wil473.

Cell

Headrock didnt take account of ROF which i cant understand cause the rate of fire is a huge impact when it comes to recoil.

And last but not least, I couldn't refrain from quoting this line of you. Do you really need an explanation on why this is so very very wrong, or can you see it yourself?

The muzzle climb (burst/auto) isn't similar with a weapon of ROF 300 to a weapon of ROF 900! Do you think the counter force frequence is similar? Are you kidding me?

Muzzle Climb =/= Recoil.
Muzzle Climb is the sum of all recoil values during a period of time, so yes, a weapon with a greater ROF will probably have a higher muzzle climb. So, no matter the ROF of a weapon, the RECOIL will be the same.
I never said that there isn't a difference in the counterforce required to control a weapon with higher rate of fire, but again, READ WHAT YOU WRITE.

Also, you again suggest an ingame function that will take a number of variables (3? 5? 20?) and calculate recoil, and then the modder will have 1 or 2 ways of modifying it. So for each weapon we need at least 5 (barrel, weight, bullet, percentage modifier, flat modifier) to get 2 recoil values, while currently we have 2 values (RecoilX, RecoilY). Write me the function (Barrel * Propelant / Weight for example), and I promise I'll give you an excel spreadsheet that will return to you the recoil of it. Then the modder will plug the numbers in the excel, get the RecoilX and RecoilY values that the function calculates, modify them as he/she sees fit, and add 2 numbers to the weapon.

Finally, for the Recoil Counter Force and Counter Force Frequency. As ChrisL told you, each bullet in a volley adds to the recoil, and every X bullets the shooter tries to compensate, reducing the gun's recoil by the Counter Force amount. A weapon with a higher ROF will have the recoil added more often, and the counter force frequency will be lower, since if you adjust the gun every 5 seconds, more bullets will have left, so there will be more muzzle climb to adjust. Both of these things are already implemented.

So, in which part am I kidding you, other than pointing to you that you 1) ask things that are already there, 2) ask for the game to require a huge more amount of variables to give us the same results we can get with a lot less, while still not sacrificing authenticity and 3) not knowing the difference between recoil and muzzle climb?

Recoil and muzzle climb are NOT based on ROF. They are strictly based on the amount of recoil energy each round generates, versus the amount of recoil energy that the shooter can compensate for. Fire a 10rnd burst from a 7.62x51mm battle rifle. Odds are that a merc will not have enough strength to totally negate the recoil energy of that 7.62x51mm round so there will be some left over recoil energy resulting in a small amount of muzzle climb. That small amount of left over energy will effectively "add up" as each round in our 10rnd burst is fired. This is true whether the battle rifle in question has a 450 cyclic rate or a 1800 cyclic rate. The only question is HOW QUICKLY the muzzle climb occurs, which has really no baring on the game.

And I should point out that you compensate for the recoil energy of every round fired regardless of the CounterForce Frequency (CFF) results (which IS based on ROF). CFF simply determines when you can change the amount of force you're applying.
The recoil system has a built in "human factor". In other words, say a weapon has RecoilX=0, RecoilY=6 and that a shooter has Max CounterForce (CFM) of 8.0. Technically, our shooter has more then enough CFM to counter all the recoil energy produced by the weapon. But just because he CAN overcome all the recoil energy doesn't mean he's going to apply exactly 6 points of CF on the Y axis and absolutely no CF on the X axis. Humans always over or under compensate. So while a perfect CF applicatino would be 0/6, our shooter may actually apply -0.5/5.5 or 0.4/6.8 or any number of other results all based on CounterForce Accuracy (CFA) and the built in minimum variance. During the course of a burst, the shooter is going to realize that he's over or under compensating and he's going to change the amount of CF that he is applying. That change occurs at CFF intervals. So if you have a high ROF weapon, you'll have a high CFF meaning more rounds get fired using "old" CF results.
Take this example out further. Lets assume our weapon has a CFF=3 and we initially calculate that 0.3/6.2 if the "proper" amount of recoil to apply. We're firing a 10rnd burst. When the first round fires, instead of the shot going to 0/0 (the point we're aiming for) where we want it to go, our first round will actually go to 0.3/-0.2. In essence, we're overcompensating for the recoil on the X-axis by shifting the barrel right by 0.3 and we're overcompensating on the Y-axis by pushing the barrel down more then the 6 that it's stats say, resulting in a barrel drop of -0.2. When the 2nd round is fired, we're still going to use the same CF results as the first because we haven't fired enough rounds to meet our CFF requirement. So our 2nd round is going to go to 0.6/-0.4. And our 3rd round will be at 0.9/-0.6. We have hit our CFF round so we recalculate CF and realize, "woops, I've been overcompensating" so we try to adjust not only for the weapons recoil energy but ALSO the overcompensation we previously caused. We actually WANT to attempt to pull the gun left and ALLOW the muzzle to climb a little. Our new "perfect" CF calculations would therefore be -0.3/5.8 (we divide the alteration over CFF number of rounds). The code applies "human error" and we end up with a result of -0.2/5.9 meaning we're undercompensating a bit on the X-axis and still overcompensating a bit on the Y-axis. But we'll have to fire another 3 rounds from our burst before we realize the mistake.
Weapons with a slower RoF (i.e. lower bAutofireShotsPerFiveAP tag) have a lower CFF meaning a shooter adjusts his CF calculations "more frequently". Weapons with a higher RoF (i.e. higher bAutofireShotsPerFiveAP tag) have a higher CFF meaning a shooter adjusts his CF calculations "less frequently".

So, yes, ROF is already be factored into the recoil system in just the way it should be.
And, yes, when we finally get an equation I can use to generate RecoilX/Y values (which has a usable correlation to the CFM calculations already in the code), that equation will include weapon data like bullet weight, bullet velocity and weapon weight.
But the calculations will be run externally and applied in the existing tags. This is the best way to give modders the most control over the data results.

1) You assume that with enough variables, the game could calculate itself the necessary recoil values for any weapon, where recoil is defined as how much the barrel would move after firing one bullet.
Currently, we have 2 tags for that, RecoilX which tells us the horizontal deviation and RecoilY which tells us the vertical deviation. You wish to change these 2 variables with 5 variables, Barrel Length, Bullet Velocity, Bullet Weight, Flat Recoil Modifier and Percent Recoil Modifier, though I do believe that the recoil modifiers should also be different for vertical and horizontal ones. Again, see Mag-na-port. However, you also want to calculate the bullet's speed through use of the calibers, with an equation that will take in account the propellant's mass, the propellant's quality, the barrel's quality (a good barrel will allow more gas to propel the bullet, thus more recoil) and I'm still not sure how many other variables. So you suggest we replace our 2 variables with 10, for ease-of-use.

2) You assume that all weapons work in accordance to Newton's 3 laws. So, again since you've probably didn't see it before, what about railguns or coilguns? Both these weapons were built by amateurs, but they do prove that the concept is working.
P.S. Railguns were patented in 1919, while coilguns first appeared in 1933. I do believe that we will be seeing these weapons deployed on the field in our generation, even if not from our countries.

3) MJOne has calculated some "better" values for calibers, through the use of a formula. If I understand correctly, you would like that formula to be part of the game, and not in the hands of a modder to adjust as he sees fit. So if a modder decides that the bullet fired is acid, so the tumble damage should be 5 times higher, the code should correct it back to normal since the bullet's statistics do not compute to the value the modder wanted. So again, we should have an extra variable for the modder to adjust values as he/she sees fit. So instead of the 10 values we currently have for each caliber to adjust the damage, how many would we need? (P.S. the current 10 values are easy to understand, and anyone can see how changing any of those would affect the game. How much difference in the tumble part would a doubling of the propelant's mass do?)

4)Cell

Headrock didnt take account of ROF which i cant understand cause the rate of fire is a huge impact when it comes to recoil.

Cell

The muzzle climb (burst/auto) isn't similar with a weapon of ROF 300 to a weapon of ROF 900! Do you think the counter force frequence is similar? Are you kidding me?

These are the two posts of you I read and "gave a lecture" on the differences between recoil and muzzle climb. Not sure how I misunderstood you, so I'm awaiting of an explanation. And no, Cell

you could prevent this point by reading more thoughtfully.

is not an explanation.

5) The tl;dr version. You wish to have a lot of variables to replace the few easy ones we currently use. You do wish to allow the modder the ability to change the values calculated, which means that the modder will have to add the value himself after all.

I did. All of them say: Muzzle climb is because of the bullet fired through an explosion in a confined space, we can compute the rise if we have ALL the variables, which means about 100 of them. If you see, all of them take in consideration the momentum of the bullet with the momentum of the gun, and assume the gun is a rigid thing (again, see Kriss Vector). Also, the muzzle climb can be changed, with proper exhaust ports (again, see Mag-na-port).
I never said that calculation was impossible, I just said that the number of variables required is too many.

Edit due to your double post.
The problems is the huge amount of variables needed for correct calculations. A 5.56 FMJ bullet will have different penetration abilities if fired from different guns, due to differences in the barrel. We can assume either that all 5.56 FMJ bullets will behave the same, or that all barrels are the same, unless we add even more variables. The current amount of variables is many, you want it changed to "too bloody many".