I see another problem with recoil. Recoil itself should not drive the barrel in any direction, ideally; a very good weapon is well-balanced and its recoil is only applied in the direction of your shoulder, which can start to ache after a while, but doesn't affect aiming directly. Vertical and horizontal recoil doesn't depend as much upon recoil velocity or recoil energy as it does on the design of the rifle. If its center of mass is along the line of the barrel, there shouldn't be horizontal and vertical recoil at all; the further it deviates from it, the more the weapon's mass and the bullet's kinetic energy and the weapon's anti-recoil mechanisms start to matter.

The tests I've been playing with have SMGs in the 12pt range and LMGs in the 4pt range. And considering a merc (without aid) can counter up to 10 points of recoil (more with the aid of attachments), I figure the values I have now just aren't gonna work. If anyone has any suggestions, I'd love to hear them as this is the only thing keeping me from posting a new build for you guys to start testing.

max_da_killah

That aside, i seem to be unable to find a ## value in the items.xml or any other xml/ini.

It's ScopeMagFactor and if you can't find it in your Items.xml file, you're using an outdated or incorrect Items.xml file.

I see another problem with recoil. Recoil itself should not drive the barrel in any direction, ideally; a very good weapon is well-balanced and its recoil is only applied in the direction of your shoulder, which can start to ache after a while, but doesn't affect aiming directly. Vertical and horizontal recoil doesn't depend as much upon recoil velocity or recoil energy as it does on the design of the rifle. If its center of mass is along the line of the barrel, there shouldn't be horizontal and vertical recoil at all; the further it deviates from it, the more the weapon's mass and the bullet's kinetic energy and the weapon's anti-recoil mechanisms start to matter.

I have no idea where to get these values except to make them up and correct as we go along. The general rule that a average LMG should have better recoil than the average SMG should be followed, sure, but that's not a strict rule. Maybe the weapon's price should also be taken into account? The higher the price, the better its recoil among the weapon's kind? We can't exactly research every weapon out there and calculate these values.

I've uploaded a new build that should deal with the recoil issues, at least as far as the code is concerned. The build is available at http://www.mediafire.com/ncth and is the 4099 version. I've also uploaded a debug version so that the Missed Offset values can be displayed for anyone interested. And there's a new items.xml, weapons.xml and cthconstants.ini here as well. These are the same three files I've just committed to the dev branch and they should at least help with the recoil balancing.

EDIT: I should make it clear. The code should be working just fine. And the xml files I've committed (and made available at mediafire) have been updated with new values. But I don't guarantee that those values are properly balanced. So recoil isn't "perfect" but it should be better then it was before. Hopefully someone else can come along and work up some realistic recoil values.

In NCTH, fewer aiming clicks is better. Every weapon can ultimatly get the "same" amount of bonus from aim. The difference is simply how much time you have to spend to stabilize the weapon enough to get max aim. The ubAimLevels value in weapons.xml is also only the base aim levels. There are attachments that can "improve the speed of aiming" which thereby lowers the aim clicks you need to reach max aim. Also the Prof_Sniper_OT, Sniper_NT and Gunslinger_NT traits will reduce the number of aim clicks you need to reach max aim. So your merc only needs 5 clicks to reach max aim because you're getting a 3click bonus. Basically, it takes your merc fewer APs to reach max aim then it would someone less trained.

The ISM-V-IR, Kobra, ACOG 4xC, and Reflex Sight each have a -1 AimLevels modifier so if you have any of those attached to your weapon, and you've got 2 levels of either Prof_Sniper_OT or SNIPER_NT, that would explain why you're needing only 5 clicks instead of 8.

Secondly I look at the cursor behavior and notice a huge stepped increase in shooting aperture size from 23 to 24 tiles.
This bug is always (?!) present in the NCTH but it is difficult to spot it without decreasing aim_draw_cost

Alex is not saying NCTH that shots are too inaccurate, but that it's weird that the cth when the target is just one square further.

