Registered: 528 |
Members On: 0 |
Guests On: 16 |
Today: 4.468 |
Month: 88.938 |
Total: 3.463.374
| W | M | D | M | D | F | S | S | ||||||||||
| 14 | 1
|
2 | 3
|
4 | 5
|
6 | |||||||||||
| 15 | 7
|
8
|
9
|
10 | 11 | 12 | 13
|
||||||||||
| 16 | 14 | 15 | 16 | 17 | 18
|
19 | 20 | ||||||||||
| 17 | 21
|
22 | 23 | 24
|
25
|
26
|
27
|
||||||||||
| 18 | 28 | 29
|
30 | ||||||||||||||
| Forum - Thema | ||||
| Neue Themen | Aktive Themen | Bestenliste | Statistik | Suche |
| Forum » 1.0 Games Board » Counter Strike » Wissenwertes | ||||
Antworten: 0
Seite 1 |
|
 en!gForum-Mod  Beiträge: 700 |
# Thema - 10.03.2006 um 17:58 Uhr
Wissenswertes [1] Der Scoreboard-Ping Quote: Was viele nicht wissen ist, dass der im Scoreboard angezeigte Ping von Half-Life/Counter-Strike nicht korrekt errechnet wird. In der Tat steigt dieser Ping mit optimalen Settings im Extremfall um bis zu 40% an, ist jedoch konstant. Die einzige Tatsache, welche zeigt, dass man eine gute Verbindung hat, ist die, dass der im Scoreboard angezeigte Ping nicht so sehr schwankt - hat man mit den Default-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! [2] Der Choke-Wert im Netgraph Quote: 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 "CL_FlushEntityPacket" - 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. [3] Der Loss-Wert im Netgraph Quote: 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 Kabels. [4] cl_cmdbackup - Warum manchmal 60, manchmal 0? Quote: cl_cmdbackup bewirkt, dass ein Datenpaket öfters gesendet wird, bis schliesslich vom Server die Empfangsbestätigung eintrifft. Dies bewirkt automatisch, wenn man cl_cmdbackup benutzt, dass die benutzte Bandbreite sich in beide Richtungen erhöht - bei dem Oberwert 60 wird ein Datenpaket zwar niemals 60x zusätzlich geschickt, da die Empfangsbestätigung mit sehr hoher Wahrscheinlichkeit schon viel früher eintrifft, jedoch wird es je nach Verbindung bis zu 5-20x dupliziert - bei höheren Pings noch öfters, da so die Antwortzeiten länger sind und CS somit eine längere Zeit keine Empfangsbestätigung für ein Paket enthält --> es schickt es noch öfter, bis die Bestätigung endlich eintrifft. Kurz gesagt sollte man nun, wenn man eine wirklich gute Internetanbindung hat, cl_cmdbackup auf 0 setzen - warum? So werden keine Zusatzpakete geschickt, was zur Folge hat, dass für die originalen Pakete viel mehr Bandbreite zur Verfügung steht. Durch diese bessere Verfügbarkeit werden die originalen Pakete etwas rascher versendet - so, als ob man nicht 500 Autos auf einer Autobahn direkt hintereinander fahren lässt, sondern nur 10. Aber woran erkennt man, dass man eine gute Verbindung hat? Allgemein können die Leute mit T-DSL und Fastpath glücklich sein - denn bei jedem, wo es freigeschalten wurde, ist eine gute Leitungsqualität sicher. Nun gibt es aber noch einen weiteren Faktor, wenn es um die Verbindungsqualität geht: die Qualität der Anbindung des Servers, auf dem man spielen möchte. Da man diese nun leider nicht beeinflussen kann, wäre es also möglich, dass bei guter Leitungsqualität und cl_cmdbackup 0 einige Datenpakete einfach im Datennirvana verschwinden, was zur Folge hat, dass manche Kommandos, unter anderem Schüsse, nie beim Server ankommen. Was kann man da tun? Je nach Server sollte man in diesem Fall dann cl_cmdbackup erhöhen - erstmal mit dem Defaultwert 2 anfangen, um zu sehen, ob das das Problem bereits zu lösen vermag. Ist dem nicht so, kann man cl_cmdbackup direkt auf einen Extremwert erhöhen, da man dann mit leider extrem hoher Wahrscheinlichkeit eine schlechte Verbindung zum Server hat, welche der Vervielfachung der Datenpakete bedarf, damit man auf dem Server wie gewohnt spielen kann. Natürlich wird dadurch die Bandbreite mehr beansprucht, was zur Folge hat, dass die verfeuerten Schüsse nicht ganz so rasch ankommen, als bei cl_cmdbackup 0. Meist sind die guten und schlechten Serververbindungen zu bestimmten Servern permanent gleich, man kann sie in diesen Fällen also nicht durch eine Neueinwahl beim Provider verändern - nur in ein paar wenigen Fällen, wo die Probleme direkt von dem jeweiligen Serveranbieter kommen, kann man darauf hoffen, dass der Serveranbieter die Probleme beheben kann. Der "Loss"-Wert im Netgraph muss, um das noch einmal zu erwähnen, nicht zwingend ansteigen, wenn man einen schlechten Server erwischt hat - dieser ist leider ziemlich fehlerhaft programmiert, so dass man nur in viel extremeren Fällen überhaupt erst Packetloss angezeigt bekommt. ------------------ |
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
30.04.2025 um 23:56 Uhr nach UTC +1 [Sommerzeit] - Load: 25ms