We all got cycled out in the past, we all know how annoying it is.
And we still don't know what exactly causes this. After some thinking about this error i decided to try something new.
I made a simple bind on F11, /reconnect.

Once the map is over and the scoreboard is displayed i wait till the last moment and then i hit F11 and reconnect to the server.
Like this the server loses all track of my presence from the previous map and behaves like I'm a new player trying to connect.
I don't know about others but i never got dropped during the "first" visit to the server. Even when i was connecting while the loading was in progress.

The scoreboard is displayed for 13 to 15 seconds. Timing is important cause if you hit the /reconnect bind to early you will load the previous map first and then just jump to the loading screen of the next map.
If you hit it to late, the bind wont work.

If anyone know what causes this feel free to drop a line. I had a chance to talk with Svarox about this today, and we managed to find half a dozen reasons why this might be happening. Any idea is welcome.

_________________


Bring the Rayne.

Hooooray i thought i am only one but i see everybody is cursed by this

http://forums.urbanterror.info/topic/82 ... ge__st__20

NulL pointed out the problem.

_________________

#define MAX_RELIABLE_COMMANDS 64
qcommon.h

Maybe I should try this

Btw this error appears a lot on Crossing and Subterra. Sometimes on Tunis.

I read this forum a while ago but I don't fully agree with his explanation. He says that the cause is the excessive number of players and time spent to load a map, while this bug is due to excessive number of players and which map you are about to play on. For example, I never get this error on suburbs and toxic but almost always on subterra, despite their loading time is maybe two times the one of subterra. (Irony, subterra is NulL's map, maybe I will ask him some information about it).

Like I wrote somewhere else, I don't understand how increasing this value could stop this error to happen. Here is the code from ioq3 :

It means that if you increase MAX_RELIABLE_COMMANDS, you have more chances to get a true condition for the if, then more chances to get the error...
Sniffing the network traffic would be interesting, only problem is that you need lots of clients to operate in normal conditions (maybe fake clients would do the trick ?)

_________________
ut4_he_tennis_v0.1
-------------------------
"We are talking about computers here, compared to those I can read women like a book ;P"
Unclefragger

I mean, I don't know the context, but that doesn't make any sense to me. clc.serverCommandSequence + MAX_RELIABLE_COMMANDS would make sense, but subtracting it? It seems like the name is actually wrong. Instead of MAX_RELIABLE_COMMANDS, the way it is used it should be named RELIABLE_COMMAND_OFFSET or something like that instead. I don't know, no matter how I look at it, it just seems to be wrong.

_________________

Monitoring these variables On Run should help to solve tthis mystery.. no?

Decreasing the value could possibly help - if the constant was only used in one place, or if it was consequently used in this (imho wrong) way.

_________________