Poll

What platform would you run Quetoo on if it was on Steam?
GNU/Linux (Any distribution)
51%
OS X (Any version)
13%
Windows (Any version)
33%
SteamOS (Not Steam)
1%
Other (BSD etc.)
2%
Total votes: 3196

Some minor bugs (as it seems)

Home
Sergeyko
January 07, 2008 - 08:29am

Greetings! Some problems I've experienced (running Quake2World three latest revisions on Windows):

While trying singleplayer maps and playing on test servers, I noticed that the entity movement is rather jerky. The jerkiness can be revealed especially when standing on some bmodel. It seems there are some problems with ground_entity checking code, because (especially in multiplayer) when you're standing on lift or plat, you peridically loose connection with it and starting to fall(may be connection problems or prediction errors but I don't think so).

Also there's a problem with thirdperson camera as it follows player predicted position, while charater remains in position according to what server sends you.

And after spending a long time on the server it starts to sent large amount of packets, the lagometer draws almost a sinus wave :))) .

jdolan
jdolan's picture
January 10, 2008 - 21:57pm

Hi, welcome.

While there is a bit of jitter to the entity interpolation code, I haven't seen anything quite as severe as you describe. The jitter was introduced with higher (and configurable) server tick rate support, which went into svn a few weeks ago. It allows server admins to run servers that send updates to clients at anywhere from 10hz (Quake2 default) to 100Hz or higher. The default update rate is 20Hz, twice that of Quake2, which generally yields a more responsive experience. The interpolation equation has to compensate for server packet rate when lerping between two server frames, and I agree that it's not perfect yet. You'll find that certain framerates and server tickrates work well together, too, while others do not. For example, 30Hz server and 60fps vsync is quite smooth. Anyway, I hope this will be ironed out before long. I should mention that this behaviour is really only noticeable when using r_thirdperson. Other ents, perhaps because they're further away from the view origin, seem to move smoothly at all server tick rates.

I'd recommend cl_predict 0 in conjunction with r_thirdperson 1 to address your other issue. While this might make sense for most people using 3rd person view, it seemed wrong to force this as the default behaviour.

I'll have to look into your last issue. Can you quantify "long time"?

Thanks!

Quake2World
http://quake2world.net