what if you can't use matties eventscripts for whatever reason?
Adam Sando wrote:
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: [email protected]
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: [email protected]
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: [email protected]
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
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
