Home » MODDING HQ 1.13 » v1.13 General Development Talk » NCTH Ideas
NCTH Ideas[message #298351] Fri, 10 February 2012 02:34 Go to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
Having returned recently to check out 1.13 prompted by the pending release of Back In Action, I spent a lot of time looking over the major overhauls that are integrated into the latest stable, and NCTH seems to be one of the most divisive features.

I just want to throw down some ideas to see if they would help promote NCTH, and maybe one day it won't be an option any more for people returning to 1.13, but instead would be a tweak for how you like the game to be played (like suppression).

On game difficulty:
JA2 is great because even within the confines of the original game rules and data, the experience is unique every playthrough. As we play the game more and more and understand its inner workings, we become better, and eventually we expect a bigger challenge. One of the main issue with vanilla JA2 is that the game is now so well-understood by the community that a lot of people play on INSANE difficulty, which is one of the most immersion-breaking settings throughout the JA2 experience because we can quickly see the lack of depth in the game mechanics (AI, shooting/aiming, etc.) which the wonderful people working on 1.13 have been so actively fixing.

Why is NCTH so divisive?
The Problem of Familiarity
Obviously, people have different preferences and tastes on how a game should play, and the mod-ability of 1.13 has gone a long way to enable those players. However, I would argue that most people who play (or are just starting to play) 1.13 would like to start off in familiar territory, before exploring the confines of the new features and eventually tweaking the game to their liking. A lot of great features that had major impact on how the game is played got integrated to the main branch this way:

- 100AP, when brought to the main branch, was eventually made scalable to arbitrary amounts with the underlying math intact
- Suppression effectiveness is completely tweakable
- Enemy activity pools and patrol rates are completely tweakable
- Drassen Counter-attack on the otherhand, is rather divisive and had to be made an option to turn on or off.

This brings us to NCTH: it

Report message to a moderator

Corporal
Re: NCTH Ideas[message #298612] Sat, 11 February 2012 18:28 Go to previous messageGo to next message
tazpn is currently offline tazpn

 
Messages:99
Registered:December 2007
Location: CA, USA
I like NCTH just not some of the implementation so any tweaking of it is good in my book. Skewing to OCTH is the right thing (or at least an option at game start up to initialize settings with different default levels). The problem is that its hard enough to tune one set let alone 2 or 3.

My frustration with NCTH was around the AI going stupid just out of gun range due to CTH going to zero. I made my own tweaks to extend that so CTH was low but high enough that AI didn't give up. I also set the INI so that it was same as original. Problem with that is not everyone likes to tweak and therefore wouldn't get some of the simple benefits because I didn't tune it.

Also having AI creep in when CTH was low but not zero helped my games. Anything that helps this like extended sight/hearing keeping the AI in the game would be good.

I thought the math already had some NL in it. When I modified I used linear on the extended range just out of simplicity.

Report message to a moderator

Corporal 1st Class
Re: NCTH Ideas[message #298846] Mon, 13 February 2012 20:14 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
When I get a chance I plan to review all the modifiers and penalties in the aiming and bullet deviation sections of the trunk code. If possible I'd also like to write or set up some sort of test program that can simulate hundreds of thousands of shots against a target at various ranges using weapons. I think it'd be really helpful to test and tweak NCTH balance.

Report message to a moderator

Corporal
Re: NCTH Ideas[message #298847] Mon, 13 February 2012 20:22 Go to previous messageGo to next message
DepressivesBrot is currently offline DepressivesBrot

 
Messages:3641
Registered:July 2009
Sounds like a great idea, I hope you don't bite more than you can chew with those tests.
I definitely agree on calling NCTH by another name btw, that would sure help to disconnect it from old expectations.

Btw, there are two deviations of the improved system employed in HAM5 I remember:
There's a function that transforms polar coordinates to cartesian. It produces biased (center heavy) results in the trunk but was fixed to even distribution. The other was a complete rewrite of the counterforce and recoil function, but that shouldn't be of too great concern when balancing single shots.

Report message to a moderator

Captain

Re: NCTH Ideas[message #299990] Wed, 22 February 2012 22:54 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
I'm going to be posting some of my research notes into the codebase here for now just as somewhere to dump my work for others to see.

Assumptions:

I'm using data from Headrock's Targeting Study where he summed up the estimated width and height of someone standing:

STANDING TARGET, front
   Head:   3,4   (12)
   Torso:  7,6   (42)
   Legs:   7,10  (70)
   Total target height:          20
   Total target surface area:    124


Quote:

Torso shot:
Width is greater than height, and height is 6. So to hit the torso dead-center with 100% probability, we need a shooting aperture that is no larger than 6/2 = 3 units.

Head shot:
Height is greater than width, and width is 3. So to his the head dead-center with 100% probability, we need a shooting aperture no larger than 3/2 = 1.5 units.


I'll also re-iterate the definition for "normal distance" here (which happens to be something like 7 tiles or 70 units): The "normal distance" is the distance at which a gun with IRON SIGHTS are fully effective.

I start with something small.

This is the Bullet Deviation function in LOS.cpp

FLOAT CalcBulletDeviation( SOLDIERTYPE *pShooter, FLOAT *dShotOffsetX, FLOAT *dShotOffsetY, OBJECTTYPE *pWeapon, UINT32 uiRange )

// Get gun's effective range
// Get gun's accuracy
// Clamp accuracy between value of 0 to 100

// Calculate the maximum possible deviation of the bullet at Normal Distance
// this value is obtained from the setting, which right now I believe is 5
// MaxPossibleDeviation = 5 (from setting)

// MaxBulletDeviationForThisGun = MaxPossibleDeviation * (100 - GunAccuracy) / 100
// This means a gun with accuracy of 0 will have a max deviation radius of 5 at Normal Distance
// It's also worth noting that this value is linearly scaled with regards to gun accuracy value
// However, actual accuracy is scaled by the bullet deviation SQUARED because it's a circle,
// meaning a 50% reduction in bullet deviation radius results in a 75% smaller circle.

// If you have "Range affects deviation" option turned on in the settings, the MaxBulletDeviationForThisGun
// is further multiplied by a ratio based on target distance and the gun's effective range.

// Pick a random value between 0 and MaxBulletDeviationForThisGun
// This value is now BulletDeviation at Normal Distance
// The value is then further broken down into x and y components (up and down / left and right)
// So at this point we know how much the bullet will stray left/right up/down relative
// to the original shot AT NORMAL DISTANCE

// The above deviation values are then FURTHER scaled by the ratio of the actual distance of the shot 
// to the normal shooting distance (assume that at 7 tiles).
// So if your deviation is calculated to be 5 (maximum) to the left of target at normal distance,
// if your target is 14 tiles away your actual deviation is going to be 10 units to the left of target.


What we learned:
There's something crazy here. If my pistol's range is 10 and has an accuracy of 20 (fairly typical values), then the bullet deviation radius of my shot could be as high as 4 units shooting at a target 7 tiles away. Even if we have a perfect shot lined up from a perfect merc, 4 units left or right will easily miss the head and quite possibly the torso (since it's a radius). This problem isn't going to be as severe for guns with super high accuracy (80-100).

The short term fix for this issue is to reduce the max bullet deviation range to a value like 1 or 2.

Ideas
The long way to address this problem, I propose, would remove "normal shooting distance" from the calculations entirely, since that deals with "aiming", which is not something that should factor into a gun's performance. If one looks at the setting value and its meaning in context: "maximum bullet deviation of 5 units at the maximum distance where iron sights are 100% effective given a gun with accuracy bonus of 0", one quickly realizes that it makes little sense. What does bullet deviation have to do with the effectiveness of iron sights?

The max deviation value should be defined as something like "max bullet deviation at the gun's max effective range if the gun's accuracy is 0". That way if a gun's max effective range is 30 tiles with 0 accuracy, then the maximum distance that the bullet could stray from where the gun is aiming at its maximum effective range of 30 tiles is 5 units, and at a range of 15, the max deviation would be 2.5 units. If that same gun is shooting at 45 tiles away, the max deviation would be 7.5 units. We could further penalize the gun's accuracy if shooting above max effective range in a non-linear fashion, so that at 45 tiles away we could increase the deviation in a squared manner.

Other considerations:
1) Maybe the gun's condition, when below a certain threshold, could increase its bullet deviation

2) The values of RPGs and LAWs might need to be tweaked if they're affected by this formula (which they might not be)

Thoughts?

[Updated on: Thu, 23 February 2012 01:56] by Moderator

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300189] Fri, 24 February 2012 14:44 Go to previous messageGo to next message
JohnnySideburns

 
Messages:19
Registered:September 2007
there is an easier way to fix it. The accuracy values are flat if im not mistaking, so the skill of the merc is only able to push you towards the max accuracy of a given gun, making some guns almost impossible to hit with(despite the skill of the merc). In NCTH The accuracy fluctuates by around 90, the difference in accuracy in octh was at most 14. I know its not the same thing but what I am trying to say is lowering the fluctuation in accuracy will make guns effective in their respective effective ranges.

Report message to a moderator

Private
Re: NCTH Ideas[message #300197] Fri, 24 February 2012 17:17 Go to previous messageGo to next message
Ryft is currently offline Ryft

 
Messages:278
Registered:June 2009
What if you bridged the two ideas?

Rather than eliminate normal shooting distance, why not make it a variable? Something based on the shooter's marksmanship and/or other stats?

At some level, this also addresses problems with the complaints I've read of "my 90 marksmanship merc with a sniper rifle missed X out of ten shots from Y distance blah blah blah".

Rather than factor shooter skill onto the back end of the CTH calculations, after range, weapon accuracy, and other factors have been determined, make it a primary factor and put it on the front end. This would also have the side effect of highly promoting merc skills over equipment... not sure how people would feel about that.

It would also set up your best marksmanship mercs to be the ones most qualified to handle sniper rifles and the like... basically giving a farther normal shooting distance to a higher marksmanship merc emphasizes differences in training. A merc like Vince, who has an abysmal 35 or similar, is used to a normal shooting distance like what you might encounter with a typical self defense scenario, in other words point blank range, and with pistols (actually, at a range where a charge with a melee weapon is probably as effective). Someone like "Scope" Sterling, with a 99 marksmanship, is used to practicing out on a large field, and is accustomed to factoring in weapons sited in for a particular range, and then accounting for bullet drop and the like. "Normal" for her is something else, entirely!

I might also suggest, to give people the most "bang for their buck" with NCTH's tweakability, we should make a few example settings for people new to the system to try out. Perhaps there's a default setting, which seeks to somewhat replicate OCTH as suggested, and then there's a more "new school" setting to showcase NCTH properly, and then there's whatever Headrock plays on. Wink

Report message to a moderator

Master Sergeant
Re: NCTH Ideas[message #300201] Fri, 24 February 2012 17:59 Go to previous messageGo to next message
Ryft is currently offline Ryft

 
Messages:278
Registered:June 2009
Additional ramblings, more to myself than anything:

What sort of range would the scaled normal shooting distance have? I would think a quality marksman could make use of iron sites out to a solid rifle distance. Maybe 100 yards, before the difference an optic makes starts to become excessively apparent? Obviously we're talking combat iron sites... not accuracy peep sites for competition shooting, and the like. No... 100 yards seems to far. I would think it would have to be less than that... maybe 50? I dunno. You can tell I don't have a ton of firearms experience outside of some casual backyard shooting with a limited variety of guns.

I would think we would need to keep normal shooting distance, at any rate, because it's what makes an optic important in the NCTH math. If you remove normal shooting distance, you need to rethink how scope magnification makes an impact on your CTH.

I'm totally going to be thinking about this all day while I'm at work, now... *sigh*

Report message to a moderator

Master Sergeant
Re: NCTH Ideas[message #300221] Fri, 24 February 2012 20:28 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
@Moustache
This is the Bullet Deviation function, which means the bullet will still stray even if the shooter has perfect aim. The "accuracy cap" in terms of aiming happens in a separate function that I haven't looked much into yet.

@Ryft
- "Normal shooting distance" is actually just an accuracy scaling factor in all of these equations. What it essential calculates to is the worst case unaimed shot's possible radius. Think of it as a base value upon bonuses can be applied. All this "normal distance" crap, when applied to aiming, essentially boils down to "base aiming circle at distance x". Your idea is actually already being applied, just not the way you think. If we reduce the possible aiming radius by applying marksmanship bonus and aiming bonuses, we're essentially "scaling" on top of "normal distance". In that sense, I don't think making "normal shooting distance" variable is a good idea. If anything, it would apply the same bonuses twice.

- Agreed with the "presets" for NCTH. I think one of my main goals for breaking down the NCTH code is so I can get an idea of how much what stats and accuracy values actually factor into the merc's ability to hit. The maths behind all of this is so convoluted that none of the values make any common sense any more.

I don't think it makes much sense to talk about ranges in real world values since this is still just a game. If we allow the TAC 50 to engage enemies at a mile away, it wouldn't even translate into the game. Rather, we should think in terms of tiles and map size.

e.g.
- pistols and SMGs are effective at short game ranges - 10-20 tiles
- carbines are effective at medium ranges 15-25 tiles
- ARs are effective at medium-long ranges 20-40 tiles
etc. etc.

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300279] Sat, 25 February 2012 08:06 Go to previous messageGo to next message
Ryft is currently offline Ryft

 
Messages:278
Registered:June 2009
Apply the same bonuses twice? In my suggestion, I'd think you would remove all other impact that a merc's stats have on the base CTH calculations if they were used to inform the CTH system something as central to the process as the normal shooting distance.

Alright, so what if you modify normal shooting distance based on the accuracy of a given weapon type's iron sites? For instance, in addition to barrel length altering a weapon's accuracy, barrel length also has an impact on how precise one can align iron sites. Anyone who has ever compared the iron sites on, say... a GLOCK versus a FAMAS understands what I mean. A pistol allows a greater angle of play before the sites look noticeably unaligned than what is apparent to a longer weapon.

Perhaps pistol class weapons have a certain normal shooting distance, modified for using the match sites attachment. SMG class weapons have a slightly farther normal shooting range. Longarms in general would have an even farther normal shooting range, with the exception possibly of some shotguns that have simplistic iron sites, such as varieties that lack a rear site entirely.... those might have a normal shooting range more akin to SMGs, perhaps. Weapons without iron sites (picatinny rails only, some sniper rifles) would probably have a lesser normal aiming distance than many "less accurate guns").

Agreed that more abstract ranges for weapon categories make sense. At least unless scale is somehow wildly fixed somehow so that it correlates properly with the graphics on your screen (don't think that's going to happen anytime soon).

Report message to a moderator

Master Sergeant
Re: NCTH Ideas[message #300325] Sat, 25 February 2012 19:00 Go to previous messageGo to next message
JohnnySideburns

 
Messages:19
Registered:September 2007
I realize it is bullet deviation, that does not negate my argument that the difference is too extreme.

Report message to a moderator

Private
Re: NCTH Ideas[message #300334] Sat, 25 February 2012 21:52 Go to previous messageGo to next message
Ryft is currently offline Ryft

 
Messages:278
Registered:June 2009
I honestly think I'm still fuzzy on how weapon accuracy effects CTH in the new system.

[Updated on: Sat, 25 February 2012 21:54] by Moderator

Report message to a moderator

Master Sergeant
Re: NCTH Ideas[message #300434] Mon, 27 February 2012 20:01 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
@Ryft:

I haven't fully examined all the other formulas yet, but the bullet deviation function SHOULD be the only place where weapon accuracy will affect your CTH (e.g. up to 5 units left/right at normal shooting distance)

I've been examining the AdjustTargetCenterPoint function (which is responsible for all aiming/muzzle sway/bullet deviation calculations), and I'm stumped on the following line

*dEndZ = __max(-127, *dEndZ + (dShotOffsetY * 11.3f)); // Y, which represented up/down offset, is actually the Z axis in 3d game terms...


Where dShotOffsetY is how much your bullet is straying up or down from poor aim or gun ballistics, and there's a 11.3f multiplier there before this value is applied to the game's Z coordinate system. I can't find this magic value anywhere else and it's driving me nuts. So now I'm digging into the hit detection / hitbox system just to verify that this isn't some sort of voodoo bogus math.

EDIT: upon further investigation it seems that this number is fairly voodoo, but if my calculations are correct, the CORRECT value here should be 11.45f. In deriving this value, there seems to be some bogus math happening in terms of calculating height distances currently in the LOS.h code. I'll cover that in a separate post I think.

I've also done a quick 1000 shot test to check the bullet distribution function, and here's one of the results:

https://docs.google.com/spreadsheet/oimg?key=0AumAgvmJNg2xdFpEaWVveUtOZm9QQW5KVHBGVlZkUmc&oid=1&zx=gmex82xpjtuh

It's interesting to note that bulets don't tend to stray where X value is high and Y value is close to 0 (i.e. to the extreme left or right), so there's probably some data loss when calculating potential arc points.

[Updated on: Tue, 28 February 2012 19:25] by Moderator

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300614] Wed, 29 February 2012 20:29 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
Just to expand on the 11.3f -> 11.45f magic value a little bit:

http://ja2v113.pbworks.com/w/page/28015925/Anatomy%20of%20a%20sprite

Each game "cell" is made up of tiles like mentioned above. Each cell, on the ground plane, is made up of 10 distance units on each side. Each 10 distance units then make up 1 tile unit. (i.e. a target 7 tiles away is 70 distance units away)

CELL_X = 10 distance units
CELL_Y = 10 distance units

Since each side of the tile on the x,y plane is made up of sqrt(10^2 + 20^2) = 22.361 pixels, then we have what approximates to 2.236 pixels per "distance unit" on the x,y plane.

Since each cell is 50 pixels high, we can conclude that each cell is
50 / 2.236 = 22.36 distance units high.

CELL_Z = 22.36 distance units

The complication arises when the Z units, or, what the game refers to as "Height Units" are on a completely different scale from distance units. In the game, each cell is 256 "Height Units" tall, and all calculations on the Z axis are done against this unit system. e.g. A person is head is about 191 height units, etc. etc.

Since the targetting system adjusts your shot's landing point on a 2D plane that's perpendicular to your original shot, the calculations are done using "distance units". This means when we convert the Y adjustments from the 2D plane back to the 3D world, it needs to be converted from distance units to height units.

We can convert distance units to height units as follows:

HeightUnits = DistanceUnits * ( CellMaxHeightUnits / CellMaxDistanceUnits )
HeightUnits = DistanceUnits * ( 256 / 22.36 )
HeightUnits = DistanceUnits * 11.45

And applying that to the original muzzle adjustment:

FinalZ = OriginalZ + ConvertDistanceUnitsToHeightUnits( 2DAdjustedY )
FinalZ = OriginalZ + 2DAdjustedY * 11.45f

There's some interesting implications of the weird scale that Z values take. One of the biggest ones is a bug in the code when calculating shot distances. Ever notice that when you're on the roof, you have trouble shooting properly against people who are right next to you but on the ground level? The NCTH cursor indicates a tiny circle, but your shot misses wildly. How is this happening?

When each shot is adjusted for muzzle sway, the radius of your sway (shot aperture radius) is calculated for the normal shooting distance and then scaled to the actual distance of the shot.

Let's say at the normal shooting distance of 7 tiles (70 distance units), the radius is 5. If your target is 14 tiles away from you, the radius is scaled by the ratio of TARGET DISTANCE to NORMAL DISTANCE: 5 * (140 / 70) = 5 * 2 = 10 units.

So whenever you take aim and fire a shot, the distance from you to the target is calculated:

Distance3D = sqrt( distanceX^2 + distanceY^2 + distanceZ^2 )

The formula is the pythagorean theorem in 3D, but the bug actually arises in the usage of value "distanceZ". The distanceZ in these formulas are in HEIGHT UNITS and not DISTANCE UNITS. So when you shoot from the roof to the ground below you, you have something like:

distanceX = 10
distanceY = 0
distanceZ = 256 HEIGHT UNITS (shooting from your eye level to target eye level one cell below you)

Distance3D using the above formula yields 256.2 units or 25.62 tiles! But actually the target is only about 2 tiles away from you! So for shots like these, your aim is severely penalized and your shot might go wildly off target when it shouldn't at all.

So why does the NCTH indicator still only show a tiny crosshair if there's a massive calculation error? Well, in the NCTH indicator code, it only attempts to estimate the range of your shot by doing this:

RangeEstimate = sqrt( distanceX^2 + distanceY^2 )

So the height component is completely ignored in this calculation... and so the indicator is lying to you quite a bit Smile

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300643] Thu, 01 March 2012 02:33 Go to previous messageGo to next message
Foxd1e is currently offline Foxd1e

 
Messages:32
Registered:February 2012
Location: US
This is an interesting discussion. I think the end result illuminatus comes to "Sniper rifles will own the map" is inevitable unless you don't include sniper rifles. Which will send many people up in arms. So you essentially have a million solutions to that conclusion that could make the game more enjoyable here are my 4.

Solution 1: Tweak the AI to stay in cover and prone position more often. Suppresion does this but when a Sniper is shooting at someone they are dead before they hear the shot.

Solution 2: Institute an accuracy penalty at extreme ranges (ingame) for snipers. Like if a Sniper is shooting from well over half a map away, institute a 10% to hit penalty. Especially to the head or even 15% for the head.

Solution 3: Provide more cover on late game maps. When most players will have high-powered rifles with high-powered scopes.

Solution 4: Give enemies Camo gear. Unless they have it already and I somehow missed that. I don't play with the enemy tooltip on 4 or 3 for that matter so I may well have missed this.

All 4 togther might be the best way to go about it.

@illuminatus I actually notice that all the time in OCTH as well. I think the code penalizes any rooftop snipers who don't have the On-Roof Shooting Trait which was removed in S.T.O.M.P. I think when they removed the trait they forgot to take the negative modifier out of the code. So in plain english, it shouldn't be there Wink

My Granmamas and My Grandaddys always told me Boy you gotta take the High Ground. He who takes the high ground first, wins. But in JA2 he who takes the low ground, has the last laugh! Infact when an enemy is rooftop sniping, I lol and then I run up point blank to the wall he takes 5 shots and misses I aim my spaz 12 Clarence Bodickker style "Nuh Nuh Nuh Nuh Nuh Nuh BOOM" and blow his head clean off 1 shot.

[Updated on: Thu, 01 March 2012 02:45] by Moderator

Report message to a moderator

Private 1st Class
Re: NCTH Ideas[message #300645] Thu, 01 March 2012 03:10 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
Regarding points 1), 3) and 4), I think the vanilla JA2 maps are varied enough that in a lot of missions you won't be able to exploit the full range of sniper rifles, so I'm not sure if there's a need to reduce your ability to see them. However, it would be nice if the AI knew to take cover or stay in-doors if they hear sniper rifle fire in the battlefield. (more reasons to have silencers?)

Regarding 2) There's already a penalty in NCTH when you fire beyond the range of sniper rifles. So maybe this will come down to a data update on the existing rifle ranges. The other suggestion i had is to reduce more sharply the bullet damage values as a shot reaches the extremes of the weapon's effective range.

Another way to reduce their effectiveness is increase AP cost of aiming and firing them even more

Also, increase the "muzzle lag" against moving targets for targets that are farther away. I know muzzle trailing is currently implemented already, where if a target is moving perpendicular to your shot, your shot will be slightly behind your target (pending the shooter's skill). But I'm not sure if this "lag" amount increases as the target is farther from the shooter with the Sniper Rifle.

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300657] Thu, 01 March 2012 08:23 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
Quote:
I think when they removed the trait they forgot to take the negative modifier out of the code


#define STANDING_FIRING_POS 175.0f
#define STANDING_HEAD_TARGET_POS 175.0f
#define STANDING_TORSO_TARGET_POS 127.0f
#define STANDING_LEGS_TARGET_POS 47.0f


I wish it were true but I believe this case it is actually a full-on bug. Let's say I'm standing one tile away from my target (10 distance units), but I'm shooting at this guy's feet. So my height is at 175.0 height units and his legs are aimed at 47.0 height units, which results in a delta of 128 units of height difference.

Using the bugged formula we would get:

sqrt(10^2 + 0 + 128^2) = 128.39 units, which translates to almost 13 tiles.

ACTUAL distance is: sqrt(10^2 + 11.45^2) = 15 units which is about 1.5 tiles.

Under the erroneous formula, my shooting aperture size would be multiplied by about a factor of 2 (making me significantly less accurate compared to NORMAL DISTANCE), where as under the correct formula, my aperture size would be reduced by about 80%, making my shot significantly more accurate compared to NORMAL DISTANCE. The 2nd method is obviously correct and the original method is clearly wrong.

It unfortunately has nothing to do with being on the roof. Being on the roof just exacerbates the problem.

[Updated on: Thu, 01 March 2012 08:23] by Moderator

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300686] Thu, 01 March 2012 16:42 Go to previous messageGo to next message
fnulp is currently offline fnulp

Messages:2
Registered:February 2012
Excuse me if this is redundant or moot, since I'm not familiar with the code, but: why even do something "like calculate deviation based on distance"? Why not simply have a random deviation (based on skill and all the other influencing factors) which is an angle (instead of tiles etc.)? Then it naturally follows that a max deviation of e.g. 5

Report message to a moderator

Civilian
Re: NCTH Ideas[message #300699] Thu, 01 March 2012 19:24 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
fnulp:

That's likely what I would have done -- work with an angular value right from the start. But NCTH is conceived and developed with these scaling factors in mind along with "normal distance", and the end result is akin to working with an angle. I'm spending my time trying to understand it, but unfortunately I'm not sure why this method was chosen initially. I imagine there was a decent reason Smile

Report message to a moderator

Corporal
Re: NCTH Ideas[message #300732] Fri, 02 March 2012 05:28 Go to previous messageGo to next message
Foxd1e is currently offline Foxd1e

 
Messages:32
Registered:February 2012
Location: US
@illuminatus Good points through-and-through. I still really like the idea of Enemy camo.

But regarding our current problematic aiming formulas OCTH & NCTH. Maybe you could just try your hand at your own chance to hit mod? Build it from the ground up to make sense, with as few lines of code as possible. I'm sure after years and years of play on both formats everyone is willing to try something new that is based on a code that isn't complicated, and has formula consisting of logical values and results.

[Updated on: Fri, 02 March 2012 05:30] by Moderator

Report message to a moderator

Private 1st Class
Re: NCTH Ideas[message #300833] Sat, 03 March 2012 06:56 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
So after poking at the codebase for a couple more hours and looking at all the variables involved in the CalculateNewChanceToHitGun function, I've decided that it'd be almost impossible to get an idea of what variables could affect what in what degree.

As I was typing a summary of what was going on in the function, my head exploded about half way down, before the "aiming" bonuses were even considered (I got through the "unaimed shot" portion of the code). I've decided to port snipplets of the code to C# and tweak/visualize things from there. The act of PORTING the code will most likely increase my understanding as well (on top of being able to escape this labyrinthine codebase).

I'll post what I found out below, in completely unorganized briandump mode:

CalcNewChanceToHitGun

Get the 2D distance between firer and target

Find the target in the cell being aimed at

Determine how easy it is to handle the weapon in hand, taking into account the attachments which
improve weapon handling. This is stored as GunBaseDifficulty and GunAimDifficulty

Force the weapon to be ready in terms of code and get the solder's maximum visible
distance with the weapon in hand. sDistVis

Do LOS test against the target to see if it's possible to reach the target, and determine
the distance "sightRange"

Force the weapon to be un-ready so the next set of values can be determined without bonus
from the weapon's attachments

DistVisNoScope = Get MaxDistance Visible for the solder without scope from guns

Remove the force weapon un-ready flag

ScopeRangeMod = DistVis / DistVisNoScope

ScopeRangeMod is the percent factor the viewing distance has been enhanced due to scopes
on the weeapon.

SightRange = SightRange / ScopeRangeMod

Divide the sight range by the sight range modifier, this is now effective range to target
Apply SNIPER trait bonuses to reduce effective range to target.

If at this point the target is still invisible, the effective range to target is set
to the higher of 1.5x scoped visibility distance or 2x the range to actual target. The target
is also flagged as not visible at this point

Calculate Base CTH, this is the CTH if the shooter just brings a weapon into the
general direction of the target and pulling the trigger. The most important skill
here is experience.

Get the effective Experience level, marksmanship, dexterity, and wisdom of the shooter
Return the minimum possible CTH if the marksmanship or dexterity is 0

; These settings determine the importance of each character skill in calculating
; your Base CTH. By default, Experience is 3 times more important than the other
; skills. Base CTH, before modifiers, is equal to the sum of the player's skills,
; each multiplied by the appropriate value from these, and then divided by the
; sum of all these four values.

example: lvl 5 experience at the default factors would result in effective combined
skill of "75"

This value is scaled between 0 and 33, which means the perfect merc can reduce the shooting
aperture by 33 percent just by virtue of raising the gun and firing from the default
maximum without really aiming

At this time, scan all attachments on the player's weapon and apply any flat CTH bonuses
from items.

Now the code starts reviewing possible modifiers. Modifiers aren't applied directly to CTH,
but is rather scaled by a factor near the end. So the numbers here shift drastically in meaning and
effectiveness compared to modifying the BaseChance directly.

First it starts with morale

Morale modifier ranges from +5 when you have 100 morale, to -20 when you have 0 morale.
At 40 morale, you take a -4 penalty, which is non-trivial. Adjust BASE_LOW_MORALE and BASE_HIGH_MORALE
CTH constants to reduce the effect of morale.

baseModifier = moraleModifier

If you're using the new trait system, trait modifiers are applied. Based on whether your
merc is trained in these traits, they get a flat penalty for using some of these weapons
which could be a -5, -10 or more. These penalties are not trivial either.


TraitModifier is calculated by adjusting training traits

Now Character Traits are calculated for a +5 or +2 bonus if the appropriate conditions apply

Heat intolerant mercs get a flat -15 penalty when hot, and fear of insects incur a -5 penalty
in tropical conditions.

The trait modifiers are now multiplied by 0.4 just to reduce their overall effect on CTH.
If you note that you could only get up to 33 points of bonus even if you're
the perfect merc, these flat penalties can quickly add up if you don't have the right traits.
On the other hand, if you do have the right traits, you're quite significantly more powerful.
The multiplier is there to make these traits less impactful to the unaimed shot (later on the other
0.6 of the STOMP trait modifier is applied to aiming)

BaseModifier = BaseModifier + TraitModifier * 0.4

If not using the new traits system, being psycho gives you a -3 (BASE_PSYCHO) penalty on the base modifier

BaseModifier = BaseModiier + BASE_PSYCHO (-3)

If you're shooting the same target as before, you get a bonus to base modifier as well:

BaseModifier = BaseModifier + BASE_SAME_TARGET (5)

If the solder is using a one-handed weapon and he's firing two pistols, apply the gun's base diffulcty
multiplied by BASE_TWO_GUNS minus GunBaseDifficulty. The penalty is halved for every level of ambidexterous
trait the shooter has. The final penalty is added on top of the Gun's Base handling diffculty:

GunBaseDifficulty = GunBaseDifficulty + PenaltyShootingTwoPistols

Otherwise if the shooter is shooting a pistol with only 1 free hand, then the gun's base difficulty is multiplied
by BASE_ONE_HANDED penalty value

GunBaseDifficulty = GunBaseDifficulty * BASE_ONE_HANDED (2.5)

If the weapon in hand is a rocket launcher and we're not using the new traits system, apply more
heavy weapons penalty to the GunBaseDifficulty here (the penalty is already applied earlier in the TraitPenalty
calculations if using the new traits system.)

If the shooter is crouching or prone, the appropriate difficulty multipliers are applied to the base
gun's handling difficulty:

GunBaseDifficulty = GunBaseDifficulty * BASE_CROUCHING_STANCE (3)
OR
GunBaseDifficulty = GunBaseDifficulty * BASE_PRONE_STANCE (4)

The Gun's base difficulty is further added to by any handling modifier multipliers as part of the gun's attachments:

GunBaseDifficulty = GunBaseDifficulty + (GunBaseDifficulty * GetPercentHandlingModifier() / 100)

(Why is this happening? this is such a high number)

Now the Gun's Difficulty is applied to the BaseModifier:

BaseModifier = BaseModifier - GunBaseDifficulty * BASE_DRAW_COST (2)

At this point if you have a difficult to handle weapon, your BaseModifier is like -100. Ouch.

If your merc is hurt, up to -30 penalty will be applied based on whether your merc is bleeding or wounded

BaseModifier = BaseModifier + BASE_INJURY (-30) * PercentLifeLost
BaseModifier = BaseModifier - BASE_INJURY (-30) * PercentLifeBandaged / 3

If your merc is fatigued (or simply out of breath), he will take a penalty:

BaseModifier = BaseModifier + gGameCTHConstants.BASE_FATIGUE * BreathDrainedFromMax / 100;

Ed* This is bullshit. penalties should not kick in until after a threshold

Apply penalties for being drunk:

BaseModifier = BaseModifier + BASE_DRUNK[drunknessLevel] (-5, -20, -50, 10)

Apply penalties for being gassed, bandaged:

BaseModifier = BaseModifier + BASE_GASSED (-15)
BaseModifier = BaseModifier + BASE_BEING_BANDAGED (-5)

If soldier is in shock, apply the shock percentage up to BASE_SHOCK amount of penalty (-150)

Now calculate bonuses and penalties based on the target's agility or experience:

First choose the more relevant stat, the greater of either experience level or agility. Use that
as a percentage to multiply against the base penalty of an agile target (-5), giving maximum penalty
if the agility is 100 or experience is 10:

BaseModifier = BaseModifier + BASE_AGILE_TARGET * (agi or exp level / 100)

If you're shooting upwards, you get up to a BASE_SHOOTING_UPWARDS penalty (-15) if you're one square
away from the enemy. The effect of this is reduced by range: -15 / range

	if (iRange > 0 && iHeightDifference > 0)
	{
		FLOAT iTempPenalty = gGameCTHConstants.BASE_SHOOTING_UPWARDS * iHeightDifference;
		iTempPenalty /= iRange;

		iBaseModifier += iTempPenalty;
	}


If you can't see target, you get a flat penalty of -100 (BASE_TARGET_INVISIBLE)

BaseModifier = BaseModifier - BASE_TARGET_INVISIBLE

At this point, the flat bonuses you get from your gear is applied:

	iBaseModifier += GetGearAimBonus ( pSoldier, iSightRange, ubAimTime );


The the flat bonus from your weapons and attachments:

	iBaseModifier += GetPercentBaseModifier( pInHand, gAnimControl[ pSoldier->usAnimState ].ubEndHeight );


If the soldier is AI controlled, he gets a penalty here based on the game's difficulty setting.

Now we're done with applying all the flat bonuses. BaseHitChance is adjusted by BaseModifier as
a percentage. e.g if your BaseModifier is -100, then your BaseHitChance is back to 0. However if
your base modifier is 10, then you get 10% more BaseHitChance on top of your original:

	iChance = (INT32)(iChance * (100+iBaseModifier)) / 100;


This is one of the craziest things I've seen as it throws all scaling sense out of order.
The resulting value is capped between 0 and 100.







Report message to a moderator

Corporal
Re: NCTH Ideas[message #301197] Wed, 07 March 2012 02:11 Go to previous messageGo to next message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
So the latest update on this endeavor is that I've ported maybe 75% of the muzzle sway/aiming code to C# (just so I'm forced to rewrite it), including all the "craziness". I'll be running a couple of comparison tests to make sure my functions are implemented the same way as the original code (as close as possible).

Next step is to hook up some sort of UI so I can adjust parameters and see how they affect muzzle sway on the fly.

The bad news is that Mass Effect 3 is out and I'm on crunch at work Wink

Report message to a moderator

Corporal
Re: NCTH Ideas[message #303255] Wed, 11 April 2012 15:00 Go to previous messageGo to next message
Scouty is currently offline Scouty

 
Messages:76
Registered:April 2008
Hey illuminatus, did you make sense of the weird use of distance/height units and arbitrary 2D/3D distance formulas?

From LOS.cpp, FireBulletGivenTargetNCTH, rev 5181, line 4149:
	dDeltaX = dEndX - dStartX;
	dDeltaY = dEndY - dStartY;
	dDeltaZ = dEndZ - dStartZ;

	//lal bugfix
	if( dDeltaZ > 0 )
		d2DDistance = Distance3D( dDeltaX, dDeltaY, dDeltaZ );
	else
		d2DDistance = Distance2D( dDeltaX, dDeltaY );

Firstly:

dDeltaZ is actually in Height units, not Distance units, hence why in other parts of the code it's called as:

dDistance = Distance3D( dDeltaX, dDeltaY, CONVERT_HEIGHTUNITS_TO_DISTANCE( dDeltaZ ));

Secondly:

dDeltaZ can be negative when shooting DOWN, and then it just ignores the Z coordinate altogether?

I'm assuming lal tried to optimize the formula, by seeing whether abs(deltaZ) > 0, and only using the 3D function in that case. But that difference is not actually an absolute value.

===

Also from LOS.cpp, FireBulletGivenTargetNCTH, rev 5181, line 4169:
	ddOrigHorizAngle = atan2( dDeltaY, dDeltaX );
	ddOrigVerticAngle = atan2( dDeltaZ, (d2DDistance * 2.56f) );


This is probably best explained with a figure:

http://upload.wikimedia.org/wikipedia/commons/thumb/4/4f/TrigonometryTriangle.svg/400px-TrigonometryTriangle.svg.png

d2DDistance is EITHER the Adjacent (Distance2D) or the Hypotenuse (Distance3D) part of the triangle.

But tan = opposite / adjacent, sin = opposite / hypotenuse. So this atan2 is not correct in all cases.

Plus, where does the 2.56 magic factor come from? The distance/height unit factor?

#define CONVERT_HEIGHTUNITS_TO_DISTANCE( n ) ((n) / (HEIGHT_UNITS / CELL_X_SIZE) )
#define HEIGHT_UNITS 256
#define CELL_X_SIZE 10

So this means, 1 Distance unit = 25.6 Height units. So he chose to multiply d2DDistance by 2.56f (which should be 25.6f) instead of divide dDeltaZ by 25.6f. Fair enough, maybe a little confusing to work with Height units when talking about distance, but ok. Regardless, this is still off by a factor of 10!

===

P.S. And one of the few good things that came out of Mass Effect 3 is the soundtrack, playing that during JA2 atm. Very Happy

[Updated on: Wed, 11 April 2012 15:53] by Moderator

Report message to a moderator

Corporal
Re: NCTH Ideas[message #303491] Mon, 16 April 2012 05:48 Go to previous messageGo to next message
Goncyn is currently offline Goncyn

 
Messages:48
Registered:July 2010
I don't mean to downplay the hard work of the people who came up with NCTH, but having looked at the code before and reviewed illuminatus's summary a bit, too, I think the code is much, much too complicated. From actually play-testing r5207, I'm not convinced it's not totally bugged, either. I aim, I shoot, and the bullets seem to fly wildly outside the relatively small aperture I saw on my cursor.

I think the whole thing could benefit greatly from being thrown out and re-written with Headrock's original intent as a guide but a new, simpler implementation.

Report message to a moderator

Corporal
Re: NCTH Ideas[message #303506] Mon, 16 April 2012 17:49 Go to previous messageGo to next message
Randok is currently offline Randok

 
Messages:332
Registered:March 2004
JA2+1.13 v5207
I like when the game is hard but what is done in a NCTH it is misunderstanding.
I've played over 10 sectors and is a tragical. Only miss, miss, miss, miss...
To hit the target I have to repeat ( more than 10 times ) Alt+L.
And no matter high accuracy, health, energy, weapons, attachments, distance, etc.
The result still the same: miss, miss, miss ...
Burst it is joke. Mercenary shoot sideways. I was waiting when he starts to shoot back Smile.
The game ( with NCTH ) is not playable.
Maybe it was enough to change the numerical values of the other back to the game was playable.

[Updated on: Mon, 16 April 2012 17:51] by Moderator

Report message to a moderator

Master Sergeant
Re: NCTH Ideas[message #303615] Thu, 19 April 2012 08:39 Go to previous message
illuminatus is currently offline illuminatus

 
Messages:61
Registered:April 2009
Location: CA, USA
After revisiting the code in 5207, I'm beginning to doubt if my initial judgement of Z-distance calculation was incorrect. I had thought there was wild discrepancy on distance calculations when shooting at targets that are close to you but are one or more levels above you. I was so convinced of this that I recall being able to reproduce those misses reliably and had the debug data to back my theory up.

However, trying the NCTH in 5207 this problem doesn't seem to flare up (or is much less pronounced). Looking at the changes to LOS.cpp I could not determine how the problem "got better", so I decided to go back to 4870 where I thought this problem was very much alive. Much to my chagrin, I can't seem to reproduce that in the old version of 1.13 either.

So I guess I'm either out of my mind or the problem is still there and I just can't re-discover it.

I'm fairly sure that the CONVERT_HEIGHT_UNITS_TO_DISTANCE macro is still incorrect in the new code, however.

As far as the FireBulletGivenTargetNCTH is concerned, I'm beginning to think that the height distance conversion is unnecessary because the function is internally consistent with its own units and thus do not require conversions.

If anyone wants to put in some debug time to see if Z-distances are factored properly when firing shots, that would be greatly appreciated.

Report message to a moderator

Corporal
Previous Topic: Spanish translation
Next Topic: C#-XNA port anyone?
Goto Forum:
  


Current Time: Fri Jun 12 09:47:13 GMT+3 2026

Total time taken to generate the page: 0.01507 seconds