[[C.T.X]-ebr!s-]

Hier auch mal was interessantes und erläuterung der einzelnen befehlen:

Rate

RATE gibt an, wieviel Byte maximal pro Sekunde transferiert werden. Ein Wert von ca. 9000 wird nur extrem selten ueberschritten und ist insofern unsere Empfehlung. Der Wert dieses Befehls wird serverseitig von den zwei Befehlen SV_MINRATE und SV_MAXRATE begrenzt - die meisten Server haben ein Maximum bei 9000 bis 10000, insofern sollte man RATE auch nicht viel hoeher stellen.


CL_RATE

CL_RATE ist ein untergeordneter Wert, welcher - aehnlich wie RATE - welcher angibt, wieviel Byte pro sekunde maximal vom Client zum Server uebertragen werden. Der Defaultwert hierfuer ist 9999, welcher auch direkt auf den meisten Servern das Maximum darstellt - Aenderungen dieses Wertes empfehlen wir nicht.


CL_CMDRATE

CL_CMDRATE gibt an, wie viele Datenpakete pro Sekunde vom Spieler zum Server uebertragen werden. Der Defaultwert hierfuer liegt bei 30, welcher den Nebeneffekt hat, dass unter anderem die Recoilberechnung der Waffen nur 30 mal pro Sekunde gemacht wird. Wenn nun zwischen zwei Recoilberechnungen mehr als ein Schuss abgefeuert werden kann, dann schlagen diese Schuesse fast auf derselben Stelle ein (bedingt durch die permanent vorhandene Streuung der Waffe, unabhaengig vom richtigen Recoil, schlagen sie nicht alle genau mittig ein). Eine weitere Empfehlung waere der Wert 1000 - dadurch wird das Recoil 1000x pro Sekunde berechnet, was in jedem Fall die Echtzeitberechnung des Recoils garantiert. Ausserdem wird durch dieses Maximum der CMDRATE auch die serverseitige Prioritaet der Abarbeitung der Daten erhoeht, denn sonst wuerde der Server nie mit den Daten fertigwerden. So erzeugt das dann den Effekt, dass die abgefeuerten Kugeln nicht erst ein paar Millisekunden verzoegert ankommen, sondern sofort und ohne Verzoegerung.Die CMDRATE mit den Bildern pro Sekunde gleichzusetzen bringt keinen Vorteil, da die NetEngine von Half-Life durch komplizierte Berechnungen jede beliebige Anzahl an Bildern pro Sekunde mit jeder beliebigen CL_CMDRATE selbst synchronisieren kann.


CL_UPDATERATE

CL_UPDATERATE gibt an, wie viele Datenpakete vom Server zum Spieler pro Sekunde versendet werden. Je weniger Daten dies beinhaltet, desdo weniger "aktuell" sind die Daten, die der Client erhaelt, so dass man schon von Lag bzw. Verzoegerung sprechen kann, was im Netgraph nachpruefbar ist. Je hoeher man den Wert setzt, desdo niedriger wird die "ms"-Zahl im Netgraph, welche die wahre Verzoegerung angibt. Bei einer CL_UPDATERATE von etwa 160 kommt es selbst auf 32-Mann-Servern nichtmehr vor, dass im Netgraph trotz der grossen Datenmenge irgendeine Verzoegerung angezeigt wird, was bedeutet, dass man KEINE Verzoegerung mehr hat. Dieser Befehl ist serverseitig von den zwei Befehlen SV_MINUPDATERATE und SV_MAXUPDATERATE begrenzt, was jedoch bei den meisten Servern nicht genutzt wird.Dass die Verzoegerung ganz eliminiert werden kann, das ist der Effekt des Befehls CL_LC (Lag-Compensation) - stellt man ihn ab, wuerde man seinen richtigen Ping "fuehlen", da er ja nichtmehr kompensiert (ausgeglichen) wird. Also an lassen!


EX_INTERP

EX_INTERP beinhaltet eine Zahl, welche aussagt, wieviel Millisekunden (ms) Half-Life die fehlenden Daten, welche wegen niedriger Updaterate fehlen, vorausberechnen soll. Je hoeher diese Zahl ist, desdo fehlerbehafteter ist die Vorhersage, da die Zukunft nur mit gewissen Wahrscheinlichkeiten vorhersagbar ist, welche mit groesserem Zeitabstand immer unwahrscheinlicher werden. Hat man durch eine hohe CL_UPDATERATE keinen Ping mehr im Netgraph, ist es nicht noetig, via EX_INTERP eine Vorhersage der Bewegungen der anderen Spielermodels machen zu lassen, denn dadurch wuerde man die anderen Spieler nie da sehen, wo sie wirklich sind, sondern nur da, wo sie mit hoher Wahrscheinlichkeit in zum Beispiel 100 Millisekunden sein werden, falls man EX_INTERP auf dessen Defaultwert 0.1 laesst. Als Empfehlung gilt hierfuer: man sollte EX_INTERP mit dem Netgraph-Ping gleichsetzen - hat man also im Netgraph etwa einen Ping von 34 im Durchschnitt (er schwankt also z.B. zwischen 30 und 38), so sollte man EX_INTERP auf 0.034 stellen.


