Home » MODDING HQ 1.13 » v1.13 Idea Incubation Lab » HAM 4.0 Alpha Testing Thread
| Re: HAM 4.0 Alpha Testing Thread[message #271766]
|
Sat, 29 January 2011 16:26  
|
|
 Kafouille |
 |
Messages:9
Registered:May 2006 |
|
|
Really, the "Handling" characteristic should be a tag in the XML, not derived from draw costs. The current way is really inflexible, and gets some pretty damn weird results. Hardcoding those kinds of relationships will make it really hard for modders down the line. It also needs to be shown in the item description.
For example, the pistols currently have unrealistically low accuracy values, to limit their effective range to a more or less realistic result. But the pistols realistically should have something like twice the current accuracy, and have pretty bad handling values. A handgun can be quite accurate, but it's difficult to get a really precise aim with it, due to a short distance between the sights and the fact that you're only holding it at one point, with no stock. That would also help provide with better variety among weapons, to avoid the "15 pistols, 1 set of stats" syndrome.
Current implementation of folding stocks also suffers from this, as you get a crippling +1 aiming step from it but better handling, when it really should be a handling penalty. (Really the current way the game handles folding stocks makes no sense, it assumes you fight with it folded "sometimes" when half the weapons with it would be pretty useless without extending it. It really should provide a minor handling penalty but reduce the size of the weapon for storage purposes if replacing a full stock, but be a major handling boost if you're adding a stock to a weapon without one. AIM has the right idea IMHO with the different stocks as default attachments)
Report message to a moderator
|
Private
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271772]
|
Sat, 29 January 2011 18:56
|
|
| ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
@AndroidXP: I don't know which part of the obstacle accounts for the head. And in NCTH you don't actually shot at the head. You just raise the muzzle's Z offset (aim higher). But yes, there is the potential that side shots to the head may become easier. It needs to be tested.
@Alex_SPB: You completely lost me. Aim_draw_cost is nothing more then a multiplier that converts the weapon handling value into a penalty. Yes, you could use it to completely turn off weapon handling (aim_draw_cost = 0). You can also make the overall penalty higher or lower by adjusting that value. But I don't see how having a second handling value would make any difference. You're still multiplying against ubReadyCost.
@Kafouille: First, I've already said that perhaps ubReadyCost isn't the best option to use but it's what we have. I suppose a new tag could be used, but what criteria would be used to generate the values?
And this has nothing to do with nAccuracy or weapon stability. "Stability", Accuracy and "Handling" are all unrelated to each other. Stability is how easy it is to keep your weapon stable during a shot, which has an effect on your overall cth. Accuracy is how far a bullet can fly, and still accurately hit a target. And Handling is how easy or hard it is to "control" a weapon.
Pistols have a low accuracy value because they have a limited range at which they can accurately hit a target. Most pistols in the game have similar nAccuracy values because most pistols in the game have similar effective range values.
Pistols have high handling because they are easy to control. Small, light weight weapons are easier to control then large, heavy weapons. Stick a folding stock on a rifle and you make the rifle smaller, therefore easier to handle.
At the same time, if you stick a folding stock on a rifle, you make it harder to stabilize which is why it takes longer to aim (that +1 AimLevels penalty). There are also other tags that deal with weapon stability (FlatBase, PercentBase, FlatAim and PercentCap) that should maybe be included on folding stocks to further show the "stability penalty" that these attachments bring. But the handling bonus is not incorrect just because they should have more of a stability penalty.
Don't confuse accuracy, handling and stability for each other.
Report message to a moderator
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271777]
|
Sat, 29 January 2011 19:40
|
|
| Alex_SPB |
 |
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg |
|
|
I will try to explain in a different way:
Current NCTH:
Penalty = gun_handling (based on ub_ready_time)*aim_draw_cost*AIM_xxx_STANCE*AIM_TWO_GUNS*
AIM_ONE_HANDED*AIM_HEAVY_WEAPON
If aim_draw_cost is set to 0 all the penalty is set to 0 and AIM_xxx_STANCE, AIM_TWO_GUNS,
AIM_ONE_HANDED and AIM_HEAVY_WEAPON are disabled.
Proposed changes
Penalty = (gun_handling * aim_draw_cost + X)*AIM_xxx_STANCE*AIM_TWO_GUNS*
AIM_ONE_HANDED*AIM_HEAVY_WEAPON
If aim_draw_cost is set to 0 we still have AIM_xxx_STANCE, AIM_TWO_GUNS,
AIM_ONE_HANDED and AIM_HEAVY_WEAPON working.
If X is set to 0, nothing changes compared to current NCTH. In this case X is a general aiming efficiency modifier.
Actually we are talking about the same thing with Kafouille, the only difference is that he is asking about a separate xml entry for each weapon and I propose an cthconstants.ini entry which will be the same for all weapons in game.
[Updated on: Sat, 29 January 2011 19:46] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271778]
|
Sat, 29 January 2011 20:01
|
|
| Alex_SPB |
|
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg |
|
|
ChrisL
Pistols have high handling because they are easy to control. Small, light weight weapons are easier to control then large, heavy weapons.
This means that they could be aimed fast (fewer aim clicks in NCTH terms). It does not mean that they could be aimed more accurate then an AR or carbine (which is true for current NCTH).
The longer is the line between front and rear sight - the more efficient is weapon aiming. This is why for example all ISPS custom pistols have longer frame - to increase the sight line (space between front and rear sight).
The gun handling concept making aiming with Colt 1911 far more efficient then aiming with M16 seems totally wrong to me.
[Updated on: Sat, 29 January 2011 20:01] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271780]
|
Sat, 29 January 2011 21:34
|
|
| loonyphoenix |
 |
