dumb question but how do you force the clients netcode settings? put it
in the autoexec? or use mani?
Whisper wrote:
--
[ 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
