banimod / etpro / ettv forums

dont think this is an ettv bug

i heard something about servers crashing when accessing invalid client id's with lua - this could be happening for the same reason and i think it was fixed in cvs

ReyalP wrote:@arni: whats wrong with large MTUs on win32 ?

players instantly go 999

told zinx and he just said "its windows ..."

A while ago I asked bani if it was possible to set a higher default ettv_mtu in the future releases. He said that i'd have to ask around in the forum if there are people who'd have a problem with it. Background: In europe we have some routers that send smaller packets before large and are thus shuff...

yes i have the same problem on linux since b12 and b13 but since all other servers of the same type worked ok i thought it was a problem that i created myself. What happens: The server works perfectly but once in a while is just messes up, all players go 999 and lagometer shows only snap per second ...

or barrels, like i did in sw_fuel_b3

thats good but an mtu of only 1400 bytes will bring the problem with "euro b0rkrouters" (=european routers that send smaller packets before large ones) back. (results in packet disordering and lags) so i think even if that gets ettv masters to run on windows its not a solution. gg windows ...

i dont rly see the problem


http://maps.arni.name/etmain/sw_fueldump_b3.pk3

download, put on the server, be happy

yep, hubbing finally works, but specs still have a 0 ping ^^

you forgot to publicly release b12 ^^

--> good job if there are no new issues from b12-pre8

thanks alot - b4 netcode behaviour might be terribly wrong, but it has one difference from later versions ... it works ...

i think the engine itself only supports "/noclip" for players, not for specs - i have never seen specs use noclip

zinx wrote:Lags to players caused by over-zealous rate limiting, which could happen in some cases (timing related)

so this means that all the known problems that apear to be caused by european networks with many alternative routes are still there and b4 -> b7 is still the best for us?

so what exactly was fixed?

Lags from hubs?
Lags from b5+ servers (packet disorder)

looks to me like id software doesnt know their own code - at least for et setting cl_allowdownload 0 also turns of web download even if thats enabled.

so only solution is to turn it off completely

if it is we'd need an ettv b4 and a b7 release without the bug, the combination of these two is the only one that really works for productive use.

(btw: the "matchserver crash bug" i reported some time ago is also caused by connected b9 ettvs .....)