This is a multi-part message in MIME format. -- [ Picked text/plain from multipart/alternative ] zBlock Max and some other plugins enforce the interpolate settings (however there's quite a bit of argument about the need to force interpolate to 1 but not force a particular interp number) The rate settings can be enforced in many different ways. Mattie's scripting plugin is a popular choice, but it adds a lot of overhead to constantly force them. I am probably going to make a plugin that allows the forcing of rate settings and interpolate to 1 but not touching interp.
Scott Long wrote: > Whisper, > > How are you enforcing the rates and interp settings? Any way to do that > silently? > > Scott > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Whisper > Sent: Thursday, April 27, 2006 9:45 AM > To: hlds@list.valvesoftware.com > Subject: Re: [hlds] Re: Server tickrate suggestions > > -- > [ 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 > > > > _______________________________________________ > 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
