Main Navigation
Clan Navigation
Service
Contact
Events
W M D M D F S S
14 1 2 3 4 5 6 7
15 8 9 10 11 12 13 14
16 15 16 17 18 19 20 21
17 22 23 24 25 26 27 28
18 29 30  
< [ April 2024 ] >
Counter
Online:36
Heute:249
Monat6.833
Gesamt:1.956.690
03.01.2014 um 11:52 Uhr
Frohes Neues Ja...
31.12.2012 um 12:26 Uhr
Guten Rutsch in...
10.02.2012
-=NTC=- vs Tactical Fighters 5 : 27
09.01.2011
CounterStrike:Source vs TD 17 : 32
User Login



Registrierung
Passwort vergessen
Last Forum
23.12.2012 um 13:27 Uhr
so last minuet Wei..
01.12.2012 um 10:54 Uhr
An und Verkauf
28.11.2012 um 14:15 Uhr
mh Scheich macht i..
01.11.2012 um 05:03 Uhr
Happy Birthday Bla..
01.11.2012 um 05:01 Uhr
Happy Birthday Crank
Next Clanwars
Keine Einträge gefunden.
Banner
Votes
Keine Umfrage aktiv
Shoutbox
epfuscher: Überraschung

-=NTC=-Minizicke: die Seite gibt es ja noch *freu* nur die Server wohl nicht mehr, oder irre ich?

epfuscher: hab dir eine Nachricht geschrieben

-=NTC=-Minizicke: holla

epfuscher: Kuckuck

-=NTC=-Minizicke: huhu

epfuscher: Sie lebt noch

-=NTC=-Minizicke: na klar doch

-=NTC=-Minizicke: Tach auch

-=NTC=-Minizicke: huhu


Archiv
Forum - Thema
Nächstes Thema ->
Forum -> -=NTC=- | Allgemein -> Technische Probleme -> Netsettings erklären

Antworten: 6
Seite [1]
flashertoy


Try to beat me




Beiträge: 120
# Thema - 02.06.2006 um 21:07 Uhr


