Long uptime bug in quake3

[[xeno]Julios]

Does anyone have any comprehensive information about this bug?

(i.e. it's causes, exact effects, etc.)?

Just been in touch with the admins of a popular 3wave server which suffers it and they want more info on it.

Here's my scattered understanding of it so far:

Floating point issue - as server stays on longer and longer, certain time based variables (which don't reset periodically?) accumulate rounding errors due to an insufficiently low decimal point roundoff.

Certain elements of the game are affected by this - animations like sky and flags are choppy, grenades don't bounce properly (they bounce lower), and generally all elements which are dependent upon this non-resetting time function are somehow compromised.

Resetting the server (not rebooting the actual computer, but reloading the quake server) is a way around this, though it needs to be done periodically.

Icculus' quake3.exe addresses this (among many other bugs).


So here are some questions:

1) Do the errors get worse and worse over time (and do the deleterious effects become gradually worsened), or is it an all or none thing?

2) Apart from grenade bounces, does this bug affect anything that isn't purely "bell and whistle" animation? Does it affect the physics of other weapons in any way? Or player movement physics? Or packet sampling?

3) If icculus' quake3.exe is implemented on a server, do clients need to run that same exe to connect?

4) If they can still connect without the modified exe, i'm assuming they'll reap the benefits of the icculus exe simply because it's running on the server - right?

5) Can this be implemented in conjunction with Punkbuster?

[^misantropia^]

1) Do the errors get worse and worse over time (and do the deleterious effects become gradually worsened), or is it an all or none thing?

They become worse, but marginally so.

2) Apart from grenade bounces, does this bug affect anything that isn't purely "bell and whistle" animation? Does it affect the physics of other weapons in any way? Or player movement physics? Or packet sampling?

No.

3) If icculus' quake3.exe is implemented on a server, do clients need to run that same exe to connect?

No.

4) If they can still connect without the modified exe, i'm assuming they'll reap the benefits of the icculus exe simply because it's running on the server - right?

Correct.

5) Can this be implemented in conjunction with Punkbuster?

No. PB is proprietary (closed-source) software, ioquake3 GPL.

[[xeno]Julios]

thanks misantropia

so 2 things:

1) this uptime bug isn't that serious at all - the only way it really affects gameplay is aesthetically and pill bounces.

2) don't you think that icculus' quake3.exe will have difficulty catching on without PB protection?

[Oeloe]

It doesn't destroy gameplay, obviously, but all shaders are moving choppy, including your shaft animation, rail trail etc. And the item bobbing on top of that, just takes away from the 125 fps smoothness of the game.

[^misantropia^]

1) this uptime bug isn't that serious at all - the only way it really affects gameplay is aesthetically and pill bounces.

This is mostly correct but it can introduce some (very rare) quirks. The uptime bug isn't caused so much by floating point accumulation errors as it is caused by a signed integer wrapping from (2^31)-1 to -(2^31). This can cause powerups to never* expire and projectiles to never explode if they are picked up/fired off just before the wrap-around. I used to have this rather funny demo of a grenade bouncing all the way through q3dm3 and everybody on the server going like "WTF?" and "HAX!".

* "never" being defined here as roughly 2^32 ms.

2) don't you think that icculus' quake3.exe will have difficulty catching on without PB protection?

Possibly. However, anyone thinking PB is the Endlösung to cheaters, is fooling himself: any half-decent programmer can whip up an indetectable proxy cheat in an hour. The only thing PB does is keeping the scriptkiddies at bay.

[[xeno]Julios]

The only thing PB does is keeping the scriptkiddies at bay.

which is perhaps the best we can hope for in an anti-cheat protection system.

[dzjepp]

Dosen't it also cause general gameplay lag (fps) - I've been on a few servers that haven't restarted in a while and they feel more laggy than those that frequently restart.

[^misantropia^]

Hmm, I shouldn't think so. Might be caused by the OS's scheduler gradually deprioritizing the server process (stock Linux kernels do this), making it less responsive. Maybe the choppy graphics put you a bit off balance. It does that to me, at least.

[dzjepp]

Well, more than anything, I've noticed for quite some time now that baseq3 gametypes really feel a bit laggy here and there. Sometimes it feels like fps lag, and I could swear I've noticed the various map shaders play back choppy... I don't mind playing on vq3 servers but you know they don't feel as nice as osp.

[Eraser]

If a server's running very long, shaders sometimes just stop animating all together. Quake3 servers should be scheduled for a periodic restart. One server my clan used to rent from Jolt was restarted every night.

I don't know how they did it but I reckon that Linux must have something similar to Windows' Scheduled tasks and then you could simply schedule a batch file that kills the process and restarts it again and have it load a cfg file through the command line.

[^misantropia^]

q3restart.sh:

Code: Select all

#!/bin/sh
kill -TERM `pidof q3ded`
sleep 1
q3ded +exec server.cfg

Add to your cron.daily directory.