I think the current fad is Matties EventScripts with zBlock Min on an internet public server, so I'd suggest that.
Just curious to know what the best rate enforcing ScriptPack is for Matties... I've seen Aces Rates pack floating around however haven't used any rate enforcement on my server as such, so can't comment on what the best one is. Any thoughts? Regards, Adam -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Long Sent: Friday, 28 April 2006 06:58 AM To: hlds@list.valvesoftware.com Subject: RE: [hlds] Re: Server tickrate suggestions 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 This e-mail has been scanned for viruses by Hostworks Message Scanning Services - powered by MessageLabs. For further information contact Hostworks on 1300 30 4848. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