- 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ßfakt or (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!

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 schiessen, 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, 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.

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 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 ?

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 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.

Quelle: www.csconfigs.mthone.de
Inaktiv
flashertoy
Thread-Ersteller


Try to beat me




Beiträge: 120
# Antwort: 1 - 02.06.2006 um 21:24 Uhr
Vorwort
Diese Netsettings sind allesamt nur Richtwerte da sie je nach Verbingsart auch variieren können. Im Grunde kommt es darauf an, dass man ein optimales Gefühl im Spiel bekommt, egal was andere erzählen oder welche Einstellungen man von wem bekommt.

Die beste methode ist von daher immer ausprobieren. Trotzdem denke ich kann man sich im Groben an diese Werte halten und von da aus ggf. die Feinjustierung durchführen.

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-Lite (oder für qualitativ schwache DSL-Leitungen)
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 "81"
cl_dlmax "512"
ex_interp "0.07"

DSL+FP (768k bzw 1000 k)
rate "20000"
cl_cmdrate "99"
cl_cmdbackup "15"
cl_updaterate "99"
cl_dlmax "512"
ex_interp "0.04"

QDSL (1024k)
rate "25000"
cl_cmdrate "101"
cl_cmdbackup "2"
cl_updaterate "101"
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"

Wie interessierten Beobachtern vielleicht aufgefallen ist ist der Wert ex_interp bei den meisten Verbindungsarten ein deutlich Anderer als wir für unsere Tickrate 100 verwenden. Da sich die Einstellung zwischen TR66 und TR100 nur im Wert cl_interpolate ändert (0/1) und ex_interp immer gleich bleibt lohnt es sich bestimmt auch mal die obigen Werte auszuprobieren.

Vor allem vor dem Hintergrund dass jede Internetverbindung anders ist und man daher nie die perfekten Settings für jeden Anschluss angeben kann.

In dem Fall hilft nur, sich reinlesen, das System verstehen und ausprobieren...





Inaktiv
|
flashertoy
Thread-Ersteller


Try to beat me




Beiträge: 120
# Antwort: 2 - 02.06.2006 um 22:02 Uhr
da jede Internetverbindung eine Andere ist, da Standortbezogen und auch T-Dsl nicht immer gleich T-Dsl ist gibt es oft keine andere Möglichkeit als Ausprobieren.

Dabei geht man am besten folgendermassen vor.

Nehmen wir an wir haben

DSL Lite oder allgemein eine schwache DSL Leitung und stellt sich folgende Werte ein:

rate "12000"
cl_cmdrate "51"
cl_cmdbackup "10"
cl_updaterate "51"
cl_dlmax "168"
ex_interp "0.07"

Dabei merkt man dass es nicht optimal läuft also muss man es ausprobieren. Da systematisches Arbeiten oft schneller zum Ziel führt als wirres herumstellen stellen wir die Settings erstmal auf einen unteren Standartwert von:

cl_cmdrate "20"
cl_cmdbackup "2"
cl_dlmax "256"
cl_updaterate "40"
rate "5000"
ex_interp "0.05"

Bei dem Einen oder Anderen kann es sein dass Er mit diesen Settings schon ganz ordentlich spielen kann. Bei anderen eher nicht. Daher fangen wir an die Werte schrittweise zu verstellen.

Jeder Schritt sollte folgende Änderungen beinhalten:

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"


Dies wiederholt man so lange bis man bei cl_updaterate 100 angekommen ist.

Das Ergebniss ist dass man beim ausprobieren relativ gutes Gefühl über die einzelnen Verstellungen gewinnt.

Das kann man noch vertiefen wenn man danach alles wieder auf den unteren Standartwert stellt und die Settings in kleineren Stücken verändert, in diesem also:

cl_cmdrate "+10"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "+10"
rate "+1500"
ex_interp "-0.005"

Dieses macht man bis man bei cl_updaterate "60" erreicht.

Jetzt kommt die Feineinstellung:

Man verändert die cl_updaterate und die cl_cmdrate in entgegengesetzte Richtungen, also folgendermaßen:

cl_cmdrate "+/-5"
cl_cmdbackup "+2"
cl_dlmax "256"
cl_updaterate "-/+5"
rate "+1500"
ex_interp "+/-0.0025" (bei cl_updateate +5 ex_interp -0.0025 // bei cl_updaterate -5; ex_interp +0.0025)


Dadurch bekommt man ein relativ genaues Bild davon mit welchen Settings man in etwa am Besten zurechtkommt. Dies soll bei jedem Spieler unterschiedlich sein so dass man da nur schwer eine allgemeine Aussage treffen kann.


Inaktiv
|
flashertoy
Thread-Ersteller


Try to beat me




Beiträge: 120
# Antwort: 3 - 02.06.2006 um 22:08 Uhr
Manchmal soll es zu Problemen zwischen den Beiden Werten und Voiceservern wie TeamSpeak kommen.

In dem Fall wird empfohlen die cl_updaterate und die cl_cmdrate auf "99" zu stellen welches sich im Spiel kaum bemerkbar macht.

Ich konnte keine Veränderung bemerken aber wenn gar nichts hilft sollte man dies auch mal testen.


Inaktiv
|
FreZer


Beginner




Beiträge: 5
# Antwort: 4 - 27.12.2010 um 00:58 Uhr
was ihr da habt ist schon recht schön, dabei fehlt euch aber noch ne menge hintergrundwissen und ne menge infos die euch noch besser helfen die settings besser zu konfigurieren ich habe mir mal die mühe gemahct alles zusammen zu fassen was man brauch zu finden unter www.netsettings.info.cm viel spaß euch damit


Inaktiv
|
Der_W


Beginner




Beiträge: 1
# Antwort: 5 - 01.02.2011 um 09:50 Uhr
Das Thema ist 4 1/2 Jahre alt!


Inaktiv
|
-=NTC=-Minizicke


Going for pro




Beiträge: 575
# Antwort: 6 - 01.02.2011 um 11:39 Uhr
aber scheinbar immer wieder aktuell


------------------
* wer Rechtschreibfehler findet, darf sie behalten *
* www.gidf.de *
* ich bin immer zickig, und damit Basta *
Mein Link


Inaktiv
|
Antworten: 6
Seite [1]


Sie müssen sich registrieren, um zu antworten.