Home » MODDING HQ 1.13 » v1.13 Idea Incubation Lab » HAM 4.0 Alpha Testing Thread
|
|
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271348]
|
Wed, 26 January 2011 19:04
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
loonyphoenixI see another problem with recoil. Recoil itself should not drive the barrel in any direction, ideally; a very good weapon is well-balanced and its recoil is only applied in the direction of your shoulder, which can start to ache after a while, but doesn't affect aiming directly. Vertical and horizontal recoil doesn't depend as much upon recoil velocity or recoil energy as it does on the design of the rifle. If its center of mass is along the line of the barrel, there shouldn't be horizontal and vertical recoil at all; the further it deviates from it, the more the weapon's mass and the bullet's kinetic energy and the weapon's anti-recoil mechanisms start to matter.
I have no idea where to get these values except to make them up and correct as we go along. The general rule that a average LMG should have better recoil than the average SMG should be followed, sure, but that's not a strict rule. Maybe the weapon's price should also be taken into account? The higher the price, the better its recoil among the weapon's kind? We can't exactly research every weapon out there and calculate these values. Actually, recoil by itself is simply a result of physics and things like the law of the conservation of motion and energy. Any action has an equal and opposite reaction. A body in motion tends to stay in motion... a body at rest tends to stay at rest. If you fire a 4gram projectile at 1000m/s from a 4kg weapon, the weapon will move in the opposite direction at 1m/s. The catch is, this movement is in line with the barrel and most weapons don't have barrels that are exactly centered over the butt (or handle). Your shoulder (or hand or whatever else) converts the linear motion into transversal motion (I believe that's the term) which results in the weapon going up and sideways. Also, as Alex_SPB says, there are some moving parts that have an effect. So I don't have an issue with the X/Y recoil system that Headrock setup. I simply need to come up with marginally accurate values that aren't arbitrarily tweeked to "make SMGs better then LMGs". However, I'll more then likely do something similar to what Sovereign suggests and let someone more qualified then me deal with balancing the final recoil numbers.
Max, that "sending bullets into the ground" thing is problably the balance issues with the gravity system. I suggest playing around with the RANGE_COEFFECIENT and GRAVITY_COEFFECIENT values in cthconstants.ini until you get a setting that looks right. Then post your results so we can eventually get the ini file balanced properly.
As for the "used magnification" that's based on the range to target and the scopes minimum effective range. If the magnification value is less then the max for your scope, you're within the scopes minimum effective range and penalized by the AIM_TOO_CLOSE_SCOPE penalty. Using default values and excluding skill traits, the minimum effective range of a battle scope and a sniper scope are 34 and 49, respectively. Using either to shot at a target at 20 tiles will result in a 14t and 29t penalty (respectively). You can see this penalty in the cth and the size of the shooting aperture: 80 with iron sights, 60 with battle scope and 40 with sniper scope. And the battle scope results in a smaller shooting aperture then the sniper scope and iron sights, meaning the battle scope will ultimately have the best chance to hit the target.
Report message to a moderator
|
|
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271377]
|
Wed, 26 January 2011 22:01
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
Is there any reason my sniper rifle says it has 8 aiming levels but only has 5 or is this a bug?
The recoil is alot better now. Testing with a full statted merc and he hits a good amount. Will try with a normal merc later.
EDIT: The AI seems to autofire alot while hitting nothing much in particulair, though.
[Updated on: Wed, 26 January 2011 22:21] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271390]
|
Wed, 26 January 2011 23:44
|
|
SpaceViking |
|
Messages:751
Registered:January 2004 Location: Rochester, Minnesota, USA |
|
|
ChrisLIn NCTH, fewer aiming clicks is better. Every weapon can ultimatly get the "same" amount of bonus from aim. The difference is simply how much time you have to spend to stabilize the weapon enough to get max aim. The ubAimLevels value in weapons.xml is also only the base aim levels. There are attachments that can "improve the speed of aiming" which thereby lowers the aim clicks you need to reach max aim. Also the Prof_Sniper_OT, Sniper_NT and Gunslinger_NT traits will reduce the number of aim clicks you need to reach max aim. So your merc only needs 5 clicks to reach max aim because you're getting a 3click bonus. Basically, it takes your merc fewer APs to reach max aim then it would someone less trained.
The ISM-V-IR, Kobra, ACOG 4xC, and Reflex Sight each have a -1 AimLevels modifier so if you have any of those attached to your weapon, and you've got 2 levels of either Prof_Sniper_OT or SNIPER_NT, that would explain why you're needing only 5 clicks instead of 8.
Does that mean if (for example) I start aiming and after several clicks the aiming circle doesn't get smaller then clicking more won't help?
Report message to a moderator
|
|
|
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271403]
|
Thu, 27 January 2011 01:35
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
WS, I actually figured out the hitting problem. I talk about it in the Beta release thread here. It's nothing to do with range, scopes, rounding or anything like that. It's strictly the way Headrock "taught" the code to view the "space" a target takes up. I'm working on trying to fix things by "re-teaching" the code but this is a portion of code I've never delved into before so I'm not even sure where to start looking.
@SpaceViking: Unlike OCTH, every click of aim in NCTH has some kind of benefit. This is because the actual CTH calculation looks at the difference between "cth cap" and the cth without aim clicks, and splits the resulting number between all available aim clicks (though it's on a weighted scale where more later clicks are worth more then early clicks). The only way to get to "max aim" is to use all available aim clicks. Of course, depending on various factors, (and when the code recognizes the "space" a target takes up properly) you might get the shooting aperture smaller then the target before you reach max aim. And, technically, if the shooting aperture fits "inside" the target, there should be little to no chance of missing the shot.
Report message to a moderator
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271523]
|
Thu, 27 January 2011 21:33
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
I'm a little curious just how "accurate" you want to make things. Below is a screenshot for one of my mercs. He's a fairly advanced sniper with the Marksemen stomp trait (2x Sniper) using an AI AWM, prone with a bipod. And as you can see from the image, the target is not only at 72 tiles away, but I can't actually see her (had to turn on cheat codes to reveal all enemies).
This is using the same CTHConstants.ini file that I uploaded to my mediafire page. This shot has pretty much no chance of actually missing the target. So, how much more accurate do you think you'd ever want to make something?
Anyway, AIM_DRAW_COST is strictly a multiplier against the weapons effective "gun aim difficulty". iGunAimDifficulty is the weapon's ubReadyTime, modified by to total PercentReadyTimeAPReduction and PercentHandling tags associated with the weapon and it's attachments, and the AIM_xxxxx_STANCE modifiers from CTHConstants.ini. The last piece factored into iGunAimDifficulty is AIM_DRAW_COST which is a straight multiplier. At the default setting of -1 (that is, "negative one"), it simply converts the iGunAimDifficulty into the penalty it's supposed to represent but if you set the value to 0, you're basically telling NCTH to totally ignore the weapons handling characteristics. That said, like most of the NCTH external values, AIM_DRAW_COST is a FLOAT so if you really want to make weapons more accurate, you can simply use a value like -0.1 which would result in 1/10th the weapon handling penalty that is applied by default.
Report message to a moderator
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271529]
|
Thu, 27 January 2011 21:52
|
|
Faithless |
|
Messages:439
Registered:October 2009 Location: The safe end of the barre... |
|
|
Quote:Secondly I look at the cursor behavior and notice a huge stepped increase in shooting aperture size from 23 to 24 tiles.
This bug is always (?!) present in the NCTH but it is difficult to spot it without decreasing aim_draw_cost Alex is not saying NCTH that shots are too inaccurate, but that it's weird that the cth when the target is just one square further.
Might it have something to do with the rubble lying there, possibly blocking his view a little?
Or does this always occur at this range?
[Updated on: Thu, 27 January 2011 21:52] by Moderator Report message to a moderator
|
Master Sergeant
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271530]
|
Thu, 27 January 2011 22:21
|
|
Alex_SPB |
|
Messages:169
Registered:February 2008 Location: Russia, St.Petersburg |
|
|
WarmSteelAlex is not saying NCTH that shots are too inaccurate, but that it's weird that the cth when the target is just one square further.
This is exactly what I mean! I am not playing the game but testing the new CTH system. As of now I am interested in the mechanics, not in the gameplay. The main reason to consider this bug bore seriously is called "big maps". It will be normal to use iron sights on 24 tile distance while playing on big maps and this will be currently impossible.
This is an unpredicted behavior of the system which is bad. The main idea behind "NORMAL_SHOOTING_DISTANCE" is that if I want to play on big maps I can just tune up one modifier instead of going through hundreds of entries in weapons.xml. It just does non help here because this bug is not affected by changes of "NORMAL_SHOOTING_DISTANCE"
[Updated on: Thu, 27 January 2011 22:22] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271531]
|
Thu, 27 January 2011 22:30
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Technically, NCTH doesn't know whether you hit or miss until the bullet is fired and reaches it's target. All the NCTH system does is determine the "offset from center" of the tile you're targeting. Here's a "quick and dirty" explanation of how a tile is "constructed" as I understand it.
A "Tile" is made up to 125 "cubes", stacked in a 5x5x5 3D grid. Each cube is approximately 2 units wide by 2 units deep by 6 units tall. A tile is ostensibly 10 units wide by 10 units deep by 60 units tall. Every "obstacle" in the game fills certain cubes in a certain pattern. For instance, from what we can tell, a standing merc "fills" cubes in a tile in "+" sign pattern that's 3 cubes wide by 1 cube deep by 3 cubes tall. When you fire a round at a target, the program "moves" the bullet through all the cubes in it's path with a destination of the specific cube in the specific tile you were aiming at based on the muzzle offsets that were generated during the NCTH process. If one of those cubes is "occupied" then the bullet impacts whatever occupied the cube. In the case of a standing soldier who is facing directly towards or away from you, this means a muzzle offset of 2.5x1.5 will "pass through" the right hand "arm" of our "+" sign, and therefore hit the target.
That's the big difference between OCTH and NCTH. In OCTH, the game generated a chance of hitting. If a random number was less then or equal to that chance, then you were hit. The code would then "move" a bullet directly to the center point of your target. OCTH knew exactly what your odds of hitting were because it is pretty much an all or nothing system. If you hit, you hit "center mass". If you miss, you miss completely.
In NCTH, we never generate a "chance to hit" and we never grab a random number to determine if you hit or not. All we do is figure out where the barrel is pointing when you "pull the trigger" and then follow the path of the bullet to see if it ever intersects with our target or not. So the code is just as "in the dark" as you are about whether you're going to hit a target or not.
Anyway, instead of modifying some arbitrary "chance to hit percentage", most attachments simply alter the characteristics of a weapon. Some tags mess with the accuracy of our weapon (like ScopeMagFactor, ProjectionFactor and PercentAccuracyModifier). Other tags impact the recoil (like RecoilModifierX, RecoilModifierY, PercentRecoilModifier and the various "CounterForce" tags). And others have an effect on weapon handling (like FlatBase, AimBase and AimLevels).
And if I've misunderstood what Alex was getting at, I appologize. But to figure out why you might have a large aperture change between 23 and 24 tiles, I'd really have to have a savegame that demonstrated the problem. The "distance aperture" (that's the larger circle) is only based on two factors: DEGREES_MAXIMUM_APERTURE and NORMAL_SHOOTING_DISTANCE. Terrain, attachments, stats... none of that has any bearing on the "distance aperture". The "shooting aperture", on the other hand, is made up of two primary factors: the weapons "Magnification Factor" and the "MuzzleSwayPercentage".
Magnification factor is pretty simply. It's simply based on your range to target, and either your scopes MagFactor or your laser sights ProjectionFactor.
MuzzleSwayPercentage, on the other hand, is alot more complicated but also has the largest effect on the "shooting aperture's" size. Range, obstacles, aim, skill, attachments, weapon handling, and a few other things are all factored together to come up with a "MuzzleSwayPercentage".
We take the "distance aperture" and reduce it by the mag factor, thus creating a "max aperture". Then we reduce this "max aperture" by our MuzzleSwayPercentage which results in the "shooting aperture".
As Headrock has previously mentioned, there is some slight difference between the system that displays the cursor and the system that calculated the actual offsets but the fundamentals are pretty much as I've described them.
If you do have a savegame you can make available to me, I'm more then willing to trace out the code and try to figure out why you might be getting large deviations in aperture size for small changes in range.
Report message to a moderator
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271532]
|
Thu, 27 January 2011 22:37
|
|
Alex_SPB |
|
Messages:169
Registered:February 2008 Location: Russia, St.Petersburg |
|
|
ChrisLI'm a little curious just how "accurate" you want to make things. Below is a screenshot for one of my mercs. He's a fairly advanced sniper with the Marksemen stomp trait (2x Sniper) using an AI AWM, prone with a bipod. And as you can see from the image, the target is not only at 72 tiles away, but I can't actually see her (had to turn on cheat codes to reveal all enemies).
This is using the same CTHConstants.ini file that I uploaded to my mediafire page. This shot has pretty much no chance of actually missing the target. So, how much more accurate do you think you'd ever want to make something?
This bug works when aiming iron sights and as far as I see you are using sniper sight. The main idea is the system behavior - not the balance. Something is going wrong in the calculations.
ChrisL
Anyway, AIM_DRAW_COST is strictly a multiplier against the weapons effective "gun aim difficulty". iGunAimDifficulty is the weapon's ubReadyTime, modified by to total PercentReadyTimeAPReduction and PercentHandling tags associated with the weapon and it's attachments, and the AIM_xxxxx_STANCE modifiers from CTHConstants.ini. The last piece factored into iGunAimDifficulty is AIM_DRAW_COST which is a straight multiplier. At the default setting of -1 (that is, "negative one"), it simply converts the iGunAimDifficulty into the penalty it's supposed to represent but if you set the value to 0, you're basically telling NCTH to totally ignore the weapons handling characteristics.
This is what I basically want because I do not like the idea of
[Updated on: Thu, 27 January 2011 22:55] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271533]
|
Thu, 27 January 2011 22:50
|
|
Alex_SPB |
|
Messages:169
Registered:February 2008 Location: Russia, St.Petersburg |
|
|
ChrisL
And if I've misunderstood what Alex was getting at, I appologize. But to figure out why you might have a large aperture change between 23 and 24 tiles, I'd really have to have a savegame that demonstrated the problem.
I was meaning the "shooting apperture", sorry if i did not make it clear from the beginig. There is nothing wrong with the "distance aperture". The problem seems to be somewhere in the aiming calculation.
ChrisLWe take the "distance aperture" and reduce it by the mag factor
This seems to be the bug of iron sights - not the scope magnification calculation.
If you do have a savegame you can make available to me, I'm more then willing to trace out the code and try to figure out why you might be getting large deviations in aperture size for small changes in range.
It is very simple to reproduce the bug - you just need to set aim_draw_cost to 0. I am 99% you will see it.
CTHconstants http://www.mediafire.com/?tlcid377r6ccc8a
save game http://www.mediafire.com/?76o6cca6lg5h16w
[Updated on: Thu, 27 January 2011 22:53] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271534]
|
Thu, 27 January 2011 23:05
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
"Draw cost" mechanics is the weapons handling characteristics. If you don't like them, set aim_draw_cost to 0 and it turns off all the handling characteristics. But you'll also disable the AIM_xxxx_STANCE modifiers because they are part of the handling characteristics. It's not a "bug" if you turn off handling characteristics and find that they are all turned off. Admittedly, base handling characteristics are currently generated from the weapon's ubReadyTime. This may or may not be the best factor for determining a weapon's base handling characteristics? But we don't have another tag that works better.
Here's another set of screen shots. Same merc from my last screenshot, using the same weapon. This time I've removed the sniper scope so this is based solely on iron sights. The top half of the image is at 23t and the bottom half is at 24t. While there is a slight size difference in the apertures, it's nothing I wouldn't expect to see because of the range. So, again, if you have a savegame that demonstrates the problem you're experiencing, making it available to me would really help.
EDIT: Again, if you set AIM_DRAW_COST to 0 you're turning OFF the modifier for handling characteristics. This is not a bug.
[Updated on: Thu, 27 January 2011 23:07] by Moderator Report message to a moderator
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271536]
|
Thu, 27 January 2011 23:24
|
|
Alex_SPB |
|
Messages:169
Registered:February 2008 Location: Russia, St.Petersburg |
|
|
The save game link is available in my previous post:
CTHconstants http://www.mediafire.com/?tlcid377r6ccc8a
save game http://www.mediafire.com/?76o6cca6lg5h16w
ChrisLEDIT: Again, if you set AIM_DRAW_COST to 0 you're turning OFF the modifier for handling characteristics. This is not a bug.
This means that there is no way to turn it off. Is it possible to make an Aim_XXX_stance modifiers independent from aim_draw_cost?
[Updated on: Thu, 27 January 2011 23:31] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271543]
|
Fri, 28 January 2011 00:51
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
No, you can't make aim_xxx_stance independant from aim_draw_cost because they modifiy the same value that aim_draw_cost modifies.iGunAimDifficulty *= gGameCTHConstants.AIM_STANDING_STANCE The other two stance modifiers do the exact same thing. All aim_draw_cost is meant to do is convert iGunAimDifficulty to a penalty. But iGunAimDifficulty is still the basis for the whole variable.
Your cthconstants.ini has turned aim_draw_cost off so no weapon handeling characteristics are being included.
Beyond that, the reason "1 tile" seems to be making such a huge difference is that you can't actually see that tile. I couldn't run the test on the apparent two tiles you did, most likely because my ja2_options.ini has a BASE_SIGHT_RANGE of 15 and you're probably using the default 13. I was able to find a pair of tiles next to each other, though, that got similar results. One at 27 tiles. The other at 28 tiles. In both cases, my maximum visibility distance is 300. The iSightRange of the 27tile shot came in at 298 while the 28tile shot came in at 307. Since this is higher then my visibility distance I'm being hit with the various "target_invisible" penalties. So that's a -100 to the iBaseModifier calcuation and another -50 to the iAimModifier calculation.
You have to remember that the values in CTHConstants.ini effect NCTH functions and calculations ONLY. The functions that calculate visibility are NOT specific to NCTH, therefore they aren't effected by anything in cthconstants.ini. Changing the NORMAL_SHOOTING_DISTANCE in cthconstants.ini simply changes the way the various distance ratios are created. But that doesn't override the BASE_SIGHT_RANGE which is what determines how far you can actually see.
And before you start making drastic changes to the target_invisibile values, you should be aware that both iBaseModifier and iAimModifier are strictly modifiers to iChance. That -100 to iBaseModifier isn't going to have a drastic effect because iChance is very small when iBaseModifier is factored in. For my test, iChance was only 23 and iBaseModifier was -162 because of the target being invisible. That basically means I have 0 stability with a hip fire shot compared to the 8 I would have gotten without the penalty. iChance can't fall below 0 because of iBase Modifier. On the other hand, the -50 to iAimModifier has a major effect because it dropped my iAimModifier from -3.1 to -53.1 which drastically reduced my iMaxAimBonus (from 83.3 to 40.3).
EDIT: I should point out that this is a similar problem in OCTH and it's because the code doesn't have a way to represent targets slowly dissapperaing from sight. You can either see a target (iSightRange less than or equal to sDistVis) or you can't (iSightRange greater then sDistVis).
EDIT2: Oh, and the reason iSightRange is coming up greater then the actual range is because of obstacles in your LOS.
[Updated on: Fri, 28 January 2011 00:57] by Moderator Report message to a moderator
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271634]
|
Fri, 28 January 2011 18:21
|
|
ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Well, I'd seperate aim_xxx_stance from aim_draw_cost, but like I said, they both are just multipliers and both multiply against the same base value (the weapons ubReadyTime). I suppose I could throw in a condition so that aim_draw_cost would reset itself to "1" whenever it was set to 0. But I really don't think that's what you're after.
And yes, PercentAim is not effected by aim_draw_cost because it has nothing to do with the handling subsystem. The "weapon handling characteristics" system uses only the following:
BASE_DRAW_COST
BASE_TWO_GUNS
BASE_ONE_HANDED
BASE_HEAVY_WEAPON
BASE_xxx_STANCE
>PercentHandling<
AIM_DRAW_COST
AIM_xxx_STANCE
AIM_TWO_GUNS
AIM_ONE_HANDED
AIM_HEAVY_WEAPON
>PercentHandling<
As should be self evident, "BASE_xxx" ini settings effect the iBaseModifier which is used the generate weapon stability (aka, CTH) when no aim clicks are applied. And "AIM_xxx" ini settings effect the iAimModifier which is used to calculate your "maxAim" weapon stability (aka, CTH). The PercentHandling tag from Items.xml applies to both of those equations. And yes, this does mean that if you turn off aim_draw_cost, you remove the handling penalty for dual weilding (makes everyone ambidextrous, basically), for firing weapons one handed, and for heavy weapons. There really isn't a way to seperate any of these, however, because they are all multipliers to the weapons base handling characteristics. Which, as I've already said, is based on the weapons ubReadyCost.
Report message to a moderator
|
|
|
|
|
|
|
|
Re: HAM 4.0 Alpha Testing Thread[message #271743]
|
Sat, 29 January 2011 11:46
|
|
Alex_SPB |
|
Messages:169
Registered:February 2008 Location: Russia, St.Petersburg |
|
|
ChrisLWell, I'd seperate aim_xxx_stance from aim_draw_cost, but like I said, they both are just multipliers and both multiply against the same base value (the weapons ubReadyTime). I suppose I could throw in a condition so that aim_draw_cost would reset itself to "1" whenever it was set to 0. But I really don't think that's what you're after.
I suppose I have found a good solution for this problem without the need of reseting aim_draw_cost to 1
ChrisL
And yes, this does mean that if you turn off aim_draw_cost, you remove the handling penalty for dual weilding (makes everyone ambidextrous, basically), for firing weapons one handed, and for heavy weapons. There really isn't a way to seperate any of these, however, because they are all multipliers to the weapons base handling characteristics. Which, as I've already said, is based on the weapons ubReadyCost.
There is the way: let us alter the aim_draw_cost multiplier the following way:
New_aim_fraw_cost = Old_aim_drow_cost+x
If I like the way NCTH behaves currently i just set x to 0 and nothing changes at all. If I like the Effect Headrock proposed (when heavy weapon is more difficult to aim) but I like to minimize this effect I decrease Old_aim_drow_cost and set X higher then 0.
If I like to completely remove the effect I just set Old_aim_drow_cost to 0 and increase X.
X would be very convenient for general accuracy tuning as it will allow us to make the system more accurate or less accurate without changing the balance of the weapons (which does not happen currently if I change aim_draw_cost). For example if I decide now to make firing from prone stance more efficient by tuning aim_prone_stance I will alter the relative balance between weapons as I will make heavy weapons less accurate then light ones (i mean UB_ready_time by weight). X will solve the problem described above.
The another argument: if a moder decides to alter ready times the aiming system will not screw up because x would help to restore the old aiming balance
[Updated on: Sat, 29 January 2011 11:51] by Moderator Report message to a moderator
|
Staff Sergeant
|
|
|
|
Goto Forum:
Current Time: Wed Apr 17 23:41:04 GMT+3 2024
Total time taken to generate the page: 0.02786 seconds
|