Registered: 528 |
Members On: 0 |
Guests On: 7 |
Today: 7 |
Month: 7 |
Total: 3.463.389
| W | M | D | M | D | F | S | S | ||||||||||
| 18 | 1
|
2 | 3
|
4 | |||||||||||||
| 19 | 5 | 6 | 7
|
8
|
9
|
10 | 11
|
||||||||||
| 20 | 12 | 13
|
14 | 15
|
16 | 17 | 18
|
||||||||||
| 21 | 19 | 20
|
21
|
22 | 23 | 24 | 25 | ||||||||||
| 22 | 26
|
27
|
28 | 29
|
30
|
31
|
|||||||||||
| Forum - Thema | ||||
| Neue Themen | Aktive Themen | Bestenliste | Statistik | Suche |
| Forum » 1.0 Games Board » Counter Strike » Net-Settings Befehls Erklärungen | ||||
Antworten: 0
Seite 1 |
|
 en!gForum-Mod  Beiträge: 700 |
# Thema - 10.03.2006 um 17:35 Uhr
Befehlserklärungen [1] rate Quote: 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 [2] cl_cmdbackup Quote: 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). [3] cl_cmdrate Quote: 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 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! [4] cl_updaterate Quote: 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 schiessen, um es zu treffen. ¹ ² Durch eine zu hohe CL_UPDATERATE kann es zu einem Datenstau (choke) oder gar Datenverlust (loss) kommen. [5] cl_rate Quote: CL_RATE ist ein untergeordneter Wert, welcher - ähnlich wie RATE - angibt, wieviel 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. [6] cl_dlmax Quote: 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 [7] ex_interp Quote: EX_INTERP gibt an für wieviele 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össerem 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 ? [8] ex_extrapmax Quote: 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 hierfuer 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 ------------------ |
Inaktiv |
|
Antworten: 0
Seite 1 |
|
| Sie müssen sich registrieren, um zu antworten. |
warhead
Grüsse an alle die nach 24 Jahren hier immer noch die HP besuchen
(08.06.2024 um 09:15 Uhr)
Vojnik
Grüße an alle! 
(01.09.2024 um 18:53 Uhr)
WildCat
Hällöchen Leutz , hoffe , es ist alles frisch bei euch 
(28.09.2024 um 20:09 Uhr)
WildCat
Wir ollen Berlinör leben och noch 
(28.09.2024 um 20:10 Uhr)
KHAN
Hallo ihr verrückten Menschen 
(25.10.2024 um 21:15 Uhr)
warhead
alles gute an die alten säcke hier
(08.02.2025 um 09:06 Uhr)
Design & Coding - Copyright ©2010, www.Universe-Designs.de
CMS ClanSphere - Copyright ©2003-2010, Scriptinfo
01.05.2025 um 00:01 Uhr nach UTC +1 [Sommerzeit] - Load: 26ms