banana
True Banana
Zoro > Law
Posts: 1,577
|
Post by banana on Sept 15, 2019 11:14:05 GMT -5
What’s the overall rpm and how do you calc that
|
|
|
|
Post by Pegasus Actual on Sept 15, 2019 18:41:48 GMT -5
Well, depends on what you mean by 'overall RPM'. You're being vague and lazy here by not defining it.
Shot 1, there's no real firetime as there's no gap between bullets as you are only shooting one shot. So that's a divide by zero kind of situation.
Shot 2, you need the firetime from your RPM.. so 60/1200 and you end up with a 0.05s gap between shots. One firetime, so you just convert back, 60 / 0.05 and you're back to 1200RPM.
Shot 3, you get two gaps of your 0.05s firetime, so 0.1s divided by 2, and then convert back and bam, back to 1200RPM obviously. It should be pretty obvious that 1200RPM is your best case scenario.
Shot 4, it starts getting a little more interesting. You have a third gap, this time it's the burst delay (I'm assuming they don't stack an extra firetime on top of the burst delay but that's not something I actually know). So you have the 0.1s from before, plus 0.25s from the burst delay, to fire the fourth shot, but that is three gaps you are measuring. So your average firetime is (0.1s + 0.25s) / 3, or 0.116666666667 (the six is repeating infinitely of course). So if you take that number and convert it back to RPM by dividing 60 by it you get 514.29-ish. It turns out this is your worst case scenario
Shot 5, you just add another .05s to the pile, and average over 4 gaps.. so (0.1s + 0.25s + 0.05s) / 4 which works out to a nice 0.1s average and converted back you've rebounded to 600RPM
If you automate this process quick and dirty in PHP you get something like:
<?php
$burst_rpm = 1200;
$burst_delay = 0.250;
$fire_time = 60/ $burst_rpm;
for ($x = 2; $x <= 1000; $x++)
{
$total_time_component = intdiv($x - 1, 3) * ($burst_delay + 2 * $fire_time) + max((($x - 1) % 3),0) * $fire_time;
$effective_fire_time = $total_time_component / ($x - 1);
echo "Shot $x = ", round(60 / $effective_fire_time, 2) , "RPM<br>";
}
?>
Which for say a 40 round mag would output:
Shot 2 = 1200RPM
Shot 3 = 1200RPM
Shot 4 = 514.29RPM
Shot 5 = 600RPM
Shot 6 = 666.67RPM
Shot 7 = 514.29RPM
Shot 8 = 560RPM
Shot 9 = 600RPM
Shot 10 = 514.29RPM
Shot 11 = 545.45RPM
Shot 12 = 573.91RPM
Shot 13 = 514.29RPM
Shot 14 = 537.93RPM
Shot 15 = 560RPM
Shot 16 = 514.29RPM
Shot 17 = 533.33RPM
Shot 18 = 551.35RPM
Shot 19 = 514.29RPM
Shot 20 = 530.23RPM
Shot 21 = 545.45RPM
Shot 22 = 514.29RPM
Shot 23 = 528RPM
Shot 24 = 541.18RPM
Shot 25 = 514.29RPM
Shot 26 = 526.32RPM
Shot 27 = 537.93RPM
Shot 28 = 514.29RPM
Shot 29 = 525RPM
Shot 30 = 535.38RPM
Shot 31 = 514.29RPM
Shot 32 = 523.94RPM
Shot 33 = 533.33RPM
Shot 34 = 514.29RPM
Shot 35 = 523.08RPM
Shot 36 = 531.65RPM
Shot 37 = 514.29RPM
Shot 38 = 522.35RPM
Shot 39 = 530.23RPM
Shot 40 = 514.29RPM
So every burst delay you add to the pile hurts your effective fire rate, but the effect is biggest in the first burst and sharply declines over the following bursts. If you look at shot 39 you're already at 530-ish RPM which isn't far off the start-of-burst worst case scenario. If you look at the output far beyond that point you would see that the end of burst shots are clearly approaching that worst case scenario though that's not super relevant as after shot 40 you're looking at a reload anyway so who cares?
Is your overall RPM the worst case scenario of 514.29RPM because that's what you're worried about? Is it 514.29RPM because that's the value when you actually finish an extended mag which happens to also be the a worst-case start-of-burst shot? Or is it 535.38RPM because that's where you'd empty a regular mag on shot 30? Or is it 1200RPM because you're the man and you one bursted that fool? Or is it 600RPM because god dammit you always fire three bursts just to make sure?
Or is it something else entirely because I fucked up my logic or math somewhere? I *think* those numbers are right. At least, if I plug in 0.05s as the burst delay (to simulate a constant 1200RPM weapon) I get the expected 1200RPM result at all shot values.
|
|
|
|
Post by Marvel4 on Sept 18, 2019 11:44:02 GMT -5
I'm assuming they don't stack an extra firetime on top of the burst delay but that's not something I actually know Technically, there isn't an extra fire time. The burst delay doesn't replace the last fire time of a burst, it just... delays the next burst.  |
|
|
|
Post by Pegasus Actual on Sept 18, 2019 18:49:52 GMT -5
I'm assuming they don't stack an extra firetime on top of the burst delay but that's not something I actually know Technically, there isn't an extra fire time. The burst delay doesn't replace the last fire time of a burst, it just... delays the next burst. I'm not exactly sure what you're saying, I understand the difference between burst delay and fire time. But it's a question of how it's implemented. Logically you would think the 50ms firetime after shot 3 is just ignored, but I could see it coded in a way where the burst delay of 250ms doesn't start until after that 50ms fire time is applied giving you an effective 300ms burst delay and would of course throw my numbers off, it was just a disclaimer. |
|
|
|
Post by thexclusiveace on Sept 19, 2019 10:01:37 GMT -5
Technically, there isn't an extra fire time. The burst delay doesn't replace the last fire time of a burst, it just... delays the next burst. I'm not exactly sure what you're saying, I understand the difference between burst delay and fire time. But it's a question of how it's implemented. Logically you would think the 50ms firetime after shot 3 is just ignored, but I could see it coded in a way where the burst delay of 250ms doesn't start until after that 50ms fire time is applied giving you an effective 300ms burst delay and would of course throw my numbers off, it was just a disclaimer. The 50ms firetime after the 3rd shot is not ignored, it stacks with the burst delay when looking at total time between shot 3 and 4. |
|
exaltedvanguard
True Bro
Hey look... uh... Over... uh... THERE!
Posts: 10,226
|
Post by exaltedvanguard on Sept 19, 2019 11:20:44 GMT -5
So it's actually 300ms total time between shots 3 and 4. Good to know! Had no idea it worked that way - I guess I never bothered to check since I don't care much for burst weapons.
Also, I had no idea you were a member here (although it doesn't surprise me).
I actually had a question about your testing methodology. I know you calculate fire rates based on frame counting. Do you test multiple times and average the results?
But also, do you test multiple times using different number of rounds fired?
The reason to do so would be to remove some of the inaccuracies of frame rounding. If I'm watching the ammo counter and counting frames, and I see 0 and frame 60, it means I could have hit 0 ammo at "frame" 59.1. For high fire rate weapons, that can make a difference.
Firing different total amounts of ammo could potentially get you a more accurate reading.
Additionally, an alternate testing tool you may want to look into is the Titan two. It's a man in the middle between controller and console. It allows you to use your preferred controller on any console, but it also allows you to (somewhat nefariously) write code for things like rapid fire. I could see such a tool being very useful for hand testing. "I want to hold the trigger for exactly 1200ms." "I want to pull the trigger at a speed of exactly 400 times/min"
|
|
|
|
Post by Marvel4 on Sept 19, 2019 11:36:01 GMT -5
Logically you would think the 50ms firetime after shot 3 is just ignored It wouldn't be logical to ignore it. Otherwise a burst delay of 0 would allow you to fire faster than a fully automatic weapon with the same fire time. |
|
|
|
Post by Pegasus Actual on Sept 19, 2019 16:03:23 GMT -5
Logically you would think the 50ms firetime after shot 3 is just ignored It wouldn't be logical to ignore it. Otherwise a burst delay of 0 would allow you to fire faster than a fully automatic weapon with the same fire time. It comes down to how you're modeling it, and just from the variable names it's ambiguous. My initial interpretation of the term "burst delay" was time between the last bullet of a burst and the first bullet of the following burst. That's not at all unreasonable. It wouldn't make any sense to have a burst weapon with 0 burst delay in that model sure, but so what? Some values don't make sense in certain models. And if you were really worried about your edge case you could always just assert that burst delay is greater than or equal to firetime. The implementation doesn't really matter either way, you'd just use a 250ms or a 300ms burst delay to achieve the exact same thing. edit: And really the 0ms burst delay wouldn't even have the problem you pointed out from the model I was working from as the whole idea is they would execute in parallel so the firetime would still lock you out from shooting early. Which is also why I referred to a stacking firetime as 'extra'. |
|
