AQ2World.com

Dont know if you still look here r1ch, but the following issue: on siol aq2 server, some server hosted in slovenia, powered by r1q2, i dont have that strafejump bug, ive to mention that that is a windows hosted server, but would that be the difference?

Are you sure that server isn't capping the cl_maxfps without you noticing? As I mentioned before, the Pmove code that prevents strafe jumping is shared by both the client and the server, so no matter what client you use... if the server somehow "allowed" the 125+ FPS strafe jumping, you would notice prediction errors.

I even added a test cvar in the latest release of r1q2ded, sv_strafejump_hack, that prevents the server from ever capping strafe jumps in this way. It's very obvious when playing with a normal client when these prediction errors occur.

Tried some things today, im usually use nocheat 2.34.
Yesterday i tried r1q2 client version.. and i didnt have the strafejump bug. But that client totally fucked up all my settings and the gameplay, and a lot of features are missing, so thats no option.
So i thought, it might works too with nc 2.40, so tested that.. and it didnt. So i tested aprq2 too and also there it had the strafejump bug, even with asskickers cfg (he doesnt have the problem).

Just for info.

Same here.

I had this problem before, without r1q2 changed some cl_maxfps settings, and I have it less often now, though it still occasionally occurs. What's the relevance, I hear you say. Well, a bit off topic, but can someone explain to me why that bit of code is in every client? What would happen if you removed it?

The world as we know it would fall apart. All that will remain will be the underdevloped countries.

I just played with Stric on a linux build server, with r1q2.. and no strafejump bug. There wasnt a maxfps limit either. So i think, can the sollution be no maxfps limit?

atm, I only let q2admin cap the maxfps to 125... so, sv_fpsflood of r1q2 is off (instead of 125) at the moment (which is default in future versions though).

125fps is quite a torrent of network data when using current q2-clients (nc, aprq2, q2ace, whatever), which do not decouple the frames from the network.

Limiting to 125 is quite nice though, since before some time, ppl were still capping at 90 -- and some years before, even to 40.
And ... today, since ppl got used to exploit the physics bugs that appear with fps higher > 100 I began capping at "only" 125.

And this is the source of the problem now? Should my server cap at 150?

Try to set different cl_maxfps and check the cl_maxfps right after setting it. Perhaps the server caps it.

n99 wrote:I had this problem before, without r1q2 changed some cl_maxfps settings, and I have it less often now, though it still occasionally occurs. What's the relevance, I hear you say. Well, a bit off topic, but can someone explain to me why that bit of code is in every client? What would happen if you removed it?

If it was removed from every client, it would still need to be removed from every server. The client would think it can jump after landing but the server will ignore the move, thus you will suddenly be jerked back to ground after the prediction miss.

You can experiment with this using latest versions of r1q2. Set sv_strafejump_hack 1 to disable the code on the server, then try jumping as a client, you will notice sometimes it will jitter but your strafe jump continues - this is because you are sending a jump command, but your client doesn't think it will be allowed so it doesn't start predicting it, but in reality it is allowed so you suddenly find yourself in the air when the server updates you.

On the other side, there is cl_strafejump_hack which turns off the code in the client. You will get the opposite effect - the client will think it can jump when in reality the server will ignore the jump command and snap you back to the ground.

Only if both client cl_strafejump_hack 1 and server sv_strafejump_hack 1 are set will you get true unlimited strafe jumping without prediction errors. The best you can hope for now is to use R1Q2 server and set sv_strafejump_hack 1 and let old clients have the occasional hitch when they don't think a jump is allowed. Thus strafe jumps will be unlimited, but may occasionally feel a little jittery when the client prediction fails.

So, to clear things up.

There never was a strafejump bug in r1q2ded. The "bug" that Da^Juan described was a q2-physics problem when a player used some funny cl_maxfps settings.

The server on which the bug happened to Da^Juan was my server since I capped the maxfps on 125 (which is, considering the network, a lot) and Da^Juan using maxfps 150 normally.
Considering the combination that came out of this network settings then: cl_maxfps 125 and some rate-setting he stuck to the ground often.

So, after all, it was NO r1q2ded bug! It was a general q2-physics problem when using a maxfps like 125. The server has no maxfps limit anymore although it's quite a lot of generated traffic of high cl_maxfps settings on a "normal" (not de-coupled) client.


Again and again:
- r1q2ded never had a "strafejumpbug"
- Da^Juan is now happy all the way and the clan =DA= now finally uses r1q2ded (b1875 - the newest version at the moment) on their server.
- It really is time for q2-serveradmins to update to r1q2ded since everything else has a shitload of security-holes and can be defined as "dead software", like NCServer is.

Teh Webby: http://www.r1ch.net/stuff/r1q2/
Server Cvars: http://www.r1ch.net/forum/viewtopic.php?t=103
Changelog: http://www.r1ch.net/forum/viewtopic.php?t=106
Download R1Q2 Source: http://www.r1ch.net/stuff/r1q2/src/

Haui said everything, DA Main is running the latest r1q2 atm with the latest version of q2admin (1.326d).

yay pings is the pwn now too

To any of you using r1q2 as a server, please update it to the latest version (b1917) to fix a major security hole .

already done! btw r1q2 owns!

angra wrote:already done!

I still see the 1788 on your servers, angra, huh?