CVS test server

[Jonathan]

While I was alone with LaTeX on the server it got through my second wall (not on my client - it needed an update from the server). I said "PHASE BUG". No client recording this time, not even one that is too big to be uploaded here.

[Z-Man]

Jonathan: Thanks, that's so much better. It takes only seven seconds to play back. I think I'll be able to do something with it.
And the fact that you did not manage to provoke it in a local game suggests it has something to do with the timer forgery the server does.

The rubber failure, as observed on the rim wall sometimes and on new cycle walls, (and that was responsible for the failure in the clientside recording Jonathan provided) is fixed in current CVS. Cycle deaths are communicated from the movement code to the higher level code with exceptions, and the rubber code intercepts them if there is rubber left. Of course, a lot of interesting new problems surfaced (I was able to phase through the rim wall in one local game...), I fixed those I already found. I'll update the test server to the fixed code and settings that provoke problems later today, so Jonathan can go and find a couple of more

[Z-Man]

Jonathan's phasing bug is fixed (I hope, the fixing change broke the recording before it could get to the bug). Credit goes mostly to Jonathan for providing excellent data to work with. I think I transformed it into a new instance of the instant kill bug. Maybe I can fix that, too, but it'll be more difficult.
It was not the kind of bug I had expected first, I must admit. It was something introduced for the extrapolating network snyc code: walls "from the future" were not considered dangerous (because they are not when extrapolating). However, they should be dangerous during normal simulation as (because of the time-warping) it's quite normal to see a wall from the future there. Consequently, I moved the time check into the extrapolator class where it belongs.

Settings have been updated to the new level of bug-finding on the server. Beware: users of non-current CVS clients may experience client crashes when they or other players grind too closely. The server is now running in debug mode, I hope this does not cause inconvenient performance drops.

[Jonathan]

Beware: users of non-current CVS clients may experience client crashes when they or other players grind too closely.

Before getting the latest CVS client I'll try my current client.

[Luke-Jr]

Beware: users of non-current CVS clients may experience client crashes when they or other players grind too closely.

Is this an acceptable behaviour? Server admin will not want to upgrade if 0.2.7.1 clients are going to crash...

[Lucifer]

Beware: users of non-current CVS clients may experience client crashes when they or other players grind too closely.

Is this an acceptable behaviour? Server admin will not want to upgrade if 0.2.7.1 clients are going to crash...

Heh, I read z-man's post as "Older releases aren't affected, but older CVS clients are". Did I read it right?

[Luke-Jr]

Beware: users of non-current CVS clients may experience client crashes when they or other players grind too closely.

Is this an acceptable behaviour? Server admin will not want to upgrade if 0.2.7.1 clients are going to crash...

Heh, I read z-man's post as "Older releases aren't affected, but older CVS clients are". Did I read it right?

I think you read it right-- still a good idea to check that 0.2.7.1 will work, though...

[Z-Man]

Yep. A) Lucifer read it right. It's the camera visibility code that crashes, and that's not in 0.2.7.1. and B) It's the settings that cause the crash, not the code. The same settings with any other server (even 0.2.7.1) cause the same crashes.

[Jonathan]

So I went in with an old client. It got confused to the point where I said BUG just in case it was the server, but that seems very unlikely after the second time.

[Z-Man]

That's the settings, too. Especially the extremely high rubber (umm, and the server is programmed not to send old clients updates when they're sitting directly in front of a wall because they'd only confuse them, which is a good idea only for low rubber. It's configurable.) With default settings, old clients should work about as well as with an old server with default settings.

[Z-Man]

The settings on the CVS server are now sane for playing; the technical problems (crashes etc) seem to be about gone, so no it's time to test gameplay. It's currently configured with CYCLE_RUBBER_DELAY .5 and CYCLE_RUBBER_DELAY_BONUS 0, which will kill you if you're trying to do a too tight 180 or adjust. The rubber meter of old clients will be unreliable on the server.

It's now named "Z-Man's 0.2.8 Gameplay Test Server" to reflect the change.

[dlh]

I went to try Z-Man's 0.2.8 Gameplay Test Server, but I can't even play a round. The round starts, but I get no updates about the AI clients. They just drive towards the middle and go through each other, and eventually I die (and I don't always receive the message that I did die). Then a new rounds starts, and same happens. My ping is fine (~250ms). Running _alpha20050905

[Z-Man]

Can you give me a recording of that? It happened to me once, but I blamed it on the network connection since I could not reproduce it.

Edit: I got one myself. The reason I could not reproduce it seems to be that the server needs to be idling about a while before you connect, a condition I did not test for.

[dlh]

Can you give me a recording of that? It happened to me once, but I blamed it on the network connection since I could not reproduce it.

Edit: I got one myself. The reason I could not reproduce it seems to be that the server needs to be idling about a while before you connect, a condition I did not test for.

Another =>

[Z-Man]

I identified and fixed the error; the timer was sending out syncs as fast as it could, spamming everything else. You may have have noticed that in the exuberant network traffic you received.

Bandwidth control bookeeping was broken, too.