So... da hier immer nach Erklärungen für Netsettings etc geschriehen wird, hier mal n ausführliches Tut:
Übrigends: Freie CFG von mir: http://www.forumdeluxx.de/forum/showpost.php?p=9811873
Aufteilung:
Part1: Allgemeines
Part2: Wie komme ich zu guten Settings ?
Part3: Richtwerte
Part4: Begriffe
############### Allgemeines zu Netsettings ###############
Der Scoreboard-Ping
Was viele nicht wissen ist, dass der im Scoreboard angezeigte Ping von Half-Life/Counter-Strike
nicht korrekt errechnet wird. In der Tat steigt dieser Ping mit optimalen Settings
im Extremfall um bis zu 40% an, ist jedoch konstant. Die einzige Tatsache, welche
zeigt, dass man eine gute Verbindung hat, ist die, dass der im Scoreboard angezeigte
Ping nicht so sehr schwankt - hat man mit den Default-Netsettings einen durchschnittlichen
Scoreboardping von 70, der im Extremfall zwischen 50 und 90 schwankt, so haette
man mit optimalen Settings in etwa einen Durchschnittsping von 90, welcher zwischen
80 und etwa 100 schwankt - und obwohl der Ping hoeher ist, ist das Spielgefuehl
deutlich besser!
Der Choke-Wert im Netgraph
Der Chokewert, viele beklagen sich ueber ihn, koennen jedoch normal spielen
obwohl sie einen Choke von 30, 60 oder noch mehr haben. Wie kommt das? Zum theoretischen:
Choke ist die prozentuale Anzahl der Daten, die auf dem Weg vom Server zum Spieler
irgendwo verschwunden sind und deswegen nie beim Spieler eingetroffen sind.
Leider hat Valve sich dabei irgendwie vertan - man kann spielen, selbst wenn
man einen Choke von 100 hat. Und Choke 100 hiesse theoretisch gesehen, dass
GAR KEINE Daten mehr beim Spieler ankommen, das Spiel wuerde also aus Sicht
des Spielers stillstehen - einige kennen diese Situation vielleicht... erst
passiert eine Weile nichts, dann steht rechts oben "CL_FlushEntityPacket" -
DAS ist die Auswirkung, wenn keine Daten mehr vom Server zum Spieler gelangen!
Einige Server haben ein Maximum fuer RATE gesetzt, ein paar wenige sogar ein
Maximum fuer CL_UPDATERATE - auf solchen Servern fuert jeder RATE- bzw. CL_UPDATERATE-Wert
zu Choke, wenn einer davon hoeher ist, als das serverseitig bestimmte Maximum.
Dennoch kommen genug Daten an, damit Half-Life weiterhin einen synchronen
Spielfluss garantieren kann.
In Einzelfaellen kann es vorkommen, dass die Daten aufgrund der serverseitigen
Begrenzung nicht synchron beim Spieler ankommen, da der Serverrechner zu ausgelastet
ist um die Daten weiterhin synchron zu senden (meist bedingt durch zu viele
Spieleserver auf einem einzigen Rechner) - in solchen Faellen passiert es, dass
die Positionen der Models der anderen Spieler voellig "springend" sind (als
haette man einen Ping umdie 500-800). Man sollte dann die CL_UPDATERATE und
ggf. die RATE soweit runtersetzen, bis der im Netgraph angezeigte Chokewert
unter 15 ist.
Der Loss-Wert im Netgraph
Hat man im Netgraph Loss, so hat man wirklich ein Problem, denn dieser Wert
zeigt an, wieviel Prozent der Gesamtdaten, die man zum Server schickt, NICHT
ankommen. Dies hat meist Leitungsprobleme als Ursache, die man oft nicht selbst
beheben kann - manchmal gibt es technische Maengel, die erst von dafuer qualifizierten
Technikern behoben werden muessen, oder ein Serverrechner ist beispielsweise
an einem nicht sonderlich qualitativen Hub angeschlossen, welcher in einer Universitaet
liegt. Bei letzterem Beispiel ist es leider oft der Fall, dass an Equipment
gespart wurde - ein altes RJ45-Kabel, ein alter 10Mbit-Hub und vielleicht noch
ein Kabelbruch... die hauptsaechlichen Gruende fuer Loss bei einem Server!
Meist kann man den Loss durch den erhoehten cl_cmdbackup-Wert grossteils umgehen,
in ein paar sehr wenigen Faellen ist das technische Problem jedoch so gross,
dass jeder auf einem Server Loss umdie 20-30 hat - in solchen Faellen ist das
Problem mit hoechster Wahrscheinlichkeit ein Kabelbruch des Netz-Kabels (RJ45)
direkt am Serverrechner. Empfehlungen: Serverwechsel oder, falls moeglich, ein
Austausch des defekten Kabels.
cl_cmdbackup - Warum manchmal 60, manchmal 0?
cl_cmdbackup bewirkt, dass ein Datenpaket öfters gesendet wird, bis schliesslich
vom Server die Empfangsbestätigung eintrifft. Dies bewirkt automatisch, wenn
man cl_cmdbackup benutzt, dass die benutzte Bandbreite sich in beide Richtungen
erhöht - bei dem Oberwert 60 wird ein Datenpaket zwar niemals 60x zusätzlich
geschickt, da die Empfangsbestätigung mit sehr hoher Wahrscheinlichkeit schon
viel früher eintrifft, jedoch wird es je nach Verbindung bis zu 5-20x dupliziert
- bei höheren Pings noch öfters, da so die Antwortzeiten länger sind und CS
somit eine längere Zeit keine Empfangsbestätigung für ein Paket enthält -->
es schickt es noch öfter, bis die Bestätigung endlich eintrifft.
Kurz gesagt sollte man nun, wenn man eine wirklich gute Internetanbindung hat,
cl_cmdbackup auf 0 setzen - warum? So werden keine Zusatzpakete geschickt, was
zur Folge hat, dass für die originalen Pakete viel mehr Bandbreite zur Verfügung
steht. Durch diese bessere Verfügbarkeit werden die originalen Pakete etwas
rascher versendet - so, als ob man nicht 500 Autos auf einer Autobahn direkt
hintereinander fahren lässt, sondern nur 10.
Aber woran erkennt man, dass man eine gute Verbindung hat? Allgemein können
die Leute mit T-DSL und Fastpath glücklich sein - denn bei jedem, wo es freigeschalten
wurde, ist eine gute Leitungsqualität sicher. Nun gibt es aber noch einen weiteren
Faktor, wenn es um die Verbindungsqualität geht: die Qualität der Anbindung
des Servers, auf dem man spielen möchte. Da man diese nun leider nicht beeinflussen
kann, wäre es also möglich, dass bei guter Leitungsqualität und cl_cmdbackup
0 einige Datenpakete einfach im Datennirvana verschwinden, was zur Folge hat,
dass manche Kommandos, unter anderem Schüsse, nie beim Server ankommen. Was
kann man da tun? Je nach Server sollte man in diesem Fall dann cl_cmdbackup
erhöhen - erstmal mit dem Defaultwert 2 anfangen, um zu sehen, ob das das Problem
bereits zu lösen vermag. Ist dem nicht so, kann man cl_cmdbackup direkt auf
einen Extremwert erhöhen, da man dann mit leider extrem hoher Wahrscheinlichkeit
eine schlechte Verbindung zum Server hat, welche der Vervielfachung der
Datenpakete bedarf, damit man auf dem Server wie gewohnt spielen kann. Natürlich
wird dadurch die Bandbreite mehr beansprucht, was zur Folge hat, dass die verfeuerten
Schüsse nicht ganz so rasch ankommen, als bei cl_cmdbackup 0.
Meist sind die guten und schlechten Serververbindungen zu bestimmten Servern
permanent gleich, man kann sie in diesen Fällen also nicht durch eine Neueinwahl
beim Provider verändern - nur in ein paar wenigen Fällen, wo die Probleme direkt
von dem jeweiligen Serveranbieter kommen, kann man darauf hoffen, dass der Serveranbieter
die Probleme beheben kann.
Der "Loss"-Wert im Netgraph muss, um das noch einmal zu erwähnen, nicht zwingend
ansteigen, wenn man einen schlechten Server erwischt hat - dieser ist leider
ziemlich fehlerhaft programmiert, so dass man nur in viel extremeren Fällen
überhaupt erst Packetloss angezeigt bekommt.
############### Wie komme ich zu guten Netsettings ? ###############
NetSettings dienen der Anpassung des Clienten und seiner jeweiligen Verbindung zu einem Server. Man kann mit ihnen das Recoil ein wenig optimieren oder aber zum Beispiel den Ping "drücken". Doch wie kommt man nun an gute NetSettings. Oft hört man von Settings 101/101/25000. Diese Settings sind mit Sicherheit nicht schlecht, doch sind es auch nicht die besten.
Die NetSettings müssen wie alle anderen Settings genauso an den eigenen PC, sowie primär an die eigene Connection angepasst werden. Wenn nun einer T-DSL hat, kann er aber nicht ohne weiteres die NetSettings von einem anderen Spieler mit T-DSL nehmen und denken, nun hat er gute, für ihn geeignete NetSettings. Nein, sein Standort ist anders und somit sind auch für ihn andere NetSettings "perfect".
Somit heist das Motto um an gute NetSettings zu gelangen "testen, testen, testen und testen".
Bevor wir anfangen: die Eingabe für Netsettings macht ihr am besten in einer Datei /cstrike/cfg/autoexec.cfg, diese wird immer ausgeführt, wenn ihr CS bzw. CSS startet.
Wo fängt man nun an zu testen. Ich gehe in dieser Einführung davon aus, dass ihr - die User - alle mindestens DSL-Low (~300+ kb/s down/ ~15+ kb/s up) besitzt. Ich denke, dass jene Connection mittlerweile Standard ist. Auf die schlechteren Connections werde ich nicht eingehen. Nun nochmals, wie fangen wir an?
Ganz einfach, wir beginnen mit niedrigen Settings und steigern uns Schrittchenweise.
Fangen wir mit folgenden Settings an:
cl_cmdrate "20"
cl_cmdbackup "2"
cl_dlmax "256"
cl_updaterate "40"
rate "5000"
ex_interp "0.05"
Das sind die Ausgangssettings, mit denen wir starten um uns gute NetSettings zu machen. Einige werden mit diesen Settings schon recht gut spielen können, andere wiederum überhaupt nicht. Daher testen wir nun Stufenweise wie folgt weiter:
Mit jedem Testdurchgang sehen die NetSettings wie folgt aus
cl_cmdrate "+10"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "+10"
rate "+1500"
ex_interp "-0.005"
Nach unserem zweiten Durchgang würden unsere NetSettings also wie folgt Aussehen:
cl_cmdrate "30"
cl_cmdbackup "4"
cl_dlmax "256"
cl_updaterate "50"
rate "6500"
ex_interp "0.045"
Diesen Vorgang wiederholt ihr, bis ihr bei einer cl_updaterate von "100" angekommen seid.
Ergebnis
Nun haben wir einmal alle Settings durchgetestet, doch zu welchem Ergebniss sind wir wirklich gekommen?
Jeder der sich etwas Zeit für diesen NetSettingsTest genommen hat, bei dem wird sich das allgemeine Gefühl für die NetSettings geändert haben.
Jene Person weis nun in etwa, was sich bei dem Verstellen von niedrigen Settings auf hohen Settings verändert.
Wie geht es weiter
Nun wollen wir einmal nicht so exponentiell bleiben und werden kleinlicher. Wir fangen wieder bei den Ausgangswerten von oben an. Doch sieht unser Veränderungsschema nun wie folgt aus:
cl_cmdrate "+10"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "+10"
rate "+1500"
ex_interp "-0.005"
Dieses bleibt gleich, bis wir eine cl_updaterate von "50" oder "60" erreicht haben.
Dann gehen wir anders vor :
cl_cmdrate "+/-5"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "-/+5"
rate "+1500"
ex_interp "+/-0.0025" (bei cl_updaterate +5 ex_interp -0.0025 // bei cl_updaterate -5; ex_interp +0.0025)
Nun gehen wir mit cl_updaterate und cl_cmdrate in verschiedene Richtungen. Während wir cl_updaterate erhöhen, setzen wir die cl_cmdrate niedriger und umgekehrt.
Was folgern wir daraus
Indem wir nun speziell mit cl_updaterate und cl_cmdrate rumgespielt haben, haben wir uns ein recht gutes Gefühl für die NetSettings angeeignet. Wir wissen nun wie sich der Ping und das Spielgefühl mit den jeweiligen Veränderungen hilft.
Einige werden während des Testens schon gemerkt haben, dass sie lieber mit niedrigen Settings spielen und andere mit hohen Settings. Das "perfekte" Spielgefühl ist halt bei jedem Spieler anders.
Fragen und Erklärungen
Warum keine 101/101/25000?
Generell kann man sagen, dass man zwar mit den Settings von cl_updaterate "101"; cl_cmdrate "101"; rate "25000"; spielen kann, dennoch ist alleine an den drei Werten schon etwas auszusetzen. Zum einen ist der rate-wert von "25000" recht hoch. Viele Server haben den maximalen Wert für den Befehl "rate" auf ca. "20000" geblockt. Somit sollte man den rate-wert in die Config auch nicht höher einstellen. Ich persönlich empfehle eine rate von "20000", diese sollte auf allen Servern zugelassen sein und ist auch hoch genug für anständige Settings.
Ein zweites Problem kann auftreten durch die cl_updaterate und cl_cmdrate von "101". Oftmals kommt es zu Problemen mit anderen Voicetools wie zum Beispiel Ventrilo oder Teamspeak. Im Normalfall reicht es aus, wenn man cl_updaterate sowie cl_cmdrate auf "99" stellt. Das sind ebenfalls sehr hohe Werte und unterscheiden sich nicht sehr viel. Jeder Spieler der mit den 101er-Settings spielt, der wird auch mit den 99er-Settings problemlos spielen können.
Thema ex_interp, warum keine "0" oder "1/updaterate"
ex_interp "0" berechnet den Interp-wert nach dem Prinzip 1/cl_updaterate. Spieler mit hohen Settings wie zum Beispiel cl_updaterate "100", dann wird ex_interp nach diesem Prinzip auf ex_interp "0.01" berechnet.
Doch kommt es oftmals vor, dass die Spielfiguren bei einem Interp-wert von "0.01" laggen. Ich empfehle daher immer einen Interp-wert von "0.02" (Bei einer hohen updaterate)
Bei mir ist es so, dass ich mit dem autogenerierten Interp-wert immer ein ungutes Spielgefühl habe, daher stelle ich den Interp-wert immer nach Gefühl ein, der aber immer in etwa der Formel 1/cl_updaterate nahekommt.
Fazit: die guten NetSettings
Wer dieses "Tutorial" komplett durgearbeitet hat und wer eventuell das Tutorial mit einem oder mehreren Personen durchgegangen ist, der wird merken, dass die "perfekten" NetSettings bei jedem verschieden sind. Manche spielen gerne mit hohen Settings, andere wiederum mit niedrigen Settings. Und was folgern wir daraus?
Man kann keine "guten" NetSettings für die jeweiligen Connections als Richtwerte angeben. Da jeder ein individuelles Spielgefühl hat und jeder individuell Settings als "gut" oder "schlecht" empfindet.
Die Richtwerte, die wir angeben, dienen lediglich der theoretischen Orientierung, in welchem Bereich der Ping in etwa der "beste", bzw der "stabilste" ist. Jedoch unterscheidet sich auch dieses von jedem Standort. Das beste bei den Einstellungen der NetSettings ist wirklich das ausgiebige Testen der verschiedenen Werte, damit man ein Gefühl für die Settings bekommt.
############### Richtwerte ###############
Die hier aufgelisteten NetSettings stellen lediglich Richtwerte dar, da es keine optimalen Werte gibt, die bei jedem PC und jeder Leitung perfekt funktionieren.
Probiert einfach ein wenig mit den Werten herum und scheut euch nicht davor, viel Zeit ins Testen zu investieren. Nur so kann man gute NetSettings bekommen. Auch meinen viele, dass es gut sei, wenn der Ping sehr niedrig ist oder die in- bzw out-Werte im netgraph sehr hoch.
Das kann man allerdings so generell nicht sagen, es kommt immer darauf an, wie der User damit zurecht kommt. Jeder hat so seine Vorlieben. Was man allerdings sicher sagen kann ist, dass der Ping (sowohl netgraph, als auch Scoreboard) nicht stark schwanken sollte, was aber auch vom Server abhängt.
56k
rate "5000"
cl_cmdrate "40"
cl_cmdbackup "2"
cl_updaterate "35"
cl_dlmax "42"
ex_interp "0.1"
ISDN
rate "7000"
cl_cmdrate "40"
cl_cmdbackup "4"
cl_updaterate "40"
cl_dlmax "48"
ex_interp "0.1"
ISDN-Dual
rate "9000"
cl_cmdrate "50"
cl_cmdbackup "6"
cl_updaterate "50"
cl_dlmax "96"
ex_interp "0.08"
DSL-Low (für schlechte DSL-Leitungen und DSL-Lite)
rate "12000"
cl_cmdrate "51"
cl_cmdbackup "10"
cl_updaterate "51"
cl_dlmax "168"
ex_interp "0.07"
DSL (für DSL-Leitungen ohne FP)
rate "20000"
cl_cmdrate "81"
cl_cmdbackup "30"
cl_updaterate "71"
cl_dlmax "512"
ex_interp "0.07"
DSL+FP (768k bzw 1000 k)
rate "20000"
cl_cmdrate "81"
cl_cmdbackup "15"
cl_updaterate "99"
cl_dlmax "512"
ex_interp "0.04"
QDSL (1024k)
rate "25000"
cl_cmdrate "99"
cl_cmdbackup "2"
cl_updaterate "99"
cl_dlmax "800"
ex_interp "0.02"
DSL (1526k oder höher mit FP)
rate "25000"
cl_cmdrate "99"
cl_cmdbackup "8"
cl_updaterate "99"
cl_dlmax "1024"
ex_interp "0.03"
LAN
rate "25000"
cl_cmdrate "101"
cl_cmdbackup "0"
cl_updaterate "160"
cl_dlmax "16384"
ex_interp "0.01"
############### Begriffe ###############
rate
RATE gibt an, wieviel Byte maximal pro Sekunde transferiert werden. Dabei wird
der Wert dieses Befehls serverseitig von den zwei Befehlen SV_MINRATE und SV_MAXRATE
begrenzt.
Ein Wert von 9999 ist auf den meisten Public-Servern standard und gilt daher
auch eigentlich als Richtwert für alle Breitbandverbindungen. In fast allen
Ligen ist jedoch eine SV_MAXRATE von 20000 vorgegeben, im LAN sogar 25000, und
ermöglicht somit einen höheren Datenfluss
cl_cmdbackup
CL_CMDBACKUP gibt an, wie oft die Daten vom Client zum Server zusätzlich gesendet
werden. Bei dem Defaultwert 2 hat man den Nachteil, dass durch die fehlerhafte
Übertragung in Netzwerken desöfteren Daten nur teilweise oder gar nicht ankommen.
In beiden Fällen kann ein HL-Server mit den Daten nichts mehr anfangen und ist
darauf angewiesen, dass die Daten mehrfach ankommen, damit er sie auf jeden
Fall auswerten kann. Bei dem Wert 2 kommt es wegen diesem Datenverlust oft dazu,
dass man durch Gegner einfach durchschiesst. Erhöht man diesen Wert empfohlenerweise
auf 60 (vor allem auf Public Servern), so hat man eine absolute Sicherheit,
dass die Daten beim Server ankommen. Die Daten werden zwar nicht alle 60x pro
Sekunde verschickt, jedoch jeweils so oft, bis eine Bestätigung vom Server kommt,
dass das jeweilige Datenpaket fehlerfrei und komplett angekommen ist. Sollte
eine Verbindung zum Server sehr gut sein, kann man CL_CMDBACKUP auch ganz deaktivieren,
also auf 0 setzen (z.B im LAN).
cl_cmdrate
Ein niedriger Wert bei CL_CMDRATE hat zur Folge, dass weniger Pakete an den
Server verschickt werden, welche die eigenen Bewegungen sowie jegliche anderen
Aktionen beinhalten. Pro Paket, welches verschickt wird, wird einmal der Rückstoß
der Waffe berechnet - wenn nun zwischen zwei dieser Berechnungen mehrere Schüsse
abgefeuert werden können, haben diese alle den gleichen Rückstoßfaktor (recoi),
welcher zum Beispiel am Anfang einer kleinen 30-Schuss-DauerfeueAr-Salve immer
sehr gering ist.
Je höher der CL_CMDRATE-Wert ist, desto mehr Datenpakete werden maximal pro
Sekunde verschickt - der Server hat also mehr Daten zu verarbeiten, bearbeitet
sie insofern also früher bzw. mit höherer Priorität, als wenn man nur wenige
Pakete an den Server verschickt. Der Waffenrückstoß wird bei einem hohen Wert
für CL_CMDRATE zwar öfter berechnet, jedoch hat man hierdurch den Vorteil, dass
die Daten aufgrund der erhöhten Datenmenge früher verarbeitet werden, was u.a.
den Effekt hat, dass Schüsse früher ankommen. Es sei anzumerken, dass bei erhöhter
CL_CMDRATE nicht permanent eine höhere Datenmenge versandt wird - der angegebene
Wert ist eine Art Höchstgeschwindigkeit für CS, auf welche der Datenfluss beschleunigt
wird, wenn es auf Grund vieler Daten nötig sein sollte.
Achja: CL_CMDRATE mit seinen FPS gleichzusetzen hat wenig Sinn - Half-Life kann
von sich aus jede beliebige Anzahl an FPS mit jedem beliebigen CL_CMDRATE-Wert
synchronisieren. Wäre das nicht der Fall, so hätte jeder mit einem etwas schlechten
Rechner, bei welchem die FPS schwanken, permanent Lags und könnte damit unmöglich
spielen - selbst bei Spielern mit sehr guten Rechnern, bei denen die Bilder
pro Sekunde zwischen 99 und 100 schwanken könnten, würde man diese Lags noch
relativ krass verspüren. Das einzige Spiel, das uns bekannt ist, welches dieses
Problem hatte, war die erste Alphaversion von Doom1
Wenn selbst ID-Software
soetwas innerhalb der Programmierzeit von Doom1 bereits gemerkt hat und korrigieren
konnte, hängt Valve da mit absoluter Sicherheit nicht über 11 Jahre hinterher!!
Also... diese Erklärungen mit "FPS = CMDRATE" einfach nicht glauben - sie sind
absolut fragwürdig und undurchdacht!
cl_updaterate
Je niedriger der CL_UPDATERATE-Wert ist, desto weniger aktuell sind die Daten,
die man vom Server erhält. Diese Daten beinhalten die Positionen und Aktionen
anderer Spieler.
Damit es für die jeweils fehlenden Daten einen Ausgleich gibt, ist EX_AINTERP
erschaffen worden. Im Netgraph sieht man eine "ms"-Zahl (Millisekunden), welche
die momentane Verzögerung anzeigt. Teilt man diese Zahl durch 1000, so hat man
in etwa den Wert, den man für EX_INTERP einsetzen sollte. Die vorherberechneten
Daten sind also dank EX_INTERP komplett vorhanden, werden jedoch an Hand von
Wahrscheinlichkeiten (wo wird Spieler x in Beachtung seines aktuellen "Kurses"
und seiner aktuellen Geschwindigkeit in 100ms höchstwahrscheinlich stehen?)
errechnet, so dass sie nie 100%ig korrekt¹ sein können, was also einen gewissen
Rechenfehler zur Folge hat.
Viel besser ist es, wenn man eine hohe CL_UPDATERATE benutzen kann. Man erhält
die korrekten Daten² und EX_INTERP muss weniger ausgleichen. So man kann bei
genügend hoher CL_UPDATERATE den Wert von EX_INTERP auf ein Minimum reduzieren
- ganz deaktivieren lässt es sich jedoch nicht !
Verwendet man bei einer hohen CL_UPDATERATE dennoch einen EX_INTERP-Wert von
0.1, so würde der "Ausgleich" dennoch die Daten für die kommenden 100 Millisekunden
berechnen und auch zeichnen, was zur Folge hat, dass man alles um 100ms vorausberechnet
sieht - man muss also genau 100ms HINTER ein Spielermodel schiessen, um es zu
treffen.
¹ ² Durch eine zu hohe CL_UPDATERATE kann es zu einem Datenstau (choke) oder
gar Datenverlust (loss) kommen.
Vielen Dank für das Lesen, hoffe einigen von euch ist jetzt die Lust auf Netsettingsfragen in Forum vergangen...
Übrigends: Freie CFG von mir: http://www.forumdeluxx.de/forum/showpost.php?p=9811873
Aufteilung:
Part1: Allgemeines
Part2: Wie komme ich zu guten Settings ?
Part3: Richtwerte
Part4: Begriffe
############### Allgemeines zu Netsettings ###############
Der Scoreboard-Ping
Was viele nicht wissen ist, dass der im Scoreboard angezeigte Ping von Half-Life/Counter-Strike
nicht korrekt errechnet wird. In der Tat steigt dieser Ping mit optimalen Settings
im Extremfall um bis zu 40% an, ist jedoch konstant. Die einzige Tatsache, welche
zeigt, dass man eine gute Verbindung hat, ist die, dass der im Scoreboard angezeigte
Ping nicht so sehr schwankt - hat man mit den Default-Netsettings einen durchschnittlichen
Scoreboardping von 70, der im Extremfall zwischen 50 und 90 schwankt, so haette
man mit optimalen Settings in etwa einen Durchschnittsping von 90, welcher zwischen
80 und etwa 100 schwankt - und obwohl der Ping hoeher ist, ist das Spielgefuehl
deutlich besser!
Der Choke-Wert im Netgraph
Der Chokewert, viele beklagen sich ueber ihn, koennen jedoch normal spielen
obwohl sie einen Choke von 30, 60 oder noch mehr haben. Wie kommt das? Zum theoretischen:
Choke ist die prozentuale Anzahl der Daten, die auf dem Weg vom Server zum Spieler
irgendwo verschwunden sind und deswegen nie beim Spieler eingetroffen sind.
Leider hat Valve sich dabei irgendwie vertan - man kann spielen, selbst wenn
man einen Choke von 100 hat. Und Choke 100 hiesse theoretisch gesehen, dass
GAR KEINE Daten mehr beim Spieler ankommen, das Spiel wuerde also aus Sicht
des Spielers stillstehen - einige kennen diese Situation vielleicht... erst
passiert eine Weile nichts, dann steht rechts oben "CL_FlushEntityPacket" -
DAS ist die Auswirkung, wenn keine Daten mehr vom Server zum Spieler gelangen!
Einige Server haben ein Maximum fuer RATE gesetzt, ein paar wenige sogar ein
Maximum fuer CL_UPDATERATE - auf solchen Servern fuert jeder RATE- bzw. CL_UPDATERATE-Wert
zu Choke, wenn einer davon hoeher ist, als das serverseitig bestimmte Maximum.
Dennoch kommen genug Daten an, damit Half-Life weiterhin einen synchronen
Spielfluss garantieren kann.
In Einzelfaellen kann es vorkommen, dass die Daten aufgrund der serverseitigen
Begrenzung nicht synchron beim Spieler ankommen, da der Serverrechner zu ausgelastet
ist um die Daten weiterhin synchron zu senden (meist bedingt durch zu viele
Spieleserver auf einem einzigen Rechner) - in solchen Faellen passiert es, dass
die Positionen der Models der anderen Spieler voellig "springend" sind (als
haette man einen Ping umdie 500-800). Man sollte dann die CL_UPDATERATE und
ggf. die RATE soweit runtersetzen, bis der im Netgraph angezeigte Chokewert
unter 15 ist.
Der Loss-Wert im Netgraph
Hat man im Netgraph Loss, so hat man wirklich ein Problem, denn dieser Wert
zeigt an, wieviel Prozent der Gesamtdaten, die man zum Server schickt, NICHT
ankommen. Dies hat meist Leitungsprobleme als Ursache, die man oft nicht selbst
beheben kann - manchmal gibt es technische Maengel, die erst von dafuer qualifizierten
Technikern behoben werden muessen, oder ein Serverrechner ist beispielsweise
an einem nicht sonderlich qualitativen Hub angeschlossen, welcher in einer Universitaet
liegt. Bei letzterem Beispiel ist es leider oft der Fall, dass an Equipment
gespart wurde - ein altes RJ45-Kabel, ein alter 10Mbit-Hub und vielleicht noch
ein Kabelbruch... die hauptsaechlichen Gruende fuer Loss bei einem Server!
Meist kann man den Loss durch den erhoehten cl_cmdbackup-Wert grossteils umgehen,
in ein paar sehr wenigen Faellen ist das technische Problem jedoch so gross,
dass jeder auf einem Server Loss umdie 20-30 hat - in solchen Faellen ist das
Problem mit hoechster Wahrscheinlichkeit ein Kabelbruch des Netz-Kabels (RJ45)
direkt am Serverrechner. Empfehlungen: Serverwechsel oder, falls moeglich, ein
Austausch des defekten Kabels.
cl_cmdbackup - Warum manchmal 60, manchmal 0?
cl_cmdbackup bewirkt, dass ein Datenpaket öfters gesendet wird, bis schliesslich
vom Server die Empfangsbestätigung eintrifft. Dies bewirkt automatisch, wenn
man cl_cmdbackup benutzt, dass die benutzte Bandbreite sich in beide Richtungen
erhöht - bei dem Oberwert 60 wird ein Datenpaket zwar niemals 60x zusätzlich
geschickt, da die Empfangsbestätigung mit sehr hoher Wahrscheinlichkeit schon
viel früher eintrifft, jedoch wird es je nach Verbindung bis zu 5-20x dupliziert
- bei höheren Pings noch öfters, da so die Antwortzeiten länger sind und CS
somit eine längere Zeit keine Empfangsbestätigung für ein Paket enthält -->
es schickt es noch öfter, bis die Bestätigung endlich eintrifft.
Kurz gesagt sollte man nun, wenn man eine wirklich gute Internetanbindung hat,
cl_cmdbackup auf 0 setzen - warum? So werden keine Zusatzpakete geschickt, was
zur Folge hat, dass für die originalen Pakete viel mehr Bandbreite zur Verfügung
steht. Durch diese bessere Verfügbarkeit werden die originalen Pakete etwas
rascher versendet - so, als ob man nicht 500 Autos auf einer Autobahn direkt
hintereinander fahren lässt, sondern nur 10.
Aber woran erkennt man, dass man eine gute Verbindung hat? Allgemein können
die Leute mit T-DSL und Fastpath glücklich sein - denn bei jedem, wo es freigeschalten
wurde, ist eine gute Leitungsqualität sicher. Nun gibt es aber noch einen weiteren
Faktor, wenn es um die Verbindungsqualität geht: die Qualität der Anbindung
des Servers, auf dem man spielen möchte. Da man diese nun leider nicht beeinflussen
kann, wäre es also möglich, dass bei guter Leitungsqualität und cl_cmdbackup
0 einige Datenpakete einfach im Datennirvana verschwinden, was zur Folge hat,
dass manche Kommandos, unter anderem Schüsse, nie beim Server ankommen. Was
kann man da tun? Je nach Server sollte man in diesem Fall dann cl_cmdbackup
erhöhen - erstmal mit dem Defaultwert 2 anfangen, um zu sehen, ob das das Problem
bereits zu lösen vermag. Ist dem nicht so, kann man cl_cmdbackup direkt auf
einen Extremwert erhöhen, da man dann mit leider extrem hoher Wahrscheinlichkeit
eine schlechte Verbindung zum Server hat, welche der Vervielfachung der
Datenpakete bedarf, damit man auf dem Server wie gewohnt spielen kann. Natürlich
wird dadurch die Bandbreite mehr beansprucht, was zur Folge hat, dass die verfeuerten
Schüsse nicht ganz so rasch ankommen, als bei cl_cmdbackup 0.
Meist sind die guten und schlechten Serververbindungen zu bestimmten Servern
permanent gleich, man kann sie in diesen Fällen also nicht durch eine Neueinwahl
beim Provider verändern - nur in ein paar wenigen Fällen, wo die Probleme direkt
von dem jeweiligen Serveranbieter kommen, kann man darauf hoffen, dass der Serveranbieter
die Probleme beheben kann.
Der "Loss"-Wert im Netgraph muss, um das noch einmal zu erwähnen, nicht zwingend
ansteigen, wenn man einen schlechten Server erwischt hat - dieser ist leider
ziemlich fehlerhaft programmiert, so dass man nur in viel extremeren Fällen
überhaupt erst Packetloss angezeigt bekommt.
############### Wie komme ich zu guten Netsettings ? ###############
NetSettings dienen der Anpassung des Clienten und seiner jeweiligen Verbindung zu einem Server. Man kann mit ihnen das Recoil ein wenig optimieren oder aber zum Beispiel den Ping "drücken". Doch wie kommt man nun an gute NetSettings. Oft hört man von Settings 101/101/25000. Diese Settings sind mit Sicherheit nicht schlecht, doch sind es auch nicht die besten.
Die NetSettings müssen wie alle anderen Settings genauso an den eigenen PC, sowie primär an die eigene Connection angepasst werden. Wenn nun einer T-DSL hat, kann er aber nicht ohne weiteres die NetSettings von einem anderen Spieler mit T-DSL nehmen und denken, nun hat er gute, für ihn geeignete NetSettings. Nein, sein Standort ist anders und somit sind auch für ihn andere NetSettings "perfect".
Somit heist das Motto um an gute NetSettings zu gelangen "testen, testen, testen und testen".
Bevor wir anfangen: die Eingabe für Netsettings macht ihr am besten in einer Datei /cstrike/cfg/autoexec.cfg, diese wird immer ausgeführt, wenn ihr CS bzw. CSS startet.
Wo fängt man nun an zu testen. Ich gehe in dieser Einführung davon aus, dass ihr - die User - alle mindestens DSL-Low (~300+ kb/s down/ ~15+ kb/s up) besitzt. Ich denke, dass jene Connection mittlerweile Standard ist. Auf die schlechteren Connections werde ich nicht eingehen. Nun nochmals, wie fangen wir an?
Ganz einfach, wir beginnen mit niedrigen Settings und steigern uns Schrittchenweise.
Fangen wir mit folgenden Settings an:
cl_cmdrate "20"
cl_cmdbackup "2"
cl_dlmax "256"
cl_updaterate "40"
rate "5000"
ex_interp "0.05"
Das sind die Ausgangssettings, mit denen wir starten um uns gute NetSettings zu machen. Einige werden mit diesen Settings schon recht gut spielen können, andere wiederum überhaupt nicht. Daher testen wir nun Stufenweise wie folgt weiter:
Mit jedem Testdurchgang sehen die NetSettings wie folgt aus
cl_cmdrate "+10"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "+10"
rate "+1500"
ex_interp "-0.005"
Nach unserem zweiten Durchgang würden unsere NetSettings also wie folgt Aussehen:
cl_cmdrate "30"
cl_cmdbackup "4"
cl_dlmax "256"
cl_updaterate "50"
rate "6500"
ex_interp "0.045"
Diesen Vorgang wiederholt ihr, bis ihr bei einer cl_updaterate von "100" angekommen seid.
Ergebnis
Nun haben wir einmal alle Settings durchgetestet, doch zu welchem Ergebniss sind wir wirklich gekommen?
Jeder der sich etwas Zeit für diesen NetSettingsTest genommen hat, bei dem wird sich das allgemeine Gefühl für die NetSettings geändert haben.
Jene Person weis nun in etwa, was sich bei dem Verstellen von niedrigen Settings auf hohen Settings verändert.
Wie geht es weiter
Nun wollen wir einmal nicht so exponentiell bleiben und werden kleinlicher. Wir fangen wieder bei den Ausgangswerten von oben an. Doch sieht unser Veränderungsschema nun wie folgt aus:
cl_cmdrate "+10"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "+10"
rate "+1500"
ex_interp "-0.005"
Dieses bleibt gleich, bis wir eine cl_updaterate von "50" oder "60" erreicht haben.
Dann gehen wir anders vor :
cl_cmdrate "+/-5"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "-/+5"
rate "+1500"
ex_interp "+/-0.0025" (bei cl_updaterate +5 ex_interp -0.0025 // bei cl_updaterate -5; ex_interp +0.0025)
Nun gehen wir mit cl_updaterate und cl_cmdrate in verschiedene Richtungen. Während wir cl_updaterate erhöhen, setzen wir die cl_cmdrate niedriger und umgekehrt.
Was folgern wir daraus
Indem wir nun speziell mit cl_updaterate und cl_cmdrate rumgespielt haben, haben wir uns ein recht gutes Gefühl für die NetSettings angeeignet. Wir wissen nun wie sich der Ping und das Spielgefühl mit den jeweiligen Veränderungen hilft.
Einige werden während des Testens schon gemerkt haben, dass sie lieber mit niedrigen Settings spielen und andere mit hohen Settings. Das "perfekte" Spielgefühl ist halt bei jedem Spieler anders.
Fragen und Erklärungen
Warum keine 101/101/25000?
Generell kann man sagen, dass man zwar mit den Settings von cl_updaterate "101"; cl_cmdrate "101"; rate "25000"; spielen kann, dennoch ist alleine an den drei Werten schon etwas auszusetzen. Zum einen ist der rate-wert von "25000" recht hoch. Viele Server haben den maximalen Wert für den Befehl "rate" auf ca. "20000" geblockt. Somit sollte man den rate-wert in die Config auch nicht höher einstellen. Ich persönlich empfehle eine rate von "20000", diese sollte auf allen Servern zugelassen sein und ist auch hoch genug für anständige Settings.
Ein zweites Problem kann auftreten durch die cl_updaterate und cl_cmdrate von "101". Oftmals kommt es zu Problemen mit anderen Voicetools wie zum Beispiel Ventrilo oder Teamspeak. Im Normalfall reicht es aus, wenn man cl_updaterate sowie cl_cmdrate auf "99" stellt. Das sind ebenfalls sehr hohe Werte und unterscheiden sich nicht sehr viel. Jeder Spieler der mit den 101er-Settings spielt, der wird auch mit den 99er-Settings problemlos spielen können.
Thema ex_interp, warum keine "0" oder "1/updaterate"
ex_interp "0" berechnet den Interp-wert nach dem Prinzip 1/cl_updaterate. Spieler mit hohen Settings wie zum Beispiel cl_updaterate "100", dann wird ex_interp nach diesem Prinzip auf ex_interp "0.01" berechnet.
Doch kommt es oftmals vor, dass die Spielfiguren bei einem Interp-wert von "0.01" laggen. Ich empfehle daher immer einen Interp-wert von "0.02" (Bei einer hohen updaterate)
Bei mir ist es so, dass ich mit dem autogenerierten Interp-wert immer ein ungutes Spielgefühl habe, daher stelle ich den Interp-wert immer nach Gefühl ein, der aber immer in etwa der Formel 1/cl_updaterate nahekommt.
Fazit: die guten NetSettings
Wer dieses "Tutorial" komplett durgearbeitet hat und wer eventuell das Tutorial mit einem oder mehreren Personen durchgegangen ist, der wird merken, dass die "perfekten" NetSettings bei jedem verschieden sind. Manche spielen gerne mit hohen Settings, andere wiederum mit niedrigen Settings. Und was folgern wir daraus?
Man kann keine "guten" NetSettings für die jeweiligen Connections als Richtwerte angeben. Da jeder ein individuelles Spielgefühl hat und jeder individuell Settings als "gut" oder "schlecht" empfindet.
Die Richtwerte, die wir angeben, dienen lediglich der theoretischen Orientierung, in welchem Bereich der Ping in etwa der "beste", bzw der "stabilste" ist. Jedoch unterscheidet sich auch dieses von jedem Standort. Das beste bei den Einstellungen der NetSettings ist wirklich das ausgiebige Testen der verschiedenen Werte, damit man ein Gefühl für die Settings bekommt.
############### Richtwerte ###############
Die hier aufgelisteten NetSettings stellen lediglich Richtwerte dar, da es keine optimalen Werte gibt, die bei jedem PC und jeder Leitung perfekt funktionieren.
Probiert einfach ein wenig mit den Werten herum und scheut euch nicht davor, viel Zeit ins Testen zu investieren. Nur so kann man gute NetSettings bekommen. Auch meinen viele, dass es gut sei, wenn der Ping sehr niedrig ist oder die in- bzw out-Werte im netgraph sehr hoch.
Das kann man allerdings so generell nicht sagen, es kommt immer darauf an, wie der User damit zurecht kommt. Jeder hat so seine Vorlieben. Was man allerdings sicher sagen kann ist, dass der Ping (sowohl netgraph, als auch Scoreboard) nicht stark schwanken sollte, was aber auch vom Server abhängt.
56k
rate "5000"
cl_cmdrate "40"
cl_cmdbackup "2"
cl_updaterate "35"
cl_dlmax "42"
ex_interp "0.1"
ISDN
rate "7000"
cl_cmdrate "40"
cl_cmdbackup "4"
cl_updaterate "40"
cl_dlmax "48"
ex_interp "0.1"
ISDN-Dual
rate "9000"
cl_cmdrate "50"
cl_cmdbackup "6"
cl_updaterate "50"
cl_dlmax "96"
ex_interp "0.08"
DSL-Low (für schlechte DSL-Leitungen und DSL-Lite)
rate "12000"
cl_cmdrate "51"
cl_cmdbackup "10"
cl_updaterate "51"
cl_dlmax "168"
ex_interp "0.07"
DSL (für DSL-Leitungen ohne FP)
rate "20000"
cl_cmdrate "81"
cl_cmdbackup "30"
cl_updaterate "71"
cl_dlmax "512"
ex_interp "0.07"
DSL+FP (768k bzw 1000 k)
rate "20000"
cl_cmdrate "81"
cl_cmdbackup "15"
cl_updaterate "99"
cl_dlmax "512"
ex_interp "0.04"
QDSL (1024k)
rate "25000"
cl_cmdrate "99"
cl_cmdbackup "2"
cl_updaterate "99"
cl_dlmax "800"
ex_interp "0.02"
DSL (1526k oder höher mit FP)
rate "25000"
cl_cmdrate "99"
cl_cmdbackup "8"
cl_updaterate "99"
cl_dlmax "1024"
ex_interp "0.03"
LAN
rate "25000"
cl_cmdrate "101"
cl_cmdbackup "0"
cl_updaterate "160"
cl_dlmax "16384"
ex_interp "0.01"
############### Begriffe ###############
rate
RATE gibt an, wieviel Byte maximal pro Sekunde transferiert werden. Dabei wird
der Wert dieses Befehls serverseitig von den zwei Befehlen SV_MINRATE und SV_MAXRATE
begrenzt.
Ein Wert von 9999 ist auf den meisten Public-Servern standard und gilt daher
auch eigentlich als Richtwert für alle Breitbandverbindungen. In fast allen
Ligen ist jedoch eine SV_MAXRATE von 20000 vorgegeben, im LAN sogar 25000, und
ermöglicht somit einen höheren Datenfluss
cl_cmdbackup
CL_CMDBACKUP gibt an, wie oft die Daten vom Client zum Server zusätzlich gesendet
werden. Bei dem Defaultwert 2 hat man den Nachteil, dass durch die fehlerhafte
Übertragung in Netzwerken desöfteren Daten nur teilweise oder gar nicht ankommen.
In beiden Fällen kann ein HL-Server mit den Daten nichts mehr anfangen und ist
darauf angewiesen, dass die Daten mehrfach ankommen, damit er sie auf jeden
Fall auswerten kann. Bei dem Wert 2 kommt es wegen diesem Datenverlust oft dazu,
dass man durch Gegner einfach durchschiesst. Erhöht man diesen Wert empfohlenerweise
auf 60 (vor allem auf Public Servern), so hat man eine absolute Sicherheit,
dass die Daten beim Server ankommen. Die Daten werden zwar nicht alle 60x pro
Sekunde verschickt, jedoch jeweils so oft, bis eine Bestätigung vom Server kommt,
dass das jeweilige Datenpaket fehlerfrei und komplett angekommen ist. Sollte
eine Verbindung zum Server sehr gut sein, kann man CL_CMDBACKUP auch ganz deaktivieren,
also auf 0 setzen (z.B im LAN).
cl_cmdrate
Ein niedriger Wert bei CL_CMDRATE hat zur Folge, dass weniger Pakete an den
Server verschickt werden, welche die eigenen Bewegungen sowie jegliche anderen
Aktionen beinhalten. Pro Paket, welches verschickt wird, wird einmal der Rückstoß
der Waffe berechnet - wenn nun zwischen zwei dieser Berechnungen mehrere Schüsse
abgefeuert werden können, haben diese alle den gleichen Rückstoßfaktor (recoi),
welcher zum Beispiel am Anfang einer kleinen 30-Schuss-DauerfeueAr-Salve immer
sehr gering ist.
Je höher der CL_CMDRATE-Wert ist, desto mehr Datenpakete werden maximal pro
Sekunde verschickt - der Server hat also mehr Daten zu verarbeiten, bearbeitet
sie insofern also früher bzw. mit höherer Priorität, als wenn man nur wenige
Pakete an den Server verschickt. Der Waffenrückstoß wird bei einem hohen Wert
für CL_CMDRATE zwar öfter berechnet, jedoch hat man hierdurch den Vorteil, dass
die Daten aufgrund der erhöhten Datenmenge früher verarbeitet werden, was u.a.
den Effekt hat, dass Schüsse früher ankommen. Es sei anzumerken, dass bei erhöhter
CL_CMDRATE nicht permanent eine höhere Datenmenge versandt wird - der angegebene
Wert ist eine Art Höchstgeschwindigkeit für CS, auf welche der Datenfluss beschleunigt
wird, wenn es auf Grund vieler Daten nötig sein sollte.
Achja: CL_CMDRATE mit seinen FPS gleichzusetzen hat wenig Sinn - Half-Life kann
von sich aus jede beliebige Anzahl an FPS mit jedem beliebigen CL_CMDRATE-Wert
synchronisieren. Wäre das nicht der Fall, so hätte jeder mit einem etwas schlechten
Rechner, bei welchem die FPS schwanken, permanent Lags und könnte damit unmöglich
spielen - selbst bei Spielern mit sehr guten Rechnern, bei denen die Bilder
pro Sekunde zwischen 99 und 100 schwanken könnten, würde man diese Lags noch
relativ krass verspüren. Das einzige Spiel, das uns bekannt ist, welches dieses
Problem hatte, war die erste Alphaversion von Doom1
Wenn selbst ID-Softwaresoetwas innerhalb der Programmierzeit von Doom1 bereits gemerkt hat und korrigieren
konnte, hängt Valve da mit absoluter Sicherheit nicht über 11 Jahre hinterher!!
Also... diese Erklärungen mit "FPS = CMDRATE" einfach nicht glauben - sie sind
absolut fragwürdig und undurchdacht!
cl_updaterate
Je niedriger der CL_UPDATERATE-Wert ist, desto weniger aktuell sind die Daten,
die man vom Server erhält. Diese Daten beinhalten die Positionen und Aktionen
anderer Spieler.
Damit es für die jeweils fehlenden Daten einen Ausgleich gibt, ist EX_AINTERP
erschaffen worden. Im Netgraph sieht man eine "ms"-Zahl (Millisekunden), welche
die momentane Verzögerung anzeigt. Teilt man diese Zahl durch 1000, so hat man
in etwa den Wert, den man für EX_INTERP einsetzen sollte. Die vorherberechneten
Daten sind also dank EX_INTERP komplett vorhanden, werden jedoch an Hand von
Wahrscheinlichkeiten (wo wird Spieler x in Beachtung seines aktuellen "Kurses"
und seiner aktuellen Geschwindigkeit in 100ms höchstwahrscheinlich stehen?)
errechnet, so dass sie nie 100%ig korrekt¹ sein können, was also einen gewissen
Rechenfehler zur Folge hat.
Viel besser ist es, wenn man eine hohe CL_UPDATERATE benutzen kann. Man erhält
die korrekten Daten² und EX_INTERP muss weniger ausgleichen. So man kann bei
genügend hoher CL_UPDATERATE den Wert von EX_INTERP auf ein Minimum reduzieren
- ganz deaktivieren lässt es sich jedoch nicht !
Verwendet man bei einer hohen CL_UPDATERATE dennoch einen EX_INTERP-Wert von
0.1, so würde der "Ausgleich" dennoch die Daten für die kommenden 100 Millisekunden
berechnen und auch zeichnen, was zur Folge hat, dass man alles um 100ms vorausberechnet
sieht - man muss also genau 100ms HINTER ein Spielermodel schiessen, um es zu
treffen.
¹ ² Durch eine zu hohe CL_UPDATERATE kann es zu einem Datenstau (choke) oder
gar Datenverlust (loss) kommen.
Vielen Dank für das Lesen, hoffe einigen von euch ist jetzt die Lust auf Netsettingsfragen in Forum vergangen...
Zuletzt bearbeitet:
