Thursday, April 12, 2012

[FA] Calculating unit DPS

[:1]Everyone knows about supcomdb, but its problem that while we are having updates on FA (yes, I'm speaking of 3603 and FAF) it isn't.
So for the past few days I've been working on creating the actual one.
To the date, almost all scriping is done yet I have troubles calculating unit's DPS. So I'm looking for your help if possible, because I don't have any time to work it around at the moment :(
The formula (for projectile, missile and torpedo weapon):
if (MuzzleDelay == 0) {
Projectiles = MuzzleCount;
if (RackFireTogether == "true")
Projectiles = Projectiles * RackCount;
} else {
Projectiles = MuzzleSize;
};
dps = (WeaponDamage * Projectiles * DoTPulses) * ((1/round(1/RateOfFire)))

I've spent 2 days on figuring it out and very close to the right solution, but it works wrong with such weapons like Mongoose Gatling Plasma Cannon and Atlantis Flayer SAM Launcher
The thing is fire cycle, for those its not just RateOfFire itself, but there is something else that affects. E.g., Flayer SAM Launcher has fire cycle of 2 seconds, but RateOfFire is only 1 and thus I get doubled DPS.
My guessing is it has something to do with values like RackSalvoChargeTime or RackSalvoReloadTime, but it's not clear at the first sight and I'm already clueless here.
So at the end, the problem is how to properly calculate fire cycle.
Thank you :)|||You don't have to worry about firing delays. They only count for alpha-strike damage (which isn't what you're after).
Just find the total damage per salvo, and divide that by the reload time. The total damage per salvo is nothing more than the damage per projectile times the number of projectiles.|||I made a bigass post about calculating weapon damage a while back, that takes into account all aspects of weapon code, timing issues (including the tendency of WaitSeconds and WaitTicks to skip one tick). Try using google to search the forums for 'weapon dps mithy' or something like that.
Edit: Found these two, both fairly comprehensive--
viewtopic.php?f=19&t=40515&start=0
viewtopic.php?f=19&t=40453&start=0
..however, neither mention the tick-dropping issues, which I seem to remember being an issue with any unit that relies on its RackSalvo or MuzzleSalvo settings for its max ROF. In a nutshell, this issue typically results in one tick (0.1s) of any wait greater than a single tick being dropped off. So with a MuzzleSalvoDelay of 0.2, it will only wait 0.1s, likewise only 0.2s of a specified 0.3s wait.
My memory of this is getting a bit fuzzy as I haven't used this information in a while, but I'm pretty sure the lua WaitSeconds method always rounds DOWN, so a MuzzleSalvoDelay of e.g. 0.39 will always result in a coroutine.wait of 3 ticks, with one of those ticks being dropped, resulting in 0.2s between salvo shots. Whether or not this actually affects the unit's firing cycle and thus DPS over time depends on whether or not the modified total lua-based timer length (MuzzleSalvoDelay*MuzzleSalvoSize, added to RackSalvoReloadTime and RackSalvoChargeTime) exceeds 1/RateOfFire.|||Actually I've already got it working, and it was giving the results exactly like the original DB
After some brainstorming I've come up with this formula:
if ($weapon["RateOfFire"] != 1) {
$FireCycle = round(1/$weapon["RateOfFire"], 1);
} elseif ($weapon["RackSalvoReloadTime"] != 1 AND $weapon ["RackSalvoReloadTime"] != 0) {
$FireCycle = round(1/$weapon["RackSalvoReloadTime"], 1);
} else {
$SalvoDelay = $weapon["MuzzleSalvoDelay"] == 0 ? 0 : $weapon["MuzzleSalvoDelay"] - 0.1;
$FireCycle = $weapon["RackSalvoChargeTime"] + ($weapon["MuzzleSalvoSize"] * $SalvoDelay) + $weapon["RateOfFire"];
PS link for working DB: http://88.191.143.136/faforever/unitsDB/
};|||That looks close, and may be good enough for the stock units, but technically you should be using the greater of:
RackSalvoReloadTime + RackSalvoChargeTime + ((MuzzleSalvoDelay if greater than 0 - (0.1 if greater than 0.1)) * MuzzleSalvoSize)
or:
1/RateOfFire
..rounded to the nearest tenth of a second, to determine total firing cycle time.

No comments:

Post a Comment