Messages:45
Registered:September 2010 |
|
|
Quote:And this has nothing to do with nAccuracy or weapon stability. "Stability", Accuracy and "Handling" are all unrelated to each other. Stability is how easy it is to keep your weapon stable during a shot, which has an effect on your overall cth. Accuracy is how far a bullet can fly, and still accurately hit a target. And Handling is how easy or hard it is to "control" a weapon.
But what about the ease of aiming? That seems like a very important characteristic; a more important one than either stability or how hard it is to control a weapon, whatever that means. Some weapons are easier to aim than others, that's for sure. I thought that was what handling means.
Anyway, what does handling affect? Is it a multiplier of base aperture? Or maximum aperture? Or final aperture? Does it affect the things the same way Stability affects the aperture? From your description it would seem so, although I might be mistaken. I understand the difference between Stability or Handling and Accuracy. But I don't understand why Stability and Handling are separated into two values. If they are applied the same way, why can't they be merged into a value of, say, Ergonomics? For instance, Stability of a weapon affects all its apertures by increasing them 20%. Handling of the same weapon affects all apertures by increasing them 50%. That will make the final Ergonomics value of said weapon 1.2x1.5=1.8 (or 80 or whatever).
By the way, if you're unsure how to calculate Handling, you could simply use the current values based on draw cost and leave it at that. I'm sure someone will adjust those as we go along. It does seem important that it is a separate value to me. Draw cost is draw cost; handling, whether that means the ease of control or aiming, is handling. Those are definitely separate values in my mind, unlike Handling and Stability, because they affect different kinds of values.
Report message to a moderator
|
Corporal
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271913]
|
Mon, 31 January 2011 20:27
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Alex, adding an "X" cthconstant to represent some arbitrary "generic handling" value for all weapons doesn't make any sense. You're asking that we define existing cth constants two mean two things: Handling OR "efficiency". That's not going to happen. I'm sorry that you want to use the existing handling constants to mean something else in your mod. I really can't think of a way you can do that without causing yourself alot of headaches. The ONLY option I would consider is replacing ubReadyTime with some other tag as the base "weapon handling" value (as Kafouille suggests). But without some idea what to set the value to, the best I could do is duplicate the existing column. But even if I do that, all the handling contstants would still be linked together.
Loony, Handling effects stability, just like a shooters Marksmenship attribute effects stability. Stability affect aperture size. A weapon with handling of 50 doesn't increase the aperture size by 50%. It simply effects stability (or "muzzle sway" or "cth") which is what effects aperture size. "Stability" is just one of many variables that go into the "muzzle sway" calculation.
The point of the various "handling" modifiers versus a more direct "stability" modifier, is that handling modifiers are all based on the weapons base handling characteristics. A "10% handling modifier" is going to have a different amount of effect on a shooter's "muzzle sway" if the shooter is using a pistol versus an assault rifle. On the other hand, a "10% stability modifier" will effect "muzzle sway" the same regardless of the weapon the shooter is using. Stick a bipod on a weapon (assuming the shooter is prone) and the modifier that gets applied to "muzzle sway" is going to be based on the weapon insted of a "flat" modification. Therefore a bipod has a "PercentHandling" modifier. On the other hand, an attachment might give the same modification regardless of the weapon it's attached to. In that case, you'd have the attachment use the FlatBase, PercentBase, PercentAim and/or PercentCap tags. It's all a matter of what is actually being modified.
Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271934]
|
Tue, 01 February 2011 02:09
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
@loonyphoenix: Not really. The aperture you see on the cursor is a mixture of "muzzle sway" (or CTH), range, vision enhancement, and accuracy.
CTH (that "chance to hit" entry you see on the 'F' hotkey) is NOT "chance to hit". It's "muzzle sway" in NCTH. Which simply means the percentage of the "distance" aperture size which is used duing the bullet deviation (aka, accuracy) calculation. In other words, if range and vision ehancement result in a "distance" aperture of 100, and you have a "CTH" of 80, then we reduce "distance" apterture by 80%, leaving an initial shooting aperture of 20. But before the aperture is displayed, we further adjust the aperture size by the weapons accuracy value. So a weapon with a 20 accuracy might end up with a 40 aperture size (this is just an example... the math in no way adds up).
So: Weapon's Handling & Merc's specs & Attachments & Aiming (and other variables) => Stability, muzzle sway, cth or whatever else you want to call it but NOT "Aperture size".
Muzzle sway & Distance & Vision Enhancement & Accuacy => Chance-To-Hit (shooting aperture, bullet aperture or whatever you want to call it).
We never actually display an apterture based on "muzzle sway". It's simply used in the calculations, along with accuracy and the rest.
@Kauouille: I'm adding a "ubHandling" value to weapons.xml. I'm just copying the ubReadyTime values into the ubHandling tags so by default the two numbers are the same. I'll leave it to starwalker (and individual modders) to start tweeking. However, I will advise that Headrock designed NCTH on the premise that "quick" guns (those with low ubReadyTime) would have low handling penalties while "slow" guns (sniper rifles, LMGs and the like) would have high handling penalties. If you reverse that assumption, or throw the assumption away, you are likely to end up with some rather odd results.
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #271940]
|
Tue, 01 February 2011 03:09
|
|
| Kafouille |
|
Messages:9
Registered:May 2006 |
|
|
ChrisL However, I will advise that Headrock designed NCTH on the premise that "quick" guns (those with low ubReadyTime) would have low handling penalties while "slow" guns (sniper rifles, LMGs and the like) would have high handling penalties. If you reverse that assumption, or throw the assumption away, you are likely to end up with some rather odd results.
It's not my intention to reverse that, the assumtion is a good one, I just wanted to be able to fine tune it to account for gun ergonomics in addition to size. Thanks for the patch
EDIT : Seems like you forgot handling values for the Glock 17, 18 and the 38. revolver in that Weapons.xml
[Updated on: Tue, 01 February 2011 03:54] by Moderator Report message to a moderator
|
Private
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #272200]
|
Wed, 02 February 2011 20:48
|
|
| Alex_SPB |
|
Messages:169
Registered:February 2008
Location: Russia, St.Petersburg |
|
|
ChrisLAlex, adding an "X" cthconstant to represent some arbitrary "generic handling" value for all weapons doesn't make any sense. You're asking that we define existing cth constants two mean two things: Handling OR "efficiency". That's not going to happen. I'm sorry that you want to use the existing handling constants to mean something else in your mod. I really can't think of a way you can do that without causing yourself alot of headaches. The ONLY option I would consider is replacing ubReadyTime with some other tag as the base "weapon handling" value (as Kafouille suggests). But without some idea what to set the value to, the best I could do is duplicate the existing column. But even if I do that, all the handling contstants would still be linked together.
Hmm, actually I hope it does make a sence. Let us compare my approach with the one proposed by Kafouille:
Kafouille's approach:
1) We are setting up an individual replacer for "weapon handling" => we edit all the weapon entries in either "items.xml" or "weapons.xml" => we need a new tag in "weapons.xml" => we break the Headrock's concept and move to the new one
My approach:
1) If we like the Headrock's concept - we do nothing
2) If we do not like the Headrock's approach we disable draw costs by setting aim_draw_cost to 0 (Zero)
3) We set X to the value we feel comfortable
4) We adjust selected weapons using the existing tag
Adwantages:
1) We do not need to adjust every weapon in items/weapons.xml
2) The system is fully compatible with the Headrock's approach
3) All other CTH_constants are still fully functional
4) We can adjust the importance factor of draw cost by setting (simultaneously) aim_draw_cast>0 (but lower then the default aim_draw_cost) and X>0
5) We can quickly adjust the overall efficiency of our aiming using different values of X without breaking the relative balance of the each weapon
6) Aim_XXX_stance constants become complitely independent ones (and do not break the relative balance of the weapon)
I do mean the following by the relative balance:
For example Glock 17 is 2X more efficient in aiming then M16 by default. If I increase either aim_draw_cast or aim_standing_stance by some value Glock17 would be (for example) 3X times more efficient in aiming then M16. So I can not make aiming either more or less efficient using CTHconstants as I will definitely break the relative balance
[Updated on: Wed, 02 February 2011 21:17] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273002]
|
Tue, 08 February 2011 23:30
|
|
| ElRaffa |
|
Messages:42
Registered:October 2009
Location: Italy |
|
|
I was thinking about it.
How about a CTH indicator like the old one, but with a "margin of error" displayed too?
Kinda like:
Where the yellow part represent a "margin of error".
So, instead of knowing EXACTLY the % chance to hit something, you know that your CTH is between, say 35% and 50%.
The gap between the 2 values decided by the weapon accuracy, and the effective result, a random roll before the effective roll.
Example:
1) roll to see where the accuracy fall between (as example above) 35% and 50%
2) usual to-hit roll with as CTH the result of the first roll.
Downside, your CPU will have to double-roll every shot... and I don't know how much extra work would be involved...
Well, it could be changed to a "roll to determine CTH" for every firing action instead of for every round... :headscratch:
---
44 minutes later:
What I posted up there is not meant as an alternative to NCTH (re-reading it seemd so).
What I meant is having an extra indicator to show how much the muzzle sway/recoil could influence the aim (and how it gives more info than the simple circle thingy).
Alternatively that double-color bar could be used to determine just the chance to get the center of the target (red) and the chance to just hit the target (yellow). But, IIRC the "not the center" feature is a part of the "handle the misses" of the original engine, so probably cannot be calculated up-front. Oh boy :idea2: .
[Updated on: Wed, 09 February 2011 00:22] by Moderator Report message to a moderator
|
Corporal
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273015]
|
Wed, 09 February 2011 01:58
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I'm not sure I'm understanding. The effect of muzzle sway is represented directly by the "shooting aperture". The "distance aperture" is the area in which the bullet will travel (including weapon accuracy) if a shooter had no ability to stabilize his weapon. The "shooting aperture" simply includes the shooter's ability to stabilize the weapon (i.e., muzzle sway). But there is no system to tell exactly where the bullet is going to go until you actually pull the trigger. About the only way to get even a general percentage chance would be to calculate exactly how many units existed within the diameter of the shooting aperture and compare it to the number of units that a target actually takes up. And I can only guess at how much processor power that would take. Especially on long range shots that have fairly large shooting apertures.
Also, keep in mind that there is no "to-hit roll" with NCTH. We generate two random values during the shooting process:
1. Random value 1 is used to determine the exact point at which the barrel of the weapon is pointing at the exact moment the trigger is pulled. The area that this "point" will be is an area smaller then the "shooting aperture" because this "point" has nothing to do wth accuracy. The exact size of this area, however, is not visually displayed. It's this shooting area that is directly controled by "CTH". So, if muzzle sway reduces the shooting aperture (excluding accuracy) to a 6.0 diameter circle, we'll randomly select a point in a 6.0 diameter circle. If muzzle sway reduces the aperture to a 20.0 circle, we select a random point in a 20.0 diameter circle. Etc.
2. Random value 2 is used to determine the exact trajectory of the bullet when it's fired. This is done be randomly selecting a point in an area whose radius is based on the weapon's nAccuracy value and centered on the exact point that was picked by Random Value 1.
The code then simply "moves" the bullet along the trajectory in order to pass through the exact point that's selected by the above random numbers. If that point happens to coincide with a point occupied by a target, then we hit.
The "shooting aperture" that is displayed is simply the largest possible circle in which the bullet could go. Here's an example:
This shot has a CTH 30 meaning the "shooting" (or smaller) aperture is 70% the size (100 - muzzle sway) of the "distance" (or larger) aperture. As far as the code is concerned, the shooting aperture is a 12.2 diameter circle, excluding accuracy. And the distance aperture is a 137.8 diamter circle. And I have a magnification factor of 7.9. The code will pick a random point within the 12.2 diameter circle. It will them create (internally) a second circle, centered on the point it just picked, with a diameter based on my weapon's nAccuracy (90) and MAX_BULLET_DEV. For this weapon I'm testing with, that results in a .5 diameter circle. So, at worst, a bullet fired will be in a 12.7 diameter circle which is what you actually see on the cursor. But even with all that information, I still can't tell you the exact percentage chance that a shot will actually hit the target because no percentage chance is actually ever calculated. I can simply tell I have a reasonable chance to hit because the target fills a good portion of the displayed "shooting aperture".
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273025]
|
Wed, 09 February 2011 03:14
|
|
| ElRaffa |
|
Messages:42
Registered:October 2009
Location: Italy |
|
|
Aye, Chris.
I know the aiming in NCTH consists in narrowing the "cone" trought which bullets are "sprinkled".
I assumed (wrongly!) that it still worked through math % calculations (after all the aperture size is, that I knew of, just a graphical aid, and not much reliable for determinating the area of impact that the bullets will have).
So, if I got it right, that problem is that once you set the cone (which itself represent the CTH), bullets will fly trought this cone randomly, and so you can detemine the aperture but not where bullets will land, rigt?
To me is not a problem at all, but if you think so, then SpaceViking's "test" would be awesome, especially cause the results will look like a real statistic (like a gun info sheet showing the MOA).
It should be run at a "standard" distance, tho.
Report message to a moderator
|
Corporal
|
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273078]
|
Wed, 09 February 2011 17:56
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Yes Rafaelito, that's basically how it works. The displayed aperture also isn't 100% accurate as I understand it. There's a small deviation because the display system and the internal "structure" system (the part that actually determines how much "space" a target takes up) use different methods for x,y,z coordinates. But it's about as close as it needs to be to suit it's purpose.
SpaceViking, the only real problem is that NCTH never generates a percentage chance. So the only way to gather that kind of data would be to actually "fire" 10,000 rounds. That said, supposedly there's already a system built into JA2 that lets you fire "fake" bullets so it should be possible to have a function run while in debug mode. It'll just really impact on response time. And it's probably not something you'd want to run unless you actually fired a round.
Also, you have to keep in mind that OCTH is NOT an accurate system. Like many other things in JA2, OCTH is strictly a "hit/miss" system. You either succeed in the hit chance and therefore hit "center mass" or you miss completely. One of OCTHs biggest issues is that the "base chance of success" is your marksmenship skill. Which implies that "environmental factors" (i.e., weapon handling/accuracy, range, visibility, etc) modify a merc's ability when in actuality a merc's ability allows him to counter "environmental factors". For instance, pretty much anyone, regardless of skill, can pick up a weapon and hit a target 2m away. Yet only the very best marksmen have any chance of hitting a target 1km away. To deal with this in OCTH we have range modifiers applied to the CTH calculation which is partially why OCTH has always been plagued with the whole "long range weapons are the best weapons at any range" thing.
NCTH, on the other hand, is based on range/weapon accuracy being the primary factor for cth, with skill being the modifier. So, technically, NCTH should never end up with the same CTH as what OCTH comes up with.
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273135]
|
Thu, 10 February 2011 02:08
|
|
| SpaceViking |
|
Messages:751
Registered:January 2004
Location: Rochester, Minnesota, USA |
|
|
ChrisLSpaceViking, the only real problem is that NCTH never generates a percentage chance. So the only way to gather that kind of data would be to actually "fire" 10,000 rounds. That said, supposedly there's already a system built into JA2 that lets you fire "fake" bullets so it should be possible to have a function run while in debug mode. It'll just really impact on response time. And it's probably not something you'd want to run unless you actually fired a round.
Also, you have to keep in mind that OCTH is NOT an accurate system. Like many other things in JA2, OCTH is strictly a "hit/miss" system. You either succeed in the hit chance and therefore hit "center mass" or you miss completely. One of OCTHs biggest issues is that the "base chance of success" is your marksmenship skill. Which implies that "environmental factors" (i.e., weapon handling/accuracy, range, visibility, etc) modify a merc's ability when in actuality a merc's ability allows him to counter "environmental factors". For instance, pretty much anyone, regardless of skill, can pick up a weapon and hit a target 2m away. Yet only the very best marksmen have any chance of hitting a target 1km away. To deal with this in OCTH we have range modifiers applied to the CTH calculation which is partially why OCTH has always been plagued with the whole "long range weapons are the best weapons at any range" thing.
NCTH, on the other hand, is based on range/weapon accuracy being the primary factor for cth, with skill being the modifier. So, technically, NCTH should never end up with the same CTH as what OCTH comes up with.
Yes, yes, I know all that. I know they won't come up the same.
I proposed actually firing 10k rounds so "fake bullets" would work perfect. I'd still like to see it added and of course it would only be in the debug version, perhaps even only with a special flag turned on during the build. I wouldn't use this all the time, just with some tests with different weapons at different ranges to see what happens.
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273158]
|
Thu, 10 February 2011 07:45
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
So after alot of testing, I've finally been presented with a savegame that demonstrates a probably issue rather nicely. Take a look at this image:
The top two images are with an AK-74, fitted with flash supressor and foregrip, taken at 15 tiles and 16 tiles, respectively. In both cases, the merc holding the weapon was able to get a 65 "muzzle sway" primarily due to the Ak-74's modest instability (ubHandling=15). The AK-74 also has an "effective range" of 33 tiles so both shots are basically at 1/2 effective range. And the AK-74 has an nAccuracy=63. The two apertures are pretty close but give you extra detail, the two shots had the following aperture values:
Distance Aperture: 30.34 & 32.06
Base Shooting Aperture: 10.62 & 11.22
Accuracy modifier: 2.10 & 20.22
Final Shooting Aperture: 12.72 & 13.44
The bottom two images are with the same merc, shooting at the same target, again at 15 and 16 tiles, respectively. However, with the bottom two the merc is not holding a pair of Calico M-950 pistols, both fited with flash suppressors. In both cases, the merc was able to get a 78 "muzzle sway" due to these weapons very low instability (ubHandling=1). The merc is suffering from using two weapons, but that only brings the ubHandling of each weapon to about 2.5. The M-950 also only has a range of 15 tiles, so the lower right hand shot is actually supposed to be beyond the weapons "effective range". And the M-950 has nAccuracy=20. As for the numbers making up those apertures, they are:
Distance Aperture: 30.34 & 32.06
Base Shooting Aperture: 6.67 & 7.05
Accuracy modifier: 4.55 & 4.80
Final Shooting Aperture: 11.22 & 11.85
And just to be clear, the "Final Shooting Aperture" is the smaller aperture that is actually displayed. I'm giving the Distance Aperture (which is not actually visible) so you can see that each weapon started with the same size aperture for the range the shot was being taken at. And I'm simply giving you all three other values to show what effects of accuracy.
So I'm seeing two probably issues:
1) The most obvious to me is simply the fact that those dual pistol shots, which are taken at and beyond the Calico's "effective range", actually have a better chance of hitting then the AK-74 shots taken at only 1/2 the ARs "effective range". I know this is the result because the Calico is "easier" to handle and therefore gets a better "muzzle sway" with max aim. You see, weapon handling is currently added in with other "aim modifiers" and the final iAimModifiers variable is used to alter the shooters "uiCap". In other words, with the current setup, a weapon with a 15 ubHandling used in the same situation as a weapon with a "2.5" ubHandling will pretty much always have a lower maximum "muzzle sway" no matter how much time you can spend "stabilizing" (i.e., aiming) the weapon.
Problem is, I don't think weapon handling is the problem. It should be harder to stabilize a large weapon when a small. But as I look at it, we're actually double penalizing "large" weapons. The Calico's only take 2 clicks to reach "max aim" meaning they are really quick to stabilize. While the AK-74 takes 5 clicks to reach "max aim" meaning it takes more time (20AP for the AK vs 8AP for the Calico's). But then we're also reducing the Ak's maximum "muzzle sway" by a ubHandling=15 versus the effective ubHandling=2.5 of the Calico's.
I know one possible solution would be to have weapon handling effect iAimModifiers as a percentage instead of simply adding them together. But I'm not really sure that's a good option as it could mean no weapon handling modifers might exist in certain conditions. I could also apply iAimModifers and weapon handling modifers as seperate percentage adjustments to the uiCap. But even these options would still result in higher ubHandling weapons always having worse stability then lower ubHandling weapons. The only way I can see to get around that would be to allow aiming clicks to compensate for weapon handling, at least in part.
2) The other, possibly less obvious, problem I'm seeing is the fact that firing the Calico's at 16 vs 15 tiles has the same basic effect as firing the AK at 16 vs 15 tiles. Even though 16 tiles is beyond "effective range" for the Calico, both weapons have about a 5.6% increase in aperture size. And as you can see from the numbers, because of weapon stability, even beyond "effective range", the Calico's are still more accurate then the AK.
I think we need the final shooting aperture to not only include the actual Distance Ratio and weapon Accuracy (like it currently does), but also some factor to account for weapon range. I get the fact that headrock intended for nAccuracy to >be< "effective range" but since smaller weapons normally have lower ubHandling, they'll normally have higher "muzzle sway" resulting in smaller apertures, which will usually more then offset (as is the case from my example) the "Accuracy modifier".
If I were to continue this example at closer to 30 tile range (double the Calico's range), you'd still see the Calico's having smaller "shooting apertures" (and theferore slightly better odds of hitting) then the AK. I'm just not sure what kind of penalty needs to be included. I don't want really long range weapons becoming the "best choice" at short range. And the fact that most really long range weapons have fairly high ubHandling values should always mean that short range weapons will be good choices. But I think we need something in place so that short range weapons don't end up with better "odds of hitting" then medium and long range weapons at medium and long ranges.
Report message to a moderator
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273218]
|
Thu, 10 February 2011 19:58
|
|
| Faithless |
 |
