Lag Problems

[Z-Man]

Heh, sorry, the last recording indeed plays back in Windows, which slows down the really-looking-at-it process quite a bit

About the protection suite: haven't heard of it, but I'm glad it's not Norton. It may make problems, but shouldn't unless it either scans all network traffic (potentially blocking some) and scanning programs as they run. You should be able to monitor how many resources it is using from the task manager.

About settings: Currently, there is no way around the instant kills in any high rubber and fast turn server. They're unavoidable if ping charity is bigger than the turn delay, and the high rubber makes them visible. 0.2.8.3 will have configurable ping charity on the server side (if all clients support it), so it'll be possible to tune that down so it won't cause any problems. The inequality you'll have to fulfill will be
PING_CHARITY_MAX + 1/SERVER_FPS < CYCLE_DELAY
and of course the server would have to be able to deliver the configured FPS.

If you don't mind that you'll have to replace wall humping (which causes lots of walls to lie almost parallel, which stresses the engine quite a bit and is asking for trouble) by really tight, single pass grinds for sealing, you can try setting
CYCLE_RUBBER_MINADJUST .01
CYCLE_RUBBER_MINDISTANCE_UNPREPARED .02

And of course the best way is to report the bugs you see, which is what you're doing We'll fix what we can, a bug that happens every 30 seconds on XzL can happen once a day on a different server.

[FroZen]

I tried those settings.Didn't seem to make much of a difference, You could still hump the rim.
But anyways here is a kinda long recording with some weird things in it.Just search for "HERE" the happening is usually right before it.
Thanks for your help

[Z-Man]

The settings aren't meant to prevent wall humping, but they make a sloppy grind followed by some humping end up farther away from the wall than a good initial grind, making the humping less useful for sealing. Of course, with the present rubber and cycle_delay settings, you can do a good initial grind plus lots of humping no problem. If you want to disable the humping, try
CYCLE_RUBBER_DELAY .1
CYCLE_RUBBER_DELAY_BONUS 0
Of course, this kills the humper. I'd guess it would be a rather unpopular change.

The last recording also plays back fine in Unix. I'd need the corresponding server side recording to make sure, but here's what I can see: the one incident at T=190s looks like a teleport bug. All that grinding hand turning must have made the grid datastructures so degenerate on the server that something odd happened. Really nothing can be done about this one except server settings that don't stress the grid engine so much. A better grid engine would help, but can't eliminate odd effects like that completely.
The other three seem to be lost packets, and extreme cases: two turns seem to get lost, and the server gets the third one only and acts on that. What could be done about that is that the server, when it realizes two turns are missing in the client commands, just lets you drive straight on until one of the missing commands arrive. This will make the bike act more correctly, but add more lag. It's unfortunately not possible to reliably fill in the two missing commands; whether you do left-left-left or left-right-right looks, apart from differences in the position that can't be used reliably because they change when rubber is in effect, just the same if only the last turn command arrives.