Stats
Heute: 6
Gestern: 17
Monat: 378
Gesamt: 78112
Mehr:

hier 

Online:


Donate
Wir freuen uns über jede Spende.

Votes
Welche ist deine lieblings Map in CS?

de_cache
de_cobblestone
de_inferno
de_nuke
de_mirage
de_overpass
de_train
eine andere!



[ Results ]
Last Wars Last News
4on4    BiP 2:16 lost
5on5    Team.MNS 14:16 lost
5on5    PPU* 19:31 lost
5on5    Rabiez 17:13 won
5on5    nwe 14:16 lost
5on5    .|KoRn|. 14:16 lost
5on5    fresh2def 34:20 won
30.04.16 - 13:16 Uhr
de_cache 2016: Ein Blick auf das HD-Update
30.04.16 - 12:57 Uhr
Update bringt de_Nuke-Remake
23.12.15 - 23:59 Uhr
Fröhliche Weihnachtszeit euch allen
18.09.15 - 21:51 Uhr
Update bringt neue Animationen und Hitboxen

Netsettings
Befehlserklärungen | Richtwerte | Wie komme ich zu guten Netsettings? | Wissenswertes

Befehlserklärungen

rate
RATE gibt an, wie viel 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 durchschießt. 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-Dauerfeuer-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 so etwas 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_INTERP 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 schießen, um es zu treffen.

Durch eine zu hohe CL_UPDATERATE kann es zu einem Datenstau (choke) oder gar Datenverlust (loss) kommen.

cl_rate
CL_RATE ist ein untergeordneter Wert, welcher - Ähnlich wie RATE - angibt, wie viel Byte pro Sekunde maximal vom Client zum Server übertragen werden können. Der Defaultwert hierfür ist 9999, welcher auch gleichzeitig auf den meisten Servern das Maximum darstellt - Änderungen dieses Wertes empfehlen wir nicht.

cl_dlmax
CL_DLMAX gibt die maximale Downloadbandbreite in Kilobit pro Sekunde an, mit welcher man Maps etc. runterladen könnte. Klar wird kein Server einfach mal so ein Megabit rausrücken, damit jemand mit Q-DSL kurz eine Map runterladen kann - mehr als Default (128kbit) ist es jedoch in den meisten Fällen. Hier eine Liste mit den jeweiligen Download-Geschwindigkeiten diverser Verbindungsmöglichkeiten:
56k --> cl_dlmax 56
ISDN --> cl_dlmax 64
Dual-ISDN --> cl_dlmax 128
Cable --> cl_dlmax 128 bis 256 (je nach Anbindung)
DSL-Low --> cl_dlmax 256 bis 512
T-DSL --> cl_dlmax 768
Q-DSL --> cl_dlmax 1024
LAN --> cl_dlmax 2000+

Sollte Deine Verbindung hier nicht mit aufgeführt sein, erkundige dich 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.

ex_interp
EX_INTERP gibt an für wie viele Millisekunden (ms) die HL-Engine die fehlenden Daten, welche wegen einer zu niedrigen CL_UPDATERATE fehlen, vorausberechnen soll. Je höher diese Zahl ist, desto fehlerhafter ist die Vorhersage, da die Zukunft nur mit gewissen Wahrscheinlichkeiten vorhersagbar ist, welche mit größerem Zeitabstand immer unwahrscheinlicher werden. Hat man eine hohe CL_UPDATERATE, ist es nicht nötig via EX_INTERP eine Vorhersage der Bewegungen anderer Spielermodels machen zu lassen, denn dadurch würde 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 (bei EX_INTERP 0.1 Default).

Unsere Empfehlung ist, den EX_INTERP-Wert abhängig vom Netgraph-Ping zu setzen: hat man im Netgraph z.B einen Ping von 35 im Durchschnitt (er schwankt also zwischen 30 und 40), so hätte man in einer Kampfsituation durchschnitt 5-10 mehr, also 40. EX_INTERP 0.040 wäre in diesem Fall also der Idealwert. Man kann das auch leicht im Kopf ausrechnen: ich habe 55ms, plus 5 macht 60 ... das ganze durch 1000 teilen und schon habe ich 0.06 - das ist der EX_INTERP-Wert, der bei 55ms am besten passen würde.

"Warum nicht einfach EX_INTERP 0 ?" - Ganz einfach, das ergibt sich doch aus der Befehlserklärung : Bei EX_INTERP 0 stellt CS den Wert automatisch, durch die Berechnung 1/CL_UPDATERATE, ein. Bei einer entsprechenden CL_UPDATERATE von 100 käme ein Wert von 0.01 für EX_INTERP heraus. Natürlich wäre das auf einer LAN sehr gut, doch wer hat im Internet einen (realen) Ping von 10 ?

ex_extrapmax
EX_EXTRAPMAX stellt indirekt eine Art Ausgleichswert dar. Durch verringerten EX_INTERP-Wert "ruckeln" die Models der anderen Spieler mehr rum, was man durch Erhöhung von EX_EXTRAPMAX zumindest teilweise ausgleichen kann, da so mehr Zwischenschritte berechnet werden können. Der Defaultwert hierfür ist 1.2 - man kann ihn beliebig erhöhen, jedoch reicht meist ein Wert von 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 Spielermodels werden etwas in die Zukunft versetzt, jedoch nicht ganz soweit, da EX_EXTRAPMAX eben auch (bzw. hauptsächlich) Zwischenschritte der Bewegungen berechnet. 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 hierfür zu nutzen hat also eher Sinn. Auf VAC-Servern ist es jedoch nicht mÃglich diesen Wert zu verändern, daher raten wir allgemein davon ab EX_EXTRAPMAX zu verändern - setzt euren EX_INTERP-Wert lieber um einige ms höher um das "Modelruckeln" zu unterbinden.

Login


Cookie setzen


Register
Send password
Login Probleme?
Potm

Random Picture