EX_EXTRAPMAX

EX_EXTRAPMAX stellt indirekt eine art Ausgleichswert der. Durch verringerten EX_INTERP-Wert "ruckeln" die Models der anderen Spieler mehr rum, was man durch Erhoehung von EX_EXTRAPMAX zumindest teilweise ausgleichen kann, da so mehr Zwischenschritte berechnet werden koennen. Der Defaultwert hierfuer ist 1.2 - man kann ihn beliebig erhoehen, jedoch reicht meist ein Wert bis maximal 10 problemlos aus. Ein extrem hoher Wert von etwa 100000 oder 1000000 hat nahezu denselben Effekt, wie der Befehl EX_INTERP bei seinem Defaultwert: die gegnerischen Models werden etwas in die Zukunft versetzt, jedoch nicht ganz soweit, da EX_EXTRAPMAX eben auch (bzw. hauptsaechlich) Zwischenschritte der Bewegungen berechnet. Leider wissen wir noch nicht, wie weit ein Model durch EX_EXTRAPMAX in die Zukunft versetzt wird - insofern ist es (noch) nicht empfehlenswert, damit zu spielen.Die angegebene Zahl hierbei ist die Anzahl der einzelnen Berechnungen, welche alles genauer darstellen. Kommazahlen stellen, rein objektiv betrachtet, einen Genauigkeitsfaktor der jeweils letzten Berechnung dar - ganze Zahlen hierfuer zu nutzen hat also eher Sinn.


EX_MAXERRORDISTANCE

EX_MAXERRORDISTANCE beinhaltet den maximalen Fehler, der durch die gesamte Vorausberechnung durch EX_-Werte zugelassen wird. 64 ist hierfuer der Defaultwert, welcher aussagt, dass das Maximum bei 64 Spielfeldeinheiten liegt - da Half-Life sehr kleine Einheiten benutzt, spielt 64 in Counter-Strike maximal etwa einen Radius von einem halben Meter dar. Wir empfehlen hier den Wert 0 (null) - speziell bei niedriger Interpolation und leicht erhoehter Extrapolation hat dies den Effekt, dass die Modelanimationen wieder fluessiger werden.


CL_RESEND

CL_RESEND ist dafuer da, die vom Server gesendeten Daten, welche nur mit begrenzter Genauigkeit bzw. nur teilweise angekommen sind, nochmals vom Server zu erhalten, damit sie genauer bzw. vollstaendig werden. Je oefter die Daten gesendet werden, desdo "unaktueller" sind sie allerdings, so dass ein Gefuehl von Verzoegerung entsteht. Der Defaultwert von 6 ist ausserdem etwas uebertrieben, da es eigentlich egal ist, ob ein gegnerischer Spieler 5mm weiter links oder 5mm weiter rechts steht - insofern lauten unsere Empfehlungen hierfuer 2 oder 3, das reicht auf jeden Fall bei weitem aus. Eine Kommazahl stellt hierbei einen Genauigkeitsfaktor dar - der Minimalwert lautet 1.5, was soviel heisst wie: neben den eigentlichen Daten werden ggf. 2 Datenpakete gesendet, von denen das erste 100%ig genau ist und das zweite nur 50%ig (halbe Groesse) - davon kommt mit relativ hoher Wahrscheinlichkeit mindestens eins an und die Datenmenge bleibt dennoch gering.


CL_CMDBACKUP

CL_CMDBACKUP gibt an, wie oft die Daten vom Client zum Server zusaetzlich gesendet werden. Bei dem Defaultwert 2 hat man den Nachteil, dass - durch die fehlerbehaftete Uebertragung in Netzwerken bedingt - desoefteren Daten teilweise oder gar nicht ankommen. In beiden Faellen 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. Erhoeht man diesen Wert empfohlenerweise auf 60, 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 Bestaetigung 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.


CL_DLMAX

CL_DLMAX gibt die maximale Downloadbandbreite in Kilobit pro Sekunde an, mit welcher man Maps etc. runterlaedt. Klar wird kein Server einfach mal so ein Megabit rausruecken, damit jemand mit Q-DSL kurz eine Map runterladen kann - mehr als Default (128kbit) ist es jedoch in den meisten Faellen.Hier eine Liste mit den jeweiligen Download-Geschwindigkeiten diverser Verbindungsmoeglichkeiten:56k --> cl_dlmax 56ISDN --> cl_dlmax 64Dual-ISDN --> cl_dlmax 128Cable --> cl_dlmax 128 bis 256 (je nach Anbindung)DSL-Low --> cl_dlmax 256 bis 512T-DSL --> cl_dlmax 768Q-DSL --> cl_dlmax 1024LAN --> cl_dlmax 2000+Sollte Deine Verbindung hier nicht mit aufgefuehrt sein, erkundige dich notfalls am besten bei deinem Provider, wie hoch dein Downstream ist. Beispielsweise gibt es DSL-Anbieter mit 1.5MBIT Downstream, das entspricht 1536KBIT (1.5*1024) --> cl_dlmax 1536


