Der Counter-Strike: Source Netcode basiert auf einem Server/Client-System. Alles was du tust, wird zum Server geschickt und dort verarbeitet. Beachte aber, dass du den Schritt nach vorne nicht auf dem Client, also deinem Computer tust, sondern das diese Information zum Server geschickt wird. Dort wird diese Information verarbeitet und wird dann wieder zu dir geschickt. Erst dann bewegst du dich einen Schritt nach vorne! Natürlich gibt es auch einige Tricks im Netcode, dass dies nicht so sehr auffällt. Wichtig für dich ist nur zu wissen, dass alle Aktionen auf dem Server ausgeführt werden und nicht auf deinem Computer. Alle Bilder auf deinem Computer sind lediglich ein Abbild vom dem was auf dem Server passiert.
Tickrate
Der Standardwert bei Counter-Strike: Source ist Tickrate 33. Dieser Begriff ist am besten zu erklären, dass der Server mit 33 fps arbeitet. Jedoch gibt es beim Server keine grafische Abbildung, sondern die ganzen Positionsdaten, die Aktionen der Spieler auf der Map werden 33 mal die Sekunde aktualisiert. Umso höher die Tickrate ist, umso stärker wird die CPU belastet, da mehr in der Sekunde aktualisiert wird. Jedoch ist dadurch die Berechnung viel genauer.
Pakete und delta compression
Informationen die von dir zum Server und vom Server zu dir geschickt werden, werden in Paketen gesammelt. Dies passiert um Bandbreite zu sparen, so können auch mehrere Aktionen von dir ausgeführt werden, aber die Daten kommen trotzdem nur in einem Paket an. Dabei werden nicht alle Daten komplett neu gesendet, sondern mit der Delta Kompression werden jeweils nur die Veränderungen geschickt, um wiederrum Bandbreite zu sparen.
cl_updaterate
cl_updaterate gibt an, wieviele Pakete du vom Server innerhalb 1 Sekunde anforderst. Der Standardwert von cl_updaterate ist 20. Du forderst also jede Sekunde 20 Pakete vom Server an.
1000 Millisekunden (1 Sekunde) : 20 Pakete = 50 Millisekunden
Dir wird also alle 50 Millisekunden ein Paket geschickt. Alles was in diesen 50 Millisekunden passiert, wird in einem Paket zusammengefasst. Umso höher also die cl_updaterate ist, umso mehr Pakete werden dir gesendet und umso genauer ist das Spielgefühl. Jedoch hat die Sache einen Hacken. Dieser dürfte den meisten inzwischen bekannt sein, damit die mehr Pakete pro Sekunde angefordern kannst, muss der Server natürlich auch mit der entsprechenden Tickrate laufen. Wenn du zum Beispiel 100 Pakete anforderst auf einen Tickrate 33 Server, können dir maximal 33 Pakete geschickt werden, weil vom Server einfach nicht mehr berechnet wird. Oder ganz simpel. Du kannst nicht 5 Bonbons aus einer Schachtel nehmen, wenn nur 3 drin sind.
cl_cmdrate
Dieser Befehl gibt an, wieviele Pakete pro Sekunde von dir zum Server geschickt werden. Dieser Wert wird genauso berechnet wie cl_updaterate.
1000 Millisekunden (1 Sekunde) : 30 Pakete = ~ 33 Millisekunden
Der Standardwert cl_cmdrate 30 bedeutet, dass alle 33 Millisekunden ein Paket von dir zum Server geschickt wird. Jedoch tritt hier ein ähnliches Problem wie bei cl_updaterate bei einer zu geringen Tickrate ein. Damit du 30 Pakete die Sekunde schicken kannst muss dein Computer mit konstanten 30 fps laufen, da wie bei der Tickrate pro Bild deine Informationen aktualisiert werden.
rate
Rate gibt an wieviel Bandbreite du cl_updaterate und cl_cmdrate zur Verfügung stellen möchtest.
10000 (rate) : 1024 ( 1 Kilobyte ) = ~ 10 Kilobyte
Ein normaler DSL 1000 Anschluss kann bis zu 128 Kilobyte pro Sekunde erreichen, rein theoretisch könnte also ein DSL 1000 Anschluss ein Wert von maximal 131072 erreichen. Jedoch werden niemals soviele Daten verschickt. Was der besste Wert genau ist, ist schwer zu beantworten, da du immer unterschiedliche viel Bandbreite benutzt. Meiner Erfahrung nach ist ein Wert von rate 25000, was ungefähr 24 KB/sec vollkommen ausreichend und wird im Spiel nie ausgereizt.
Das Zusammenspiel der rates
Zusammenfassend möchte ich betonen, dass der Netcode wirklich nur gut funktioniert, wenn die Netsettings aller Spieler den selben Werten entsprechen und auch von allen erreicht werden können. Die meisten Internetanschlüsse dürften wohl den Wert von cl_updaterate 100 schaffen. Jedoch sind die meisten Computer immernoch zu schwach, um die cl_cmdrate 100, also die konstanten 100 fps, zu erreichen. Solange die meisten Spieler diesen Wert nicht erreichen, macht eigentlich auch cl_updaterate 100 keinen Sinn. Denn wenn zum Server nur alle 20 ms (50 fps oder auch cl_cmdrate 50) ein Paket geschickt wird, aber alle 10 ms ein Paket angefordert wird, erzeugt man eigentlich nur mehr Traffic, als die erhoffte Verbesserung. Dabei kommt es gerade bei nicht erreichbaren Settings zu einem schlechten Spielgefühl, da die Werte immer wieder schwanken und man manchmal das Gefühl hat, man trifft alles und beim nächsten mal der Gegner einfach nicht umfallen will. Mit konstanten 100 fps wie bei 1.6, wird auch der Netcode von Counter-Strike: Source mit unseren jetztigen Settings perfekt funktionieren.
cl_interpolate, cl_interp, lag compensation
Wie du schon erfahren hast, werden alle Informationen vom Server zu dir in Paketen geschickt. Da wie im ersten Abschnitt beschrieben, du dich nicht auf deinem Computer bewegst, sondern die Informationen erst von dir zum Server geschickt werden müssen und dann wieder zurück, hinkst du immer den Paketen vom Server hinterher. cl_interpolation 1 setzt dich in der Zeit zurück, damit neue Pakete ankommen können und du nicht auf diese erst warten musst und dadurch Ruckler vermieden werden. Das gesamte Spiel wird sozusagen gebuffert und vorhande Informationen werden absichtlich erst später zu euch geschickt. Damit die Interpolation korrekt funktioniert, muss cl_interp an den Wert von cl_updaterate eingstellt werden.
1000 Millisekunden (1 Sekunde) : 20 Pakete = 50 Millisekunden
Der Standardwert von cl_updaterate ist 20. Das heißt, alle 50 ms erreicht dich ein neues Paket. Damit die Bewegungen, Animationen zwischen zwei Paketen berechnet werden kann, müssen wir zum ersten Paket zurück. Wieviele Millisekunden die Interpolation zurück geht, steuert also cl_interp. Ein Wert von cl_interp 0.05 bringt dich die besagten 50 ms zurück zum ersten Paket. Valve setzt hier auf Nummer Sicher und setzt dich sogar zwei Pakete zurück. Dies entspricht den Standardwert von cl_interp 0.1, also 100 ms. So kann sogar ein Paket verloren gehen, ohne das die Interpolation aussetzt.
Snapshot steht gleich bedeutet für ein Paket
Also ist alles was du auf deinen Computer siehst 100 ms (bei cl_interp 0.1) vorraus gegenüber dem Server. Damit du nicht auch vorraus aimen musst, gibt es die serverseitige lag compensation (sv_unlag 1), die diesen Fehler behebt. Sagen wir mal, du schiesst auf ein Gegner zur client time 10.15 (command execution time). Die Feuerinformation wird mit dem nächsten Paket verschickt und während die Information zum Server gelangt (Ping), läuft der Gegner natürlich weiter. Wenn dann das Paket zur server time 10.20 (current server time) ankommt, würde der Schuss nicht registriert werden, da sich der Gegner schon weiter bewegt hat. Und dies obwohl du genau auf dem Models drauf warst. Genau dieser Fehler wird eben von der serverseitigen lag compensation behoben. Das lag compensation System speichert für ungefähr 1 Sekunde (dies kann mit sv_maxunlag geändert werden) alle letzten Positionen der Spieler. Wenn ein Befehl ausgeführt wird, wie der Schuss zum Beispiel, errechnet der Server wann der Befehl ausgeführt wurde.
Command Execution Time = Current Server Time - Client Latency (Ping) - Client View Interpolation (cl_interp Wert)
Wenn das Paket beim Server ankommt, werden alle Spieler zu der Position zurück gesetzt, wo sie zur command execution time (zum Augenblick wo du abdrückt hast) waren. Wenn der Befehl korrekt ausgeführt wurde, werden die Spieler wieder zur aktuellen Position verschoben. Du kannst dir mit sv_showimpacts 1 anzeigen lassen, wo sich die Hitboxen befinden.
Die blaue Hitbox ist die auf dem Server und die rote Hitbox ist die auf deinen Computer. Logischerweise hinkt die blaue Hitbox immer der roten hinterher. Umso besser die Verbindung zum Server ist, umso näher sind die beiden Boxen zusammen. Genau dies versuchst du zu verbessern mit den Netsettings. Das Model läuft inübrigen deshalb vor den Hitboxen, weil die Interpolation die 100 Milliesekunden buffert. Vergesse in diesen Moment nicht, dass der Server den cl_interp Wert automatisch abzieht. Würdest du auf die Hitbox anstatt auf den Model schiessen, würde der Treffer nicht registriert werden.
cl_interpolate 1 versus cl_interpolate 0
Aus der Erklärung von Valve heraus dürfte es zwischen cl_interpolate 1 und cl_interpolate 0 keinen Unterschied in der Trefferregistrierung geben, jedoch ist von vielen Spieler das gegenteilige zu lesen. Ich möchte aber diesen Artikel zu keiner int1 vs int0 Diskussion verkommen lassen, sondern einfach etwas mitgeben. Letztlich ist es zu dieser Diskussion einfach gekommen, weil Valve Bugs im Netcode hatte und längst noch nicht alle bekannten bugs gefixt hat. Sollte irgendwann alles gefixt sein, dürfte auch kein force mehr nötig sein.
cl_predict, cl_smooth, cl_interp_all
Wenn du einen Schritt nach vorne machst, muss die Informationen mit dem nächsten Paket zum Server geschickt werden und dann wieder zu dir zurück. Umso höher dein Ping ist, umso länger dauert dies zum Server und das Spiel ist gerade mit höheren Pings schlechter spielbar. An genau diesem Punkt setzt cl_predict ein. Wenn du einen Schritt nach vorne machst, verhält sich dein Computer als ob es der Server wäre und setzt dich sofort nach vorne und vergleicht dies später mit dem ankommmenden Paket vom richtigen Server. Sollte die Vorhersage/prediction falsch sein, gibt es einen prediction error. Dies kann mit cl_showerror 1 angezeigt werden. Wenn ein Fehler zustande kommt, wirst du an die korrekte Position verschoben.
Dies passiert sehr direkt und kann verwirrend sein, weshalb man mit cl_smooth 1 entgegen wirken kann. So wirst du etwas langsamer zur korrekten Position verschoben. Mit cl_smoothtime wird angegeben wie lange cl_smooth für die Verschiebung Zeit hat. Die Vorhersage funktioniert nur perfekt wenn der Computer alle Informationen hat, die auch der Server hat, was aber nicht der Fall ist. Dadruch funktioniert die Vorhersage auch nur für dich und kann nicht bei anderen Spieler angewendet werden. Deshalb ist immernoch die Interpolation für die anderen Spieler nötig.
Im Gegensatz wie viele Denken hat cl_interp_all nichts direkt mit cl_interp & cl_interpolation zu tun, sondern steht im Zusammenhang von cl_predict. Wie du weisst, wird bei aktiviertem cl_predict deine Bewegung sofort umgesetzt, als ob du auf dem Server spielst. Dabei wird alles vorhergesagt, worüber cl_predict Informationen hat. Zumindest war es so vor cl_interp_all. Bei deaktiviertem cl_interp_all wird der neue Code eingesetzt und es wird nur noch das predicted was auch wirklich nötig für dich ist.
Der Netgraph
fps: Zeigt dir an, wieviele fps (Bilder pro Sekunde) du hast.
ping: Zeigt dir deinen durchschnittlichen Ping an.
in/out: Zeigt dir, die Größe deines letzten erhaltenen und gesendeten Paketes, in Bytes an.
in/out: Zeigt dir deine verbrauchte Bandbreite an.
in/out: Zeigt dir an, wieviele Pakete du die Sekunde erhälst (Tickrate des Server) und verschickst (ist von deinen fps abhängig).
loss: Zeigt dir an, ob Pakete verloren gegangen sind.
choke: Zeigt dir an, dass du mehr Daten angeforderst hast (zu geringe Tickrate <100) oder verschicken möchtest (zu wenige fps <100), als vorhanden sind.
Wie lauten die besten Settings?
Für diese Werte benötigst du einen Internetanschluss der mindestens 30 Kilobytes pro Sekunde zur Verfügung stellen kann.
cl_updaterate 100
cl_cmdrate 100
rate 25000
cl_interp 0.01
Standardwerte die nicht verändert werden müssen:
cl_interpolate 1
cl_interp_all 0
cl_lagcompensation 1
cl_smooth 1
cl_smoothtime 0.1
cl_predict 1
fps_max 101
Achtung: Neuerdings gibt es den Wert:
cl_interp_ratio
Ist dieser Befehl aktiviert, wird ein passender Wert für cl_interp automatisch mit folgender Formel errechnet: cl_interp_ratio/cl_updaterate=cl_interp. Für die hier empfohlenen Settings also: 1/20 = 0.05 - Da der Wert für cl_interp jetzt auf die Art ermittelt wird, ist der "cl_interp" kaum noch von nutzen?!
Der Member "Jaybee" muss aufgrund von Cheating den Clan verlassen.
Sein Steamacc wurde außerdem von Valve gesperrt (VAC-Ban)
Wir haben eine Null-Toleranz-Politik im Umgang mit Cheatern.
Clan-Ausschlüsse werden unter keinen Umständen zurückgenommen.
Nach langen Planungen wurde heute entschieden, der Homepage einen neuen Glanz zu verpassen.
Dies sollte mit sogenannten "Addons" geschehen, die der Homepage neue Funktionen verleihen.
Am heutigen Tage wurden schon einige Erneuerungen getätigt, in den nächsten Tagen sollen weitere folgen.
Hier liste ich die Erneuerungen an der Homepage einmal auf:
Trainingsplaner:
Ab sofort besitzt unsere Homepage einen fast funktionellen Trainingsplaner. In den nächsten Tagen wird dieser noch "entbuggt" und daraufhin kann jeder Sqaud seine Trainings in dieser Liste eintragen. Dies verleiht eine verbesserte Organisation.
Away Caller:
In dem sogenannten "Away Caller" können die Member ihre inaktiven Zeiten + Grund eintragen. Dies ist für das Management sehr nützlich, falls es über Inaktivitäten einiger Member verwundert ist und diese die Abmeldung versäumt haben.
Sqaudpics:
In den nächsten Tagen werden wir versuchen der Page unter dem Menüpunkt "Members" mit neuen Sqaudpics neuen Glanz zu verpassen. Des weiteren wird warscheinlich noch die Memberansicht verändert.
Weitere Addons folgen in den nächsten Tagen und werden in dieser Liste näher erläutert.
Nun noch einmal die neusten Informationen zur Aktivität unseres Teamspeak-Servers.
Da unser Server Hoster ein Restart Problem besitzt, versuchen Sie dieses zu beheben.
Nun überlegt das Mangement über einen neuen Hoster nach. Anfragen an diesen wurden schon gestellt.
