Home » MODDING HQ 1.13 » v1.13 General Development Talk » NCTH Ideas
| NCTH Ideas[message #298351]
|
Fri, 10 February 2012 02:34
|
|
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 #299990]
|
Wed, 22 February 2012 22:54 
|
|
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 
|
|
| 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 
|
|
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.
Report message to a moderator
|
Master Sergeant
|
|
|
|
|
|
| Re: NCTH Ideas[message #300221]
|
Fri, 24 February 2012 20:28 
|
|
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 
|
|
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 #300334]
|
Sat, 25 February 2012 21:52 
|
|
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 
|
|
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:

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 
|
|
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 
Report message to a moderator
|
Corporal
|
|
|
|
|
|
|
|
| Re: NCTH Ideas[message #300657]
|
Thu, 01 March 2012 08:23 
|
|
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 #300833]
|
Sat, 03 March 2012 06:56 
|
|
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 #303255]
|
Wed, 11 April 2012 15:00 
|
|
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:

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.
[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 
|
|
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 
|
|
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 .
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
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Jun 12 09:47:13 GMT+3 2026
Total time taken to generate the page: 0.01507 seconds
|