Verbindung zwischen EX_INTERP und CL_UPDATERATE

Zwischen den Befehlen CL_UPDATERATE und EX_INTERP gibt es eine Verbindung: waerend CL_UPDATERATE die korrekten Daten bis zu einem gewissen Zeitpunkt vom Server erhaelt (bei genuegend hoher CL_UPDATERATE in Echtzeit), berechnet EX_INTERP fehlende Daten voraus. Hat man also durch eine CL_UPDATERATE zwischen 60 und 80 einen Netgraphping von etwa 30ms, so braeuchte man einen EX_INTERP-Wert von 0.03 (=30 Millisekunden), um die restlichen 30ms auszugleichen. Ist die CL_UPDATERATE also bei dem Maximum vom 160, so benoetigt man kein EX_INTERP mehr, da man dadurch die Spieler nicht dort sehen wuerde, wo sie tatsaechlich sind, sondern nur da, wo sie mit hoher Wahrscheinlichkeit in einigen Millisekunden sein werden.Bei einem Teil an Rechnern kann man eine zu weit erhoehte CL_UPDATERATE nicht nutzen, da dadurch Lags enstehen - wild springender Ping, man kommt sich vor als haette man die schlechteste Verbindung weltweit. In diesem Fall fuehren bereits leicht erhoehte NetSettings zu Lags, man sollte rumprobieren, jedoch relativ nah an den Defaultsettings bleiben. Dies gilt allerdings nicht fuer CL_CMDBACKUP 60 und CL_RESEND 3 (oder 2) - diese 2 Werte sollte man in jedem Fall nutzen, da sie lag-VERMINDERND wirken.Bei Spielen auf WWCL-Servern, wo ein EX_INTERP-Wert von 0.1 erzwungen wird, ist es noetig, CL_UPDATERATE so niedrig zu machen, dass man im Netgraph einen Ping von etwa 80-100 hat. Leute mit besonders guten Verbindungen und somit mit besonders niedrigen Pings haben hierbei sogar den Nachteil, dass sie ihren Netgraphping nicht auf 90-100 heraufbekommen koennen und sich deswegen daran gewoehnen sollten, bei EX_INTERP 0.1 auf WWCL-Serven dahin zu schiessen, wo die Gegner vor etwa 60ms gewesen sind. "100 minus Eigenping" ist hierbei die korrekte Zahl, um die die anderen Models in die Zukunft versetzt sind, insofern man mit EX_INTERP 0.1 spieltAnzeige nicht immer richtig.Der Choke gibt an, wie viel Prozent der Daten nicht vom Server zum Client übertragen werden. Theoretisch sollte der Client den Choke mit der rate regulieren können.Beim Testen, wie man den Choke auf 0 runter bekommt habe ich einige Sachen feststellen können.Wenn der Client die Rate erhöht (es darf kein serverseitiges Maximum gesetzt sein), geht der Choke gegen 0. Wenn man aber auf Servern spielt, auf denen Plugins wie wwclTool/csgurad/hlguard installiert sind, dann geht der Choke hoch wenn der Client seine rate erhöht. Außerdem ist die Choke Anzeige auf Servern mit Plugins immer höher als auf Servern ohne Plugins.Die Formel zur Choke Berechnung wurde zu Beta-CS Zeiten entworfen. Damals waren die Server/Connection viel langsamer als heute. Zu Beta-CS Zeiten, hat ein Plugin den Server so ausgelastet dass es zu richtigem Choke gekommen ist. Deshalb gibt es auch heute noch die hohe Choke Anzeige (auf Grund der veralteter Berechnungsformel) auf Servern mit Plugins. Heutzutage verkraften die Server aber viel mehr und bei einem oder zwei Plugins geht zwar die Choke Anzeige hoch, aber der wirkliche Choke bleibt 0.Wenn auf einem Server sehr viele Plugins laufen kann es durchaus zu einem Durchschiess-Effekt bzw richtigem Choke kommen, blos liegt dieser dann nicht bei 100 (laut Anzeige) sondern weitaus niedriger.P.S.: Dies ist nur eine THEORIE


Wieso wird der Choke falsch angezeigt ?


der Scoreboard-Ping


der Choke-Wert im Netgraph

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 wahre Ping zu einem Server, welchen man ueber den Befehl "ping" in einem DOS-Fenster ermitteln kann, ist immer der gleiche - egal, wie hoch man im Spiel die Bandbreite belastet!
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 etwas mit "CL_FlushEntity" - 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 Kab
Diese werte und beschreibung bekam ich von einem Progamer clan der ehem espl ( jetzt die ESL)

Also ungefähre settings:
Rate 9000
Cl_rate 9999
CL_CMDRATE 999
CL_UPDATERATE 166
EX_INTERP auf 0.080
EX_EXTRAPMAX 9,5
EX_MAXERRORDISTANCE 0
CL_RESEND 3
CL_CMDBACKUP 60