Home » PLAYER'S HQ 1.13 » JA2 Complete Mods & Sequels » UC/DL 1.13 & AFS » NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)
| NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290175]
|
Thu, 01 September 2011 00:35 
|
|
| Wil473 |
 |
Messages:2813
Registered:September 2004
Location: Canada |
|
|
I believe I am not alone in wanting a clean sheet discussion of what the current NCTH tags do, and perhaps some insight into the mechanics. The development threads are useful, but their size and detail (not to mention long abandoned ideas) seem to be obscuring the key points useful to using NCTH as we know it today. Quite frankly, I am looking for authoritative answers, so by all means ask questions, but please allow those that actually worked on the NCTH implementation to answer.
Using this particular sub-forum as:
1) I have moderator rights over it - yes, this is a warning, the subject of this thread are existing NCTH tags and mechanics
2) Information gathered here will feed back into my Alrulco Folding Stock / Deidranna Lives!-1.13 / Urban Chaos-1.13 projects
2a) I do intend on being able to quickly turnaround any discussions into releases to test concepts that may address the NCTH balance issues
3) If successful, I may even help with implementation in stock v1.13
For the last little while, I have been compiling the pop-up hints from UDB (in-game Description Boxes). This was done by picking a low item index gun and filling in dummy values so the NCTH Tags were in use. Now weapons and attachments have slightly different descriptions, but in either case the same basic information should be conveyed / be true. For a few of them, I have listed the attachment's description of the tag's function.
Each Tag is listed in the format of: "XML Editor v0.57 Label" / "in-game UDB Label" I've also listed some immediate concerns about the descriptions in italics.
WEAPONS.XML
NCTH Accuracy / Accuracy
Determines whether bullets fired by
this gun will stray far from where
it is pointed.
Scale: 0-100
Higher is Better
Recoil X / Lateral Recoil
The distance this weapon's muzzle will
shift horizontally between each and every bullet in a
burst or autofire volley.
Positive numbers indicate shifting to the right.
Negative numbers indicate shifting to the left.
Closer to 0 is better.
Recoil Y / Vertical Recoil
The distance this weapon's muzzle will shift
vertically between each and every bullet in a
burst or autofire volley.
Positive numbers indicate shifting upwards
Negative numbers indicate shifting downwards
Closer to 0 is better
Default Aim Levles / Allowed Aiming Levels - spelling mistake present in XML Editor v0.57
This is the number of Extra Aiming
Levels you can add when aiming this gun.
The FEWER aiming levels are allowed, the MORE
bonus each aiming level gives you. Therefore,
having FEWER levels makes the gun faster to aim,
without making it any less accurate.
Lower is better.
Recoil Delay / ???
does not appear in UDB
Weapon Handling/ ???
does not appear in UDB
ITEMS.XML
Scope Mag Factor / Scope Magnification Factor
When greater than 1.0, will proportionally reduce
aiming errors at a distance.
Remember that high scope magnification is detrimental
when the target is too close!
A value of 1.0 means no scope is installed.
Laser Projection Factor / Projection Factor
Proportionally reduces aiming errors at a distance.
This effect works up to a given distance,
then begins to dissipate and eventually
disappears at sufficient range.
Recoil X Modifier / Lateral Recoil Modifier
UDB Advance for Attachment:
When attached to a ranged weapon capable
of Burst or Autofire modes, this item modifies
the weapon's Horizontal Recoil
by the listed percentage.
Reducing recoil makes it easier to keep the gun's
muzzle pointed at the target during a volley.
Lower is better
- Shouldn't this be "amount" instead of "percentage?"
UDB Advance for Weapon:
This weapon's horizontal recoil strength is being
modified by its ammo, attachments, or inherent
abilities.
This has no effect if the weapon lacks both
Burst and Auto-Fire modes.
Reducing recoil makes it easier to keep the gun's
muzzle pointed at the target during a volley.
Lower is better
Recoil Y Modifier / Vertical Recoil Modifier
UDB Advance for Attachment:
When attached to a ranged weapon capable
of Burst or Autofire modes, this item modifies
the weapon's Vertical Recoil
by the listed percentage.
Reducing recoil makes it easier to keep the gun's
muzzle pointed at the target during a volley.
Lower is better
- Shouldn't this be "amount" instead of "percentage?"
UDB Advance for Weapon:
This weapon's vertical recoil strength is being
modified by its ammo, attachments, or inherent
abilities.
This has no effect if the weapon lacks both
Burst and Auto-Fire modes.
Reducing recoil makes it easier to keep the gun's
muzzle pointed at the target during a volley.
Lower is better
Recoil Modifier / ???
No description found in UDB, but results are visible in the Advance tab of the UDB for the modified weapon.
Accuracy Modifier
This weapon's accuracy is being modified by
an ammo, attachment, or built-in attributes.
Increased accuracy allows the gun to hit targets
at longer ranges more often, assuming it is
also well-aimed.
Scale: -100 to +100
Higher is better.
- In the modified weapon's General tab, the displayed modification does not seem to equal the expected results from this tag if it was a straightforward percentage.
ie. -5% accuracy on a weapon with 38 NCTH Accuracy should be -1.9, but instead shows up as a -3 modification in UDB.
ITEMS.XML - Differentiated by Stance
Flat Base / ???
Appears in advance tab, but no pop-up description
Percent Base / Percent Snapshot Modifier
This weapon modifiers its shooter's accuracy
with ANY shot by the listed percentage
based on the shooter's original accuracy.
Higher is better
Flat Aim / Flat Aiming Modifier
This weapon modifies the amount of accuracy
gained from each extra aiming level you
pay for by the listed amount.
Scale: -100 to +100
Higher is better
Percent Cap / Aiming Cap Modifier
This weapon modifies the shooter's maximum
accuracy, as a percentage of the shooter's original
maximum accuracy.
Higher is better.
Percent Handling / Gun Handling Modifier
This weapon's attachments or inherent abilities
modify the weapon's Handling difficulty.
Better handling makes the gun more accurate to fire,
with or without extra aiming.
Note that this is based on the gun's original
Gun Handling factor, which is higher for rifles and
heavy weapons, and lower for pistols and small
weapons.
Lower is better.
Percent Tracking / Target Tracking Modifier
This weapon's ability to hit moving targets
at a distance is being modified by attachments
or the weapon's inherent abilities.
A high bonus here can help hitting
fast-moving targets, even at a distance.
Higher is better
Percent Drop Com / Drop Compensation Modifier
This weapon's ability to compensate for shots
beyond its maximum range is being modified by
attachments or the weapon's inherent abilities.
A high bonus here can increase a weapon's
natural Maximum Range by at least a few tiles.
Higher is better.
Percent Max CF / Maximum Counter-Force Modifier
This weapon modifies the shooter's ability to
cope with recoil during Burst or Autofire volleys,
due to its attachments, ammo, or inherent abilities.
When high, this can help a shooter to control
guns with powerful recoil, even if the shooter
has low Strength.
Higher is better
Percent CF Accuracy / Counter-Force Accuracy Modifier
This weapon modifies the shooter's ability to
accurately apply counter-force against its
recoil, due to its attachments, ammo, or inherent abilities.
Naturally, this has no effect if the weapon lacks
both Burst and Auto-Fire modes.
A high bonus helps the shooter bring the gun's muzzle
precisely towards the target. Even at longer ranges
making volleys more accurate as a result.
Higher is better.
Percent CF Frequency / Counter-Force Frequency Modifier
This weapon modifies the shooter's ability to
frequently reasses how much counter-force they
need to apply against a gun's recoil due to its
attachments, ammo, or inherent abilities.
Naturally, this has no effect if the weapon lacks
both Burst and Auto-fire modes.
Higher frequency makes volleys more accurate on the whole,
and also makes longer volleys more accurate assuming
the shooter can overcome recoil correctly.
Higher is better
AimLevel Modifier / Allowed Aiming Levels Modifier
UDB for Attachment:
This item modifies the number of extra aiming
levels this gun can take.
Reducing the number of allowed aiming levels
means that each level adds proportionally
more accuracy to the shot.
Therefore, the FEWER aiming levels are allowed,
the faster you can aim this gun, without losing
accuracy!
Lower is better.
UDB for Weapon:
The number of Extra Aiming Levels allowed for this gun has been modified by its ammo,
attachments, or built-in attributes.
If the number of levels is being reduced, the gun is
faster to aim without being any less accurate.
Conversely, if the number of levels is increased,
the gun becomes slower to aim without being more accurate.
Lower is better [Updated on: Thu, 01 September 2011 00:43] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290214]
|
Thu, 01 September 2011 18:22 
|
|
| Wil473 |
|
Messages:2813
Registered:September 2004
Location: Canada |
|
|
I don't have to imagine anything, hi-end suppressors (not to mention dedicated muzzle brakes) in my mods do reduce the recoil (climb, movement, sway?) along either/or X and Y axis. The values for these two tags are simply added or subtracted from the weapon's inherent X and Y recoil.
ie. AK-74 recoil (X ,Y) = 3,9
AK-74 + Premium Intermediate Cartridge Suppressor = (3,9) + (0,-1) = 3,8
AK-74 + AK Muzzle Brake = (3,9) + (-1,-2) = 2,7
Basically I was highlighting what looked like an incorrect label, but as I said, I'll await someone involved with the current NCTH implementation address this one.
[Updated on: Thu, 01 September 2011 18:23] by Moderator Report message to a moderator
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290218]
|
Thu, 01 September 2011 18:35
|
|
 ctiberious |
 |