Messages:439
Registered:October 2009
Location: The safe end of the barre... |
|
|
I think you've described the problem well there. Double penalties for larger weapons.
I don't think it's a good idea to add a bonus for long ranged weapons though, because this would cause a sniper rifle to be more accurate than an m4 at *any* range, while an m4 will usually also shoot straight where you aim it at closer ranges.
This was something that has plagued OCTH for a long time, and it made rifles good all round weapons.
A better solution in my opinion would be to have all guns have the same number of aimclicks, but let handling decide how much aimbonus you get per click.
All weapons should have a max aimbonus that's independent from handling.
Weapons with good handling will get most of their bonus in the first few clicks, but later clicks will give a lesser result, because you already have most of your max bonus.
Guns with bad handling would get a more even spread of the bonus they get per click. The first few aimclicks will still get a better yield than the last few, but the difference will be alot less than with a gun with good handling.
This effectively does the same as the system that reduces the amount of aimclicks for small weapons, but it is much easier to differentiate between guns. Right now nearly every handgun has 2 aimclicks, making them almost the same.
When it all depends on handling and the aimclicks are the same for every gun, you can have any value for handling (0 to 10000 for all I care).
This way the two penalties are also combined in just one, making it more transparent.
Report message to a moderator
|
Master Sergeant
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273237]
|
Thu, 10 February 2011 22:04
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I'm not suggesting we "add a bonus for long ranged weapons". I'm simply concerned that pistols with an "effective range" of 15t, fired at 30t, have an ultimately better chance to hit then an AR with 33t "effective range" fired at the same 30t. Shooting beyond "effective range" should be harder then shooting within "effective range".
One possible solution would be to have the "Base Aperture" created using the weapons "effective range". The "Base Aperture" is never actually displayed but it is used to create all the other apertures (including "Distance" and "Shooting" which are both displayed). If an 80t (SR) weapon had a smaller "Base Aperture" then a 35t (AR) weapon, which had a smaller "Base Aperture" then a 15t Pistol, that might resolve the issue. And since the apertures are all based on ratios, the long and medium range weapons shouldn't be better at short range because of the weapon handling factor.
Or another possible solution would be to have NORMAL_SIGHT_RANGE fluctuate based on the weapons "effective range". This would have a similar effect where the apertures are concerned, though it would impact numerous other calculations, so I'mnot sure how good an idea this would be.
As for the weapon handling, aim clicks won't change anything. Currently, weapon handling is added directly to iAimModifiers. iMaxAimBonus is the difference between uiCap (which is based on attributes) and the "base" iChance (the CTH with no aiming), and finally modified by iAimModifiers. And iMaxAimBonus is then split amungst the number of aim clicks you can take. In other words, say you've got a merc with 90 uiCap which is weapon independant. With dual pistols you might have a 20 "base" iChance and Weapon Handling of -10 while an AR might have a 15 "base" iChance and -35 weapon handling. This means the iMaxAimBonus for the pistols would be (90 - 20) * -10% = 63 resulting in a maximum 83 cth with max aim. And an the AR would be (90 - 15) * -35% = 48 resulting in a maximum 63 cth with max aim. This would be true whether the pistols had the 2 clicks they currently get, or 8 clicks. You can't currently compensate for the iAimModifiers which are made up mostly by weapon handling.
Using the example from my previous post: Those dual pistols had an iAimModifiers of -2.0 before weapon handling (-10.0) was added in. And they only had -17.34 iAimModifiers when it's finally applied to iMaxAimBonus meaning over half the modifiers came directly from weapon handling.
And the AR had an iAimModifiers of +4.0 before weapon handling (-33.75) was added in. And it had a -35.09 iAimModifiers when it's finally applied to iMaxAimBonus meaning there were only another -5.34 points added after weapon handling was considered. Or, only -1.34 total points of modifiers from sources other then handling, meaning handling accounted for more then 96% of the modifiers.
I don't think aiming should be able to negate all weapon handling penalties. But maybe we should reverse how much penalty weapon handling applies to the "base" and "aim" portions of the equation. The AR from my example only had a -27.0 applied to it's iBaseModifier (-28.45 after all calculations) while the dual pistols had -7.0 applied to it's iBaseModifier (-12.45 after all calculations). If we reversed the weapon handling penalties to apply more penalty to the iBaseModifier and less to the iAimModifier, that would still allow better handling weapons to reach ultimately higher max CTH, but the difference shouldn't be as great. And it would make poorly handling weapons all but useless without proper aim (which actually makes sense to me).
EDIT: So I added a BASE_STANDING_STANCE and played around with some of the weapon handling modifiers.
BASE_DRAW_COST = -2.0
BASE_TWO_GUNS = 5.0
BASE_ONE_HANDED = 2.5
BASE_STANDING_STANCE = 2.0
BASE_CROUCHING_STANCE = 3.0
BASE_PRONE_STANCE = 4.0
BASE_HEAVY_WEAPON = 2.0
AIM_DRAW_COST = -1.0
AIM_STANDING_STANCE = 1.5
AIM_CROUCHING_STANCE = 1.25
AIM_PRONE_STANCE = 1.0
AIM_TWO_GUNS = 4.0
AIM_ONE_HANDED = 2.5
AIM_HEAVY_WEAPON = 2.0
The end result is displayed here:
This gives the AR a slightly better chance to hit even though it's still got a lower "muzzle sway" (74 vs 80). If we lower AIM_DRAW_COST it improves the AR even more: at -0.75 we get "muzzle sway" of 78 vs 81 and at -0.5 we get 81 vs 82. In all three cases, the "base" iChance is 19 for the AR and 22 for the dual pistols.
And if we set BASE_DRAW_COST to -4.0 (with aim back at -1) we get a "muzzle sway" range for the dual pistols of 20 to 80. And a range of 12 to 73 for the AR. In either event, it seems like we can resolve the handling problems simply be changing the "weight" of how much handling effects the base vs the aim chance.
[Updated on: Thu, 10 February 2011 23:05] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273257]
|
Fri, 11 February 2011 00:16
|
|
| AndroidXP |
 |
