-- [ Picked text/plain from multipart/alternative ] Ian, that is why I went the whole control freak route instead.
Sick and tired of getting blamed for clients poor setups. That and tards with dodgy rates and cl_interpolate 0 abusers. On 4/28/06, Whisper <[EMAIL PROTECTED]> wrote: > > Dual CPU Dual Core Opeterons FTW :p > > 1 SRCDS per core effectively > > I would get lynched if I tried to pull 100 tick off our public CS:S > servers now > > > On 4/28/06, Ian mu <[EMAIL PROTECTED]> wrote: > > > > -- > > [ Picked text/plain from multipart/alternative ] > > Pretty much the same as us really, we just go for 66tick, have tried 33 > > & > > 100, and 66 seems to be the sweet spot for least amount of problems > > (100tick > > maybe more client issues as well though I often suspect). > > > > > > On 4/27/06, Stuart Stegall <[EMAIL PROTECTED]> wrote: > > > > > > This is a multi-part message in MIME format. > > > -- > > > [ Picked text/plain from multipart/alternative ] > > > Those are our recommendations for competition servers, but we wish the > > > leagues would allow other cl_interp #s, but it's not up to us. > > > > > > For public servers, we just cannot recommend 100 tickrate. We just > > get > > > too many complaints door and other problems (since the September > > update > > > I believe). For pubs we just recommend 66 tickrate. > > > > > > Whisper wrote: > > > > -- > > > > [ Picked text/plain from multipart/alternative ] > > > > This is what we do currently: > > > > > > > > Windows OS > > > > Kernel Timer Resolution 1000Hz > > > > 100 tickrate > > > > 600 fps_max > > > > 30000 sv_maxrate > > > > 5000 sv_minrate for small servers 7500 for 40 player servers > > > > 100 sv_maxupdaterate > > > > 0 sv_minupdaterate (because of that strange lag problem if the fps > > drops > > > > even for an instant and then goes straight back to 500fps) > > > > > > > > We enforce cl_interpolate 1 and cl_interp 0.1 with zBlock (We have > > to > > > cater > > > > for users from 56Kbps to 24000Kbps connections who can be up to > > 4000KM > > > away > > > > from the servers) > > > > > > > > We also enforce ranges of rate values on clients mostly so people > > are > > > not > > > > blaming us for their shit house in game playing experience > > > > rate 6000 - 30000 > > > > cl_updaterate 35 - 100 > > > > cl_cmdrate 35 - 100 > > > > > > > > As much as you may like to quote the official documentation, the > > reality > > > > does not always match what the official documentation says is > > supposed > > > to > > > > happen i.e. bugs or "features" that remain undocumented. > > > > > > > > I for one would almost kill for a complete Game Packet, UDP Segment, > > IP > > > > Packet break down of SDRDS/HLDS client server communications along > > with > > > the > > > > effects of changing various settings for highly optimised low > > latency > > > > lossless high speed LAN networks to the unoptimised slowest worst > > case > > > > scenario networks rather than using trial and error as the method > > for > > > > verifying the best for the circumstances settings. > > > > > > > > On 4/28/06, James Tucker < [EMAIL PROTECTED]> wrote: > > > > > > > >> I think the bigger issue is people not keep up to date with > > > >> documentation and updates, and meanwhile misunderstanding the > > netcode > > > >> in general. I moved away from this mailinglist for a long time due > > to > > > >> the continual pointless arguments of this nature. I think the > > > >> documentation is clear, if you read valves documentation in their > > > >> wiki, then read carefully what each cvar says as you type it > > without a > > > >> value. > > > >> > > > >> There are things I still see very commonly abused though (why I'm > > > here): > > > >> > > > >> 1. There is no maximum to rate or sv_maxrate. Read the cvar docs > > and > > > >> compare to the cl_cmdrate/cl_updaterate cvar docs. Attention to > > detail > > > >> people, and don't read old CS 1.6 docs for advice on the Source > > > >> engine. > > > >> 2. cl_smooth is still being recommended set to 0 by many people - > > this > > > >> was fixed YEARS ago now (check the update logs), and the server > > does > > > >> cl_smooth 1, so if you have cl_smooth 0 on your client, your view > > WILL > > > >> DIFFER from the servers view. > > > >> 3. Optimising with client settings far from defaults is ALWAYS > > going > > > >> to seperate you from Valves internal testing procedures (how they > > > >> optimise the game) which will use some form of the defaults! > > > >> 4. rate and sv_maxrate are still being set to low by most people > > due > > > >> to these imaginary 'limits'. This causes choke. Beware setting them > > > >> too high causes loss. If you don't know the difference you need to > > > >> learn. > > > >> 5. cl_cmdrate is being recommended too high still. In the same way > > > >> that you don't set a server sv_maxupdaterate to 100 if the server > > is > > > >> doing 64fps on a 100tick setup, you don't set cl_cmdrate higher > > than > > > >> your average client fps if you don't want client generated choke > > > >> (which will drop bullets!). > > > >> 6. No accounting for protocol overheads - check the size of the > > real > > > >> data flow to and from your servers, there's some un-accounted for > > data > > > >> there than when you get a pile of clients running updaterates at > > your > > > >> tick, you'll start to use more data than you were originally > > expecting > > > >> - I've been recommending using 10-20% boundaries to my clients for > > > >> years anyway. > > > >> 7. Use QoS services to prioritize your data! > > > >> 8. 100 tickrate is above and beyond the call of duty. There are > > very > > > >> few humans who can quantize anything at 100Hz. Furhtermore, latency > > > > > >> flux is greater than 0.01ms in almost ALL cases of internet server, > > > >> therefore this is quite silly anyway, it's wasted data as the next > > > >> tick could well arrive before the last! > > > >> 9. cl_interp - I don't know how, after good references now have > > decent > > > >> pagerank and are referenced in a lot of core reference docs that > > > >> people don't get this yet. And yet there are now server side > > plugins > > > >> that lock you to cl_interp 0.01 - this only feels good if you set > > > >> cl_smooth 0, suprise suprise, because it's extrapolating, not > > > >> interpolating. At a client fps of 20-30 you might not even notice, > > but > > > >> it's there. The interpolation, prediction, and smoothing engines > > WORK > > > >> REALLY WELL, so leave them on, and as has been noted in the past, > > the > > > >> server generally runs them ALL, so for a server-client aligned > > world > > > >> view, you want to run them. > > > >> 10. cl_smoothtime is a capping value, like sv_maxrate and rate - > > they > > > >> don't affect anything until the controlled variable approaches the > > > >> value of the cvar. In other words, sv_maxrate 20000 generally does > > > >> nothing if you use cl_updaterate 10. > > > >> 11. dump net_graph! net_graph does not give you accurate values. > > I've > > > >> seen servers out there which register 0.1 loss permanently in > > > >> net_channels, and net_graph shows nothing at all. The client-server > > > >> consistency is heavily affected by this loss and many of you would > > > >> never find out whats causing it. > > > >> > > > >> > > > >> Locking variables does not solve any of the above problems. The > > > >> problems of the communities are: > > > >> > > > >> 1. Ego - players can't accept having a bad day. > > > >> 2. Sheep - players listen too much to random forum posts rather > > than > > > >> finding out real information - reading 'rate' and 'cl_updaterate' > > and > > > >> understanding in detail what the cvar documentation says and > > doesn't > > > >> say is a perfect example. > > > >> 3. Name clobbering - as there are common cvar names between cs 1.6and > > > >> cs:s there is alot of clobbering of names and people read the wrong > > > >> documentation, what's worse is this has spread to the hl2dm > > > >> communities. > > > >> 4. HSPs / GSPs don't generally understand much better and often > > give > > > bad > > > >> advice. > > > >> 5. Variables outside of workable settings should not be able to be > > > >> set. Setting cl_cmdrate < 10 no longer works. Setting rate really > > low > > > >> works really fine aslong as your server admin hasn't set moronic > > > >> settings and your client doesn't do something like cl_interp 0.01. > > > >> 6. Lack of cohesion in thinking - there are plenty of setups that > > will > > > >> feel smooth, if you're going to choose someones advice to follow, > > > >> follow all of it, not a part from here a part from there. > > > >> 7. Major leagues carry community thinking - some of the major > > leagues > > > >> have very incorrect settings which they are pushing out as "league > > > >> standards". Please, get some computer scientists or engineers to do > > > > > >> the real engineering work, inference without understanding is > > called > > > >> guessing. > > > >> > > > >> > > > >> On 26/04/06, Biscuits < [EMAIL PROTECTED]> wrote: > > > >> > > > >>> It would create more as well. > > > >>> > > > >>> On 4/27/06, Andreas Grimm <[EMAIL PROTECTED] > wrote: > > > >>> > > > >>>> and why ? > > > >>>> > > > >>>> -----Ursprüngliche Nachricht----- > > > >>>> Von: [EMAIL PROTECTED] > > > >>>> [mailto:[EMAIL PROTECTED] Im Auftrag von Hans > > Vos > > > >>>> Gesendet: Mittwoch, 26. April 2006 16:27 > > > >>>> An: hlds@list.valvesoftware.com > > > >>>> Betreff: Re: [hlds] Re: Server tickrate suggestions > > > >>>> > > > >>>> VALVE should just lock the tickrate on 66, would save us all a > > lot of > > > >>>> headaches. > > > >>>> > > > >>>> -- > > > >>>> Kind regards, > > > >>>> > > > >>>> Hans Vos > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> To unsubscribe, edit your list preferences, or view the list > > > archives, > > > >>>> please visit: > > > >>>> http://list.valvesoftware.com/mailman/listinfo/hlds > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> To unsubscribe, edit your list preferences, or view the list > > > archives, > > > >>>> > > > >> please visit: > > > >> > > > >>>> http://list.valvesoftware.com/mailman/listinfo/hlds > > > >>>> > > > >>>> > > > >>> -- > > > >>> Biscuits > > > >>> > > > >>> _______________________________________________ > > > >>> To unsubscribe, edit your list preferences, or view the list > > archives, > > > >>> > > > >> please visit: > > > >> > > > >>> http://list.valvesoftware.com/mailman/listinfo/hlds > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> To unsubscribe, edit your list preferences, or view the list > > archives, > > > >> please visit: > > > >> http://list.valvesoftware.com/mailman/listinfo/hlds > > > >> > > > >> > > > > -- > > > > > > > > _______________________________________________ > > > > To unsubscribe, edit your list preferences, or view the list > > archives, > > > please visit: > > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > > > > > > > > > > -- > > > > > > _______________________________________________ > > > To unsubscribe, edit your list preferences, or view the list archives, > > > please visit: > > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > -- > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