Messages:605
Registered:March 2007 |
|
|
Recoil Delay is a special Recoil value. I can't remember if it's part of UDB or not, but you can check by looking at either of the two weapons that actually use it: G11 and AN-94
The point of this tag is to represent weapons that can fire off multiple rounds BEFORE the shooter actually feels the recoil. Take the G11 as an example. It is designed so that a 3 round burst will be fired before the shooter is effected by recoil. So the code 'ignore' recoil until after the 3rd round is fired. This doesn't mean that the recoil is completely ignored. It's simply not calculated until more then 3 rounds are fired in a single volley. Therefore, in burst mode the G11 effectively has no recoil. While in autofire mode, you won't be hit with recoil until calculating the offset for the 4th round in the volley.
If it really isn't part of UDB, I'll add that to my todo list. When I took over NCTH from Headrock, I didn't spend alot of time on the UDB side of it. He said it was all working as intended so I focused on the NCTH system itself.
Weapon handling is used by the NCTH calculation to modify hit chances based on how cumbersome a weapon is. The idea here is that small, light weight weapons will be easier to control and 'stabilize' then large, heavy weapons.
Originally, NCTH didn't have a Handling tag. Instead, it used the ubReadyTime to determine the handling modifier. I added the Handling tag to give modders more control over weapon handling and to resolve a problem where ubReadyTime=0 weapons were getting no handling modifiers at all. I never got around to adding information for this tag to the UDB interface. I'll add that to my todo list.
Yes, both the Recoil X Modifier and Recoil Y Modifier are flat modifiers. Not percents.
EDIT: Cell makes a good point. These modifiers probaby >should< be percent values, but they currently aren't. Right now if you want to percent recoil adjustment, you have to use the 'PercentRecoilModifier' tag and it will effect both RecoilX and RecoilY results equally (i.e., PercentRecoilModifier=10 will increase both RecoilX and RecoilY by 10%).
"Recoil Modifier / ???", do you mean 'PercentRecoilModifier'? Not sure why that one isn't in UDB.
EDIT: FYI, since RecoilX and RecoilY are integer values, and the code sucks at rounding in most cases, you may well need fairly high percentages to actually see a change. For instance, currently the M16A1 has RecoilX=0, RecoilY=6. If you attach something that has PercentRecoilModifier=10, the net result will likely be "RecoilX=0, RecoilY=6". In other words, no change at all. On the other hand, the AK-47 currently have RecoilX=4, RecoilY=11 so this same PercentRecoilModifier=10 will result in "RecoilX=4, RecoilY=12". Please understand that this is not a fault in the code but a fault in the current RecoilX/Y values that we have in place. The current RecoilX/Y values are the PRIMARY reason that the NCTH recoil system is out of balance. Once these base RecoilX/Y values have been updated for all weapons (still working out a recoil equation that I can logically compare with the existing CFM equation), then I'll come back to the PercentRecoilModifier tag to see if adjustments need to be made in the way it is handled.
PercentAccuracyModifier is a combination of the weapon, ammo and any attachments. Also, the status of the weapon and attachments effects the resulting modifier. That said, the function returns an INT32 value, and all the calculations in the function do straight forward Integer based math. Very likely the problem is simply that we should be doing float math in the function and then returning a interger value that is rounded nearest.
Flat Base is basically the same as Percent Base only it gives a flat adjustment instead of a percentage adjustment. There is a description in the code for this tag so I'm not sure why it's not being displayed.
'Percent CF Frequency / Counter-Force Frequency Modifier': I should point out that at this time, this tag isn't really doing anything. Originally NCTH used an equation to calculation CFF but we kept getting results of 1 for any merc with even a modest amount of training and both Headrock & I felt that being able to adjust recoil compensation on every round (especially for high RoF weapons) was wrong. Currently the CFF calculation is based solely on bAutofireShotsPerFiveAP. This will eventually change once more of the recoil balance issues have been dealt with.
[Updated on: Thu, 01 September 2011 18:43] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290226]
|
Thu, 01 September 2011 20:39
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
Scope Mag Factor is simply the scopes mag factor. A 4x scope would have a Scope Mag Factore of 4.0. A 10x scope would be 10.0. *shrug* The real trick is how scope mage factor is used to calculate shooting aperture size and "too close" penalties.
When the aperture is created, we start off with a baseAperture which equals:
( (DEGREES_MAXIMUM_APERTURE * RADIANS_IN_CIRCLE) / 360 ) * NORMAL_SHOOTING_DISTANCE
DEGREES_MAXIMUM_APERTURE is an adjustable constant found in CTHConstants.ini
RADIANS_IN_CIRCLE is a hard coded constant set to 6.283
NORMAL_SHOOTING_DISTANCE is an adjustable constant found in CTHConstants.ini
The baseAperture is never displayed anywhere. It's strictly an internal calculation.
Next, we calculate the distanceAperture which equals:
baseAperture * (DISTANCE / NORMAL_SHOOTING_DISTANCE)
DISTANCE is the actual number of cells between the shooter and the target. Effectively this is the range in meters between the shooter and the target.
distanceAperture is the large aperture displayed on the NCTH cursor.
Next, we calculate the maxAperture which equals:
distanceApterture / magFactor
For scopes, magFactor is the ScopeMagFactor. For laser sights, magFactor is the ProjectionFactor.
maxAperture is never displayed anywhere. It's strictly an internal calculation.
Finally we calculate the shootingAperture which equals:
(maxAperture * 'accuracy') / 100
'accuracy' is the NCTH "muzzle sway" calculation and we divide by 100 ("/ 100") so that muzzle sway represents a percentage modifier.
'accuracy' also includes the weapons nAccuracy. For the displayed cursor, this is always the "worst case" potential of the nAccuracy score. For the actual "to-hit" calculation, though, a specific deviation, which is based on nAccuracy, is genereted for each round fired.
shootingAperture is the small aperture that displays on the NCTH cursor.
As for the "too close" penalty, that is also based partially on mag factor using the following:
ScopeMagFactor * NORMAL_SHOOTING_DISTANCE * SCOPE_RANGE_MULTIPLIER
SCOPE_RANGE_MULTIPLIER is an adjustable constant found in CTHConstants.ini. It is further adjusted in the code by -0.05 based on certain traits. For example, if you have a level of the Sniper trait and you're using a high power scope, the SCOPE_RANGE_MULTIPLE will be reduced by 0.05. This is a static reduction, not a percent. So if the base were 0.7, the above example would result in a 0.65.
The result is a minimum range that a scope can be used without penalty. For every cell within that minimum range, the "muzzle stability" calculation gets penalized by an amount based on AIM_TOO_CLOSE_SCOPE and ScopeMagFactor. Therefore, a 2x scope used within it's minimum range (which based on defaults is about 98 cells or 9.8 tiles) won't get much of a penalty while a 10x scope used within it's minimum range (490 cells or 49 tiles) will get a fairly large penalty.
The actual penalty is ultimatly based on how close the target is but the basic calculation is:
AIM_TOO_CLOSE_SCOPE * (ScopeMagFactor / 2)
AIM_TOO_CLOSE_SCOPE is an adjustable constant found in CTHConstants.ini
Report message to a moderator
|
|
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290230]
|
Thu, 01 September 2011 21:39
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
@Tango: Unfortunately, the system can't do variable RoF. So it's either we "negate" recoil in burst but give a "bonus" in full auto, or lose the recoil bonus in burst mode.
NORMAL_SHOOTING_DISTANCE is actually used in alot of placed in the NCTH code. Since so many of the NCTH values are based on a "distance ratio", there has to be some 1:1 ratio built into the code. Headrock used a value of 70 (or 7 tiles) to get this 1:1 ratio. The best way I can put it is, NORMAL_SHOOTING_DISTANCE is the range at which iron sights reach maximum effect. Shooting within this range doesn't incur a penalty while shooting beyond this range, it's harder to see the target and therefore harder to aim at the target. If you increase NORMAL_SHOOTING_DISTANCE, you make all the distance ratio calculations smaller which will result in longer ranged shots have higher effective hit chances.
Something else I should mention about SCOPE_RANGE_MULTIPLIER. The "default" in the current CTHConstants.ini is 0.7 but that's simply the multipler I originally generated when I was working with the NCTH scope stuff. Originally there was no multiplier so a 10x scope would get a "too close" penalty within 70 tiles. I didn't agree with this since it meant that 7x and 10x scopes were ALWAYS penalized in some way: either you were shooting too close or you couldn't actually see the target... and sometimes you'd get hit with both penalties. So I introduced the multiplier so that Headrock's intention would still exist while allowing the minimum range to be reduced to a point where it was at least possible to use a high powered scope without penalty.
That said, 0.7 was basically just my "first try". It worked in my initial testing, it (more or less) appeased Headrock, and so it was included in NCTH when the project was released. Since then I've run alot of tests using a value of 0.5 which I actually prefer. It results in a shorter minimum range, giving all scopes a larger useful range, but also results in greater "per tile" penalties when shooting too close.
Whether you use 0.7 (49tile effective 10x range) or 0.5 (35tile effective 10x range), the maximum "too close" penalty is the same: -20. The difference is that with a 0.7 multiplier, that -20 is spread over 49 tiles (so effectively -.4/tile) while a 0.5 multiplier has the penalty applied over only 35 tiles (so effectively -.6/tile).
Report message to a moderator
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #290405]
|
Wed, 07 September 2011 00:12
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
PercentCap only increases or decreases the upCap portion of the NCTH muzzle stability calculation. uiCap represents the maximum stability a particular merc can attain assuming perfect conditions and is based on the merc's Lvl, MRK, WIS and DEX, with MRK being weighted 3:1, DEX weighted 2:1 and LVL & WIS both weighted 1:1 (by default). PercentCap is used to modify this cap value. uiCap is then forced to fall within the valid 0-ubMaximumCTH limits. So if you have a uiCap of 97 without a PercentCap modifier, and you're using something that has a PercentCap=10, you end up with a uiCap of 99 (by default). uiCap is them put through further equations to determine the actual maxAim score possible.
As an example, my test merc gets a uiCap of 97 and ends up with a maxAim of 83. The 14 point difference is a result of various factors. If I modify the weapon so that it has PercentCap=10, my merc's uiCap only increases to 99 (ubMaximumCTH) which results in a maxAim of 85.
Now, I do see a bug if you use a negative PercentCap, which is supposed to be absolutely plausible. The uiCap value is a UIN32 value and we use the following equation to include the PercentCap modifier:
uiCap += (uiCap * GetPercentCapModifier( pInHand, gAnimControl[ pSoldier->usAnimState ].ubEndHeight )) / 100;
Because uiCap is an unsigned int, if 'GetPercentCapModifier' returns a -10, and my initial uiCap is 97, I end up with the following:
uiCap += (97 * -10) / 100;
uiCap += (4294966326) / 100;
uiCap += 42949663;
uiCap = 42949760;
Which will get reset to 99 because of ubMaximumCTH
Anyway, after fixing this bug with a simple variable recast, this same test merc ends up with a uiCap of 88 and maxAim of 75 when I set the weapon's PercentCap=-10.
uiCap += (INT32)(uiCap * GetPercentCapModifier( pInHand, gAnimControl[ pSoldier->usAnimState ].ubEndHeight )) / 100;
I'll commit this small fix to the release branch so it's available the next time a build is released.
EDIT: I fixed a similar issue with PercentTargetTrackingSpeed
[Updated on: Wed, 07 September 2011 00:18] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #292785]
|
Thu, 27 October 2011 11:04
|
|
| Strohmann |
 |
