version 2.3 = end of nexuiz for me

[*HxC*Cuizinier]

Also, try cl_netinputpacketlosstolerance 1.

ok, with the cl_netinputpacketlosstolerance 1 seems to be much playable.
always the same high values of ping, but don't feel them.

not good as 2.2.3 but this command run well.
The fact that my ISP filter against P2P traffic is possible because of the TV by adsl which provides.I talked with another french player who have the same ISP, "neuf telecom" and he havn't the 2.3 new lags as me.
my router is a C-box (Sagem Fast 3302) never had problem with it.

Thx for helping me, I think I'll wait a little before quiting =)

[Zaarock]

I agree with some of these points... theres also some strange server joining lag on the os x ver apparently ( max time to join server ive had is like 7 minutes ) but ingame its still definately playable on some servers

[SavageX]

Also, try cl_netinputpacketlosstolerance 1.

ok, with the cl_netinputpacketlosstolerance 1 seems to be much playable.
always the same high values of ping, but don't feel them.

Good to know it's better for you now.

As for the higher displayed ping value: The actual ping didn't change (after all it's still the same connection), it's just that a more accurate way to measure it is used.

[GreEn`mArine]

it is very odd that cl_netinputpacketlosstolerance > 0 would affect (improve) movement or decrease felt lag, because it just sends packets twice which, for less good internet connections, will increase (!) ping because the connection is loaded more than before, and I cannot think how it could make movement much smoother (even for my "really" packetloss loaded line the movement-smoothness was not really much affected by the pl-tolerance variable, but, of course switching weapons was working then). Anyhow, a screenshot of your netgraph would really be helpful to tell what is wrong with your connection!

[SavageX]

it is very odd that cl_netinputpacketlosstolerance > 0 would affect (improve) movement

Sending it more than once makes it more robust against packetloss. Without that redundance a lost packet of that type would lead to your input getting lost, meaning you'd stop moving for a short fraction of a second on the server, while the client assumes you were moving as usual. This may lead to jerky movement.

Of course one can debate if sending the stuff more than twice makes sense ( > 1) - an already loaded line would be stuffed even further.

[*HxC*Cuizinier]

Yerstaday, much playable, DCC's 1on1 at 20:05 on game


Today, not much playable, DCC's Minsta at 13:47, before join the game


on game

this time, I really fell the 80 of ping

[Urmel]

and you checked if cl_netinputpacketlosstolerance is still 1?

[ZyanKLee]

and you checked if cl_netinputpacketlosstolerance is still 1?

this one needs to be set on the client-side, doesn't it ?

[divVerent]

Also, try cl_netinputpacketlosstolerance 1.

ok, with the cl_netinputpacketlosstolerance 1 seems to be much playable.
always the same high values of ping, but don't feel them.

Okay, that proves that you do suffer from packet loss.

If you aren't using a WLAN and aren't sharing your internet connection with anyone else, you should call your ISP - it seems to be their fault.

As for the measurements, they now are more correct than before (and less varying).

[GreEn`mArine]

Cuizi, you should definetely not use the DCC public servers for testing your connection, but just servers that don't modify the sv_clmovement_minping valuie, which are basically all existing v2.3 servers, well, except the DCC public servers. This is because the nice admins of DCC decided to disable client-side movement on their public servers. The DCC 1on1 server however is a good thing for testing because you use your cl_movement there.

If playing on DCC 1on1 is fine but playing on the DCC public servers isn't, it could either mean that it is because of the deactivation of cl_movement on the public server (honetly, if you do have packetloss, playing on a DCC public server will NOT feel good, I tested that myself) or also probably because there are MORE players and your line is more loaded because of that.

And seeing from that screenshot: On the netgraph one can unfortunately only see that you have packetloss on the incoming side. If you have these kind of spikes on server like the 1on1 server it will not be choppy there, because the clientside movement will predict it fine in most of the cases. However, if packetloss also affects your packets (outgoing) TO the server (and this cannot be seen on the netgraph), then your movement will be choppy there, too.