Ah, yes, the ROF issues, I got a dev's response, and it was that the animation is FPS based, but the ROF numbers are correct in the balance.txt.
[snapback]37447[/snapback]
I'd think that I've played long enough to know that the animation is synchonized with the attacks. It would be pretty obvious if it wasn't. In any case, though, I tested, on an internet server, the time to kill a structure at different framerates.
The results, with framerate (FPS) in the first column and time (seconds) in the second:
adren bite vs RT
20 - 32.1
22 - 32.8
40 - 33.5
100 - 32.7
HMG vs movement chamber
20 - 5.4
22 - 9.7
31 - 6.8
35 - 5.9
40 - 7.9
50 - 6.4
75 - 6.3
100 - 6.0
The difference is much greater in the weapon with a high rate of fire, thus indicating that the rate of fire differences are due to small rounding errors.
but the ROF numbers are correct in the balance.txt.
Even disregarding the effect of framerate changes, the numbers in Balance.txt are far from correct.
Example:
Balance.txt gives the rate of fire of bitegun as 0.80. Assuming this is in seconds, the bitegun should attack 1.25 times per second.
A marine resource tower has 6000 health. A skulk bite does 75 damage. That means that the RT takes 80 skulk bites.
The average amount of time to kill the RT as a skulk in the above tests was 32.8. Thus, 79 skulk bites take 32.8 seconds (the first bite can be disregarded because it is instant). Divide by 32.8, and we get approximately 2.4 skulk bites per second, or 1 bite every .42 seconds, approximately. This is far from the value given in Balance.txt.
Your numbers fluctuate heavily, though, so what exactly do you deduce from them?
...
There's no recognizable pattern really. The numbers go up and down seemingly at random. What does this mean, other than that NS behaves weirdly?
[snapback]37595[/snapback]
I think this is because of rounding numbers up or down done by NS, but that's just a random guess.
Rounding errors, most likely. If I were to test every FPS setting, I'd likely find a pattern similar to the one described here (http://www.fortress-forever.com/fpsreport/) (scroll down).
[snapback]37624[/snapback]
So essentially, to get an accurate average we need pretty much need to do exactly that, test at ever FPS...
Yay for making things easier!
There isn't much need for such extreme precision in the manual. All that is needed are values that are reasonably accurate, as opposed to the approximately 0.52 factor inaccuracy of the current values.
[snapback]37842[/snapback]
I really do appreciate the work done here civ, I'll try and get a dev's word on it, or you will, or soemthing, when NS site goes back up.