Fixing the client FPS effect of fire rate?

the_x5

<div class="IPBDescription">Is there are way? Will NS2 implement it?</div>Recent bug reports thread reminded me of this.

First, <a href="http://www.fortress-forever.com/fpsreport/" target="_blank">READ THIS COMPLETELY BEFORE REPLYING</a>

Second, let's dicuss possibles way to fix that. As he said, "10% quicker rate [in reference to the difference between 60 and 100 fps] of fire could let you fire off that final bullet that kills somebody before they kill you. It's not a huge advantage but it certainly isn't negligable." So, any ideas?

Third, if a good idea is proposed let's weigh pro's and con's and get a reply from Max on the feasibility of seeing it implemented in NS2.


PS: Please don't forget the "[code]" tags if your plan to insert C++ or Lua source code.

J!

When was that written? I recall reading something like this years ago, only to discover that the issue had been fixed and guns only appeared to fire faster from the client's perspective, but the server kept tabs on the correct ROF.

Also, is this even an issue in Source?

Max

I'm not really up-to-date on all of the issues in Half-Life 1, but in NS2 we're not going to have any dependency on frame rate like that (unless we screw up!)

Rokiyo

EDIT: Interesting.... Took another look at that article... That's the opposite of the 1.04 issue... Not sure what's going on there.

There was a similar issue that was fixed when NS 2.0 was released: The one that caused JP/HMG combos to be so devestating in 1.04: At 100fps your jetpack refilled faster than it could be emptied.

the_x5

<!--quoteo(post=1627918:date=May 20 2007, 12:13 AM:name=Max)--><div class='quotetop'>QUOTE(Max @ May 20 2007, 12:13 AM) [snapback]1627918[/snapback]</div><div class='quotemain'><!--quotec-->I'm not really up-to-date on all of the issues in Half-Life 1, but in NS2 we're not going to have any dependency on frame rate like that (unless we screw up!)
<!--QuoteEnd--></div><!--QuoteEEnd-->

Interesting, I wonder what Valve fixed then when they made Source. Or why the HL engine had that oddity? What exactly are the clients sending to the server then? <img src="style_emoticons/<#EMO_DIR#>/confused-fix.gif" style="vertical-align:middle" emoid="???" border="0" alt="confused-fix.gif" />

schkorpio

<!--quoteo(post=1627961:date=May 20 2007, 06:35 PM:name=the_x5)--><div class='quotetop'>QUOTE(the_x5 @ May 20 2007, 06:35 PM) [snapback]1627961[/snapback]</div><div class='quotemain'><!--quotec-->
Interesting, I wonder what Valve fixed then when they made Source. Or why the HL engine had that oddity? What exactly are the clients sending to the server then? <img src="style_emoticons/<#EMO_DIR#>/confused-fix.gif" style="vertical-align:middle" emoid="???" border="0" alt="confused-fix.gif" />
<!--QuoteEnd--></div><!--QuoteEEnd-->

It seems to be an ID software thing (remember HL1 was modified quake engine) I know that quake 4 and doom 3 both had their frames capped at 60fps for the exact reasons as explained in the 1st post. And quake 3 had some really strange bugs or exploits - there was a sweet spot for setting your max_fps - on my machine if i set it max_fps to about 113 i could strafe jump 50% further and about 20% higher.

the_x5

So source doesn't have these bugs which can be exploited you're saying? It's immune?

Max

I believe there is a bug in the code in that article which can account for those results. Because the firing code is only invoked at most once per frame at a specific point in the frame, the updates won't always happen at exactly the interval specified in the code (in this case 0.15s). The slower the frame rate, the larger the discrepancy can be between the desired interval and the actual interval, with the maximum discrepancy being the time between frames (0.05s at 20 FPS).

The way this code is written, the error (i.e. the discrepancy between the desired rate and the actual rate) will continue to accumulate every time the update is invoked. To correct this, the update interval should be adjusted each time to keep the average error equal to 0. For example, if the interval between the last two updates was 0.20s, instead of invoking the next update in 0.15s, you'd schedule it for 0.10s. The average of those two updates would then be the desired 0.15s.

This is how I think the code should be written:

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->const float desiredAttackRate = 0.15;
m_flNextPrimaryAttack = desiredAttackRate - (timeSinceLastShot - desiredAttackRate);
<!--c2--></div><!--ec2-->
This is why you see the dots in the graph become less scattered as the frame rate increases. At 50 bullets per clip you'll accumulate up to 2.5s of error at 20 FPS (50 * 1/20), which is about the spread you see in the low end of the graph. At 100 FPS you only get 0.5s of error (50 * 1/100) which again is what you see on the high end.

Max

Faskalia

<!--quoteo(post=1628309:date=May 21 2007, 06:38 PM:name=Max)--><div class='quotetop'>QUOTE(Max @ May 21 2007, 06:38 PM) [snapback]1628309[/snapback]</div><div class='quotemain'><!--quotec-->
post
<!--QuoteEnd--></div><!--QuoteEEnd-->

Do you have enough control over the source engine to allow for a fix of this issue?

I am especially thinking of server client interaction, simply because the number of frames that a server can calculate has always had a huge impact on the client side. This has also been quite an issue with TFC in the beginning. When lots of nade spam dropped the server to its knees HWGs were out of the sudden 20% stronger as usual <img src="style_emoticons/<#EMO_DIR#>/tounge.gif" style="vertical-align:middle" emoid=":p" border="0" alt="tounge.gif" /> and having such things like ROF independant from server and/or client control would provide a more constant gaming experience.

a_civilian

About the notion that this is only client-side (or a result of faulty code), I've tested firing rate and movement speed (by all three of stopwatch, HL script, and macro) on internet dedicated NS servers and am quite certain they are affected by framerate. No idea whether this problem exists in the Source engine though.

Max

This isn't part of the engine code, it's actually the game code. So the correct question to ask is whether it's part of Half-Life 2, Counter-Strike: Source, etc., not whether it's part of the Source engine. I don't know the answer to those questions, but I can say that we're going to strive to eliminate any dependency on the frame rate in NS2.

In regards to how much flexibility we have in changing things in the Source engine: the great thing about making NS2 a full commercial game is that we get access to the all of the engine code. This is the most helpful when trying to figure out why something isn't working, but we've also had some occasions so far to make tweaks or fixes in the engine code. We're not planning on making big changes to the engine, but if we need to we can.

Max