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.6 and 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