Messages:32
Registered:July 2003
Location: Austria |
|
|
To be honest, I don't quite understand what "weapon handling" means if mapped to reality and I won't even attempt to untangle the big string of numbers that was just thrown around  . I fear NCTH has kind of tripped over its own legs in the attempt to achieve weapon balance, so I suggest to take a step back and have another look at the basics. (All these gazillions of, outside of a few people, poorly understood weapon modifiers with seemingly arbitrary values certainly don't help clearing things up.)
Now, the base premise of NCTH - having a real cone of fire rather than %-based hit/miss - is a very good one.
However, the way the cone/aperture size is calculated (or maybe rather, how the base input values were calculated) seems to suggest a certain agenda that might just clash with reality. Let me put it this way: if you were to find a good algorithm - a good model - of how to simulate true-to-reality shooting dynamics and input real, objectively sound values into this model, the result will be that pistols have very limited use and modern assault rifles outclass almost everything else at almost every range. Why? Because that's just the way it is in reality. If you base your model on reality, you're going to get realistic results, as much as you might dislike this in regard to game dynamics.
Overall I get the impression that you (as in the impersonal "you") are applying heavy, artificial penalties to "big guns" for the sake of nerfing them at close range, but then wonder why they underperform even at their intended role (because it turns out the values used to nerf them affect them at all ranges).
So "handling". What is it? Ability to quickly put your sights on the target? Isn't that what the draw cost is supposed to do? Or maybe additional AP costs for not aiming at the same tile as before - the bigger the difference (relative to the merc), the bigger the cost? Maybe increased penalty to hit a moving target?
Hm, so what else, ability to "stabilise" the gun? So a handgun that is held freely is somehow easier to stabilize than an assault rifle with its stock resting on your shoulder? Maybe the used term is not the right one or I misunderstood what was meant, but the latter seems like a lot more "stable" platform to me. The current behaviour in general suggest that somehow all people in JA2 have jello knees and struggle immensely just keeping the gun pointed at the enemy, with "big" guns having unworldly aiming difficulty as if some evil god has played too many FPSs and is applying random "sniper rifle sway" the bigger the gun is.
Now, to make this post more constructive, what can effectively be done with what we have? I think the premise of making smaller guns easier to aim is not a bad one. Less clicks required to achieve maximum aim is good, and promotes CQB usage. However, the best possible aperture size on a short-ranged weapon needs to be inherently a lot worse than on longer ranged weapons, since that is what effective range is all about. Besides the physical range limitation of the slower handgun bullets, the main factor is that your aiming apparatus (the sights) is a lot worse due to how close together they are (plus the limited ability to adjust for bullet drop), how unstable a pistol in your hands is compared to, for example, an assault rifle resting on your shoulder, and last, how mechanically accurate your gun is due to manufacturing quality and barrel length.
Overall, range should determine the best achievable aperture; handling, if anything, should determine how much AP you have to spend to get to that point, but not have any direct impact on accuracy. If a gun is supposed to be inaccurate, give it high autofire penalty and/or higher uncounterable bullet deviation. Or, even better, less effective range. The mysterious handling property seems counter-productive and ill fitting to fulfil that purpose.
But how to prevent ARs from becoming all-purpose headshot railguns in the game? I think some other mechanic outside of the aiming calculation itself is needed. For example, restricting the available aim clicks (on difficult to aim/handle weapons) if you have moved last round. Or if your breath is low. You just ran and crouched? Sorry but the last three aim clicks aren't available. You moved last round? Last two aim clicks not available. You spent AP turning? The same. Maybe even deduct one aim click if you're not aiming at the same tile as before.
In game terms, rifles should be accurate, but only if you're not on the move and had some time to settle in. Pistols and SMGs shouldn't be affected as much (or at all) by prior movement due to "easier handling" if you will - they're restricted enough by the lower effective range. Now, overall that might sound like something the AP aim cost (and more aim clicks required) was supposed to solve, but really, the turn based nature of JA2 defeats that point. One well aimed shot is all you need, the aim cost just limits the total amount of shots you can put down range per round. What must be prevented is aiming that accurately to begin with. Of course, if you sit still, you can merrily headshot away, but that's kind of the point, isn't it? If you can afford to sit still, you're definitely in a good AR engagement range. If you move, the more unwieldy the weapon is, the less aim clicks will be available, making them less accurate in that situation without nerfing overall accuracy.
Welp, that's my 2c at least.
Report message to a moderator
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273276]
|
Fri, 11 February 2011 02:30
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Handling and "draw cost" are the same thing. The ubHandling value in weapons.xml is the base handling characteristics for the weapon. Modifiers like BASE/AIM_XXX_STANCE, BASE/AIM_TWO_GUNS, BASE/AIM_ONE_HANDED, BASE/AIM_HEAVY_WEAPN and BASE/AIM_DRAW_COST are applied to the weapons handling. For example, having a lower AIM_PRONE_STANCE modifier then AIM_STANDING_STANCE implies that a weapon is easier to handle when we're prone.
I fully agree with you about range needing to be a factor. Currently IT'S NOT. The first part of my post pointed that out. I honestly think accuracy alone is not enough to determine aperture size. Range should be factored in as well.
I don't agree with limiting "aim clicks" based on actions. You already have that and forcing another level of it is just "double penalizing". Aim clicks in NCTH simply represent the time a shooter can invest in a shot. If you spend half you turn moving, you only have half as many APs available to ready, aim and fire your weapon.
I don't really have a problem with "handling" because it helps to offset the accuracy (and eventually range) of a weapon. I just think it needs to be adjusted so that "aiming" can compensate for more of it then is currently possible. If you do away with handling, especially if we apply a modifier to the Aperture based on range, then Sniper rifles would become the best weapons in the game. ARs/LMGs would be a marginal 2nd (mostly for suppression). SMGs, MPs and Pistols would become completely worthless. Why? Because if every weapon can always attain 95 "muzzle sway" you never need to use a short range weapon once you have a long range one.
Report message to a moderator
|
|
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273348]
|
Fri, 11 February 2011 17:57
|
|
| AndroidXP |
|
Messages:32
Registered:July 2003
Location: Austria |
|
|
ChrisLHandling and "draw cost" are the same thing. Thanks, didn't know they're already related
Quote:I fully agree with you about range needing to be a factor. Currently IT'S NOT. The first part of my post pointed that out. I honestly think accuracy alone is not enough to determine aperture size. Range should be factored in as well. Frankly, I'm surprised that range wasn't used as a base to begin with. That's the whole point of "effective range" (since that's what you define with it, not maximum physical projectile range), meaning if you're out of it, your accuracy will be too low to effectively combat the enemy. Bullet drop should be a secondary concern, as it is pretty insignificant in gameplay IMO.
From that you'd just have to define what exactly "effectively combat" means in game terms. For example, it could mean that with max aim (w/o scope, good or best MRK) at effective range, you'd get an aperture with a diameter the size of the target (which leaves plenty of room to miss). You can still hit beyond effective range, but your chances are not that great. Plus bullet drop will make things even worse.
Accuracy should then be only a secondary modifier that offsets this base aperture a bit... however, that would basically modify the "effective range", so I'm not sure if that's even a good idea. Maybe accuracy should just be what it actually implies: an indicator of the fixed bullet deviation and nothing else. No matter how well you aim a gun at a faraway target using scopes and other fancy gadgets, if you have crappy accuracy, bullet deviation will ruin your day anyway.
Quote:I don't agree with limiting "aim clicks" based on actions. You already have that and forcing another level of it is just "double penalizing". Aim clicks in NCTH simply represent the time a shooter can invest in a shot. If you spend half you turn moving, you only have half as many APs available to ready, aim and fire your weapon. Fair enough, I thought it would be a intuitive idea on how to prevent mercs who are moving with "bad handling" weapons from shooting them accurately Rambo-style.
AP costs do in my opinion not solve this at all; currently you can still pop around a corner, crouch, draw your gun and aim with full AP, sniping the guy across the courtyard. Sure, AP simulate "time", and if mapped to reality it makes sense, as all you need to steady your gun is time. BUT, JA2 is not realtime, it is turn based. It doesn't matter how much time something takes, as long as you can still execute it in your turn, because one hit is all it takes to prevent the enemy from killing you next turn.
If you'd limit the aim clicks in certain movement situations (depending on weapon handling, of course), then you could nicely prevent Rambo activity without sacrificing the guns capabilities when used as intended.
If you want to solve it with AP costs, maybe they are too low for bad handling weapons at the moment. A fully aimed sniper shot should take (nearly) max AP then, as that's the only real way to prevent fully aimed shots after movement. But it doesn't solve the problem as nicely, as it would mean semi-auto sniper rifles can only accurately shoot once per round too, even if you're not moving.
At least that's what I understand "handling" should be, the amount of run-and-gun you can perform with the weapon, a.k.a. its CQB capabilities. Aiming difficulty (how many clicks for full aim, how much a click helps (a click doesn't necessarily have to be a linear improvement)) of course, too.
Quote:I don't really have a problem with "handling" because it helps to offset the accuracy (and eventually range) of a weapon. I just think it needs to be adjusted so that "aiming" can compensate for more of it then is currently possible. If you do away with handling, especially if we apply a modifier to the Aperture based on range, then Sniper rifles would become the best weapons in the game. ARs/LMGs would be a marginal 2nd (mostly for suppression). SMGs, MPs and Pistols would become completely worthless. Why? Because if every weapon can always attain 95 "muzzle sway" you never need to use a short range weapon once you have a long range one. To your last point, limiting aim clicks would prevent exactly that.
I've never said to remove handling, I just meant it shouldn't have a direct influence on base aperture size. I do understand your intention (bad handling weapons require more AP spent aiming to get to their intended effective range accuracy - currently they can't compensate enough respectively handling has a too big impact). Correcting that, however, will not fix misuse, IMO it will just make them Rambo-able again. Why? Because AP costs do only rarely actually prevent you from reaching maximum or sufficient aiming level in my experience. Only if the game says "no" and doesn't let you aim fully after movement (because "the weapon is so unwieldy, it needs at least a turn to settle"), you will truly be able to fix what the current AP costs in a turn based environment can't. Or maybe make higher aim levels exponentially more expensive AP-wise if you have moved, if you're hell bent on solving this with AP
Pistols and SMGs would then have the distinct advantage of not being penalized (as much, or at all) by merc movement (they "handle" better). Also, they're easier to aim, so you might be able to fight multiple targets effectively in one round. Increased AP costs for aiming at different tiles for bad handling weapons, as I've suggested earlier, would add another incentive to use pistols and SMGs as intended.
Well anyway, please definitely try your suggestions first; maybe they turn out to solve the problem in a satisfactory way. I do certainly lack the in depth knowledge of the system, so I'm just expressing my concerns with the issues I see, based on the way I perceive NCTH to be working.
loonyphoenix... I completely agree, the whole picture needs to be understood before "hacking in" changes.
Report message to a moderator
|
|
|
|
|
| Re: HAM 4.0 Alpha Testing Thread[message #273360]
|
Fri, 11 February 2011 19:55
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Well, part of the reason I give you guys so many numbers from so many areas is to try and include as much of the picture as possible.
Currently there are three systems involved in calculating "cth".
1- Muzzle sway (the "chance to hit" result on the 'F' hotkey) which is strictly the mercs ability to aim and control his weapon.
2- The actual range to target which has absolutely nothing to do with the weapons "effective range" but does factor in magnification from scopes and "projection factor" from lasers.
3- The weapon's actually accuracy.
Part of the issue is that when Headrock introduced NCTH, he redefined the ubRange value as "maximum range" thus effectively cutting all weapon ranges pretty much in half as compared to OCTH. But he also externalized the "gravity" value which is how the game actually determines "max range", thus allowing players to get the "max range" they're used to. But with no system to account for "effective range", other then the nAccuracy value, the result is you can setup "realistic max range" and have a pistol that's nearly as effective at long range as a sniper rifle. With the current system, really the only "perk" the SR would have is the fact that it can mount a sniper scope. But if you take an AI AWM with no attachments, and a .38 special, set the gravity variables to "realistic levels" and fire at a target 50 tiles away, both weapons would result in pretty similar chances to hit. That's a bit of an exageration, of course, since at that range the weapon's accuracy has a pretty big effect, but only about a 33% difference which doesn't seem like enough to me considering you're well within the AWM's "effective range" but about 5x the .38s.
"it could mean that with max aim (w/o scope, good or best MRK) at effective range, you'd get an aperture with a diameter the size of the target". Unfortunately, this would result in long range weapons being the "best choice" at any range. Remember, everything is based on ratios. So if an AWM (137t range) got a shooting apreture (without a scope) the size of a soldier at 137 tiles, it's going to have a tiny aperture (regardless of what penalties we throw at it) at 10 tiles. Currently the "range" portion of the equation takes the actual range and compares it to the NORMAL_SIGHT_RANGE value. This way, the basic "distance aperture" is the same regardless of the weapon and is meant to represent (as I understand it) the shooters ability to see the target well enough to aim effectively. Hence why the "distance aperture" is reduced by magnification factor since the shooter can see the target better when using a scope.
But I do think we need something to show that a weapon is being used beyond it's "effective range". Something that won't give a benefit to SRs (making them "best" weapons) but still puts in an appropriate penalty. And something that doesn't act like OCTH where accuracy seems to "hit a wall". What I'm thinking is a ratio of actual range and ubRange, with a minimum of 1.0, used to increase the "distance ratio". This should allow all weapons to be as effective as they are now out to their "effective range" (so no bonus for being close with a long range weapon) but start an additional incremental penalty for shooting beyond "effective range".
Finally, NCTH (and to a lesser extent, OCTH) is a HUGE system. Makes sense considering calculating chance to hit in a weapon combat game is a fundamental part of the game. I try to give as many details as I can without overwhelming you with information that may not mean anything to you (that's the general "you") or that "you" might not have a context for. But when I'm coding changes, to the best of my ability I try to pay attention to the whole system and not just the one part I'm talking about. That way I don't make suggestions that are likely to impact areas of CTH that I'm not aware of. I'm certainly not perfect in that regard, but I do try, even if it doesn't always seem so.
Report message to a moderator
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Wed May 15 06:07:27 GMT+3 2024
Total time taken to generate the page: 0.02747 seconds
|
Blog
Search
Help
Members
Register
Login
Home