Messages:287
Registered:August 2011
Location: Division Thought Crimes |
|
|
what do you mean, that the tool tips don't explain the mechanisms correctly/comprehensive or that you don't understand the mechanisms themselfes?
if it's the latter:
imagine a circular coordinate system. in the middle is the target at 0;0. at the beginning of the shooting sequence the gun's muzzle point matches exactly with the target. now all additional bullets fired in a volley after the first one shift the gun's muzzle point away from the target, by moving it by flat x;y-values, for example recoil +2;+7 , in the coordinate system. now the muzzle point (2;7) and the target's location (0;0) don't match anymore, meaning missing the target. of course the shooter wants to reverse that, so he applies counterforce.
the ideal way would be to apply exactly -2;-7 to bring target and muzzle point in match again. but of course the shooter isn't a computer or something. so with a low counterforce-accuracy he applies for example -3;-4, so the muzzle points now at -1;3. still not 0;0, so has to try again and again and so forth. with a high counterforce accuracy the shooter approximates the ideal version -2;-7 and needs less time/steps to do so.
every shooter has a certain counterforce maximum, that's the cap the negative x;y-values can reach, for example 8. weapons with relativly low recoil, for example a 9x19mm submachine gun with recoil +1;+4 (both are lower than  is easy to overcome. but now an assault rifle chambered with 7.62x51mm with recoil +3;+12, that's a problem for him, he could only apply a theoretical maximum of -3;-8, that's not enough. no matter how accurate he could be, the recoil is simple too strong, he could never bring muzzle point and target in match again.
(all very simplified, for example ignoring prerecoil wisdom etc., but you should get the idea)
Report message to a moderator
|
Master Sergeant
|
|
|
|
| Re: NCTH Discussion on What Exactly We Have Right Now (as far as XML Tags)[message #293003]
|
Wed, 02 November 2011 16:51
|
|
| ctiberious |
|
Messages:605
Registered:March 2007 |
|
|
That was a pretty close explanation, Strohmann. The only thing you got wrong is that Max CounterForce is the maximum >combined< counterforce a merc can apply. If you have a CFM=8, then you can counter a maximum of 8 points of recoil. So if a weapon has +3x+12, it's said to have a "recoil factor" of 15. With CFM=8, you can reduce that "recoil factor" to no lower then 7 meaning you end up with something like +1.4x+5.6 remaining recoil.
I should also point out that if a weapon has a higher "recoil factor" then a shooters CFM, the CFM is applied to both X and Y recoil in the same ratio as the weapons actual recoil values. Hence why you end up with +1.4x+5.6 instead of 0x+7 or +3x+4. In your example, the weapon's RecoilX is 20% of it's total "recoil factor" so only 20% of the shooters CFM will be applied against RecoilX. This is only the case, however, when "recoil factor" is greater then CFM. If CFM is equal or greater then "recoil factor", then it's possible to negate all recoil, up to your mercs counterforce accuracy and the games built in minimum deviation.
Report message to a moderator
|
|
|
|
|
Goto Forum:
Current Time: Thu Jun 19 14:59:05 GMT+3 2025
Total time taken to generate the page: 0.00893 seconds
|
Blog
Search
Help
Members
Register
Login
Home
My pea brain has a hard time wrapping around numbers sometimes. 