I'm a little curious just how "accurate" you want to make things. Below is a screenshot for one of my mercs. He's a fairly advanced sniper with the Marksemen stomp trait (2x Sniper) using an AI AWM, prone with a bipod. And as you can see from the image, the target is not only at 72 tiles away, but I can't actually see her (had to turn on cheat codes to reveal all enemies).

This is using the same CTHConstants.ini file that I uploaded to my mediafire page. This shot has pretty much no chance of actually missing the target. So, how much more accurate do you think you'd ever want to make something?

Anyway, AIM_DRAW_COST is strictly a multiplier against the weapons effective "gun aim difficulty". iGunAimDifficulty is the weapon's ubReadyTime, modified by to total PercentReadyTimeAPReduction and PercentHandling tags associated with the weapon and it's attachments, and the AIM_xxxxx_STANCE modifiers from CTHConstants.ini. The last piece factored into iGunAimDifficulty is AIM_DRAW_COST which is a straight multiplier. At the default setting of -1 (that is, "negative one"), it simply converts the iGunAimDifficulty into the penalty it's supposed to represent but if you set the value to 0, you're basically telling NCTH to totally ignore the weapons handling characteristics.

And if I've misunderstood what Alex was getting at, I appologize. But to figure out why you might have a large aperture change between 23 and 24 tiles, I'd really have to have a savegame that demonstrated the problem.

We take the "distance aperture" and reduce it by the mag factor

EDIT: Again, if you set AIM_DRAW_COST to 0 you're turning OFF the modifier for handling characteristics. This is not a bug.

• The "bug" that causes shots at targets who's facing is perpendicular to the shooter to miss a significant number of times. To counter this, I've added a new cthconstants.ini value: SIDE_FACING_DIVISOR The default setting for this is 2.0. Any time a targets is considered to be perpendicular to a shooter (i.e. a shooter who is facing North against a target facing East), we'll reduce the X/Y offsets of the shot by the divisor. I've set the value to 2.0 by default because it should be a little harder to hit a "side facing" target then one facing right towards you. You'll want to download the cthconstants.ini that's included at the above link.
• I've added a new flag to JA2_OPTIONS.INI: USE_NCTH_CURSOR. In NCTH mode, if you set this flag to FALSE, the aperture circles and crosshairs will NOT be displayed. All other ncth cursor information will remain as usual. It's just the aperture that will go away.
• There was a bug in the nAccuracy calculation between the display system and the shooting system which has been resolved.
• I've altered the "color gradiant" of the NCTH circle. Instead of being based on muzzle sway, it's now based on the final aperture value so small apertures will be green and large will be red. As usual, both apertures will get the same color. The color is strictly controled by the smaller of the two apertures.
• I've updated UDB so that the AimLevels entry on the Weapon - Gen page now includes your mercs skill traits were appropriate.
• I've updated UDB so that the Weapon - Adv page now displays Max Counter Force of your merc, and the Counter Force Frequency your merc will get with his weapon.

Is the source code updated too?

Well, I'd seperate aim_xxx_stance from aim_draw_cost, but like I said, they both are just multipliers and both multiply against the same base value (the weapons ubReadyTime). I suppose I could throw in a condition so that aim_draw_cost would reset itself to "1" whenever it was set to 0. But I really don't think that's what you're after.

And yes, this does mean that if you turn off aim_draw_cost, you remove the handling penalty for dual weilding (makes everyone ambidextrous, basically), for firing weapons one handed, and for heavy weapons. There really isn't a way to seperate any of these, however, because they are all multipliers to the weapons base handling characteristics. Which, as I've already said, is based on the weapons ubReadyCost.

A new build is available at my mediafire page: http://www.mediafire.com/ncth

This build includes the following alterations:

• The "bug" that causes shots at targets who's facing is perpendicular to the shooter to miss a significant number of times. To counter this, I've added a new cthconstants.ini value: SIDE_FACING_DIVISOR The default setting for this is 2.0. Any time a targets is considered to be perpendicular to a shooter (i.e. a shooter who is facing North against a target facing East), we'll reduce the X/Y offsets of the shot by the divisor. I've set the value to 2.0 by default because it should be a little harder to hit a "side facing" target then one facing right towards you. You'll want to download the cthconstants.ini that's included at the above link.