quake.de

[Badb0y]

Ab einer ISDN-Verbindung kann man Quake 3 gut spielen, 56K Modem wird nicht empfohlen.
Mit manchen Werten könnt ihr spielen "// von-bis Werte" bis euch die Einstellung am besten gefallen.

Gesamteinstellungen für die unterschiedlichen Verbindungskategorien

LAN
seta cl_maxpackets "125"
seta cl_packetdup "0" // 0-1
seta snaps "40"
seta rate "25000"

ADSL / DSL
seta cl_maxpackets "100" // 60-100
seta cl_packetdup "1" // 0-1
seta snaps "40"
seta rate "25000"

ISDN einfach & gebündelt
seta cl_maxpackets "60" // 30-60
seta cl_packetdup "1" // 0-1
seta snaps "40"
seta rate "7000" // 6200-8000

56K Modem
seta cl_maxpackets "30" // 20-40
seta cl_packetdup "1" // 1-2
seta snaps "30"
seta rate "3000" // 3000-4000


cl_maxpackets
Dieser Wert bestimmt die Anzahl der maximal vom Client verschickten Gameworldupdates pro Sekunde, dabei wird im Scoreboard ein höherer Ping angezeigt und man bekommt ein smootheres Spielgefühl, da der Server die eigenen Aktionen präziser umsetzen kann.

cl_packetdup
Wer Packetloss hat also eine schlechte Verbindung besitzt, kann durch anschalten mit Wert 1 die Packetsicherheit erhöhen.

snaps
Der Wert bestimmt, wieviele "Schnappschuesse" von der aktuellen Spielwelt auf dem Server pro Sekunde vom Client angefordert werden.

rate
Das bestimmt die Bandbreite, die der Client nutzt. Höchster Wert ist 25000. Viele Server begrenzen automatisch auf einen niedrigeren Wert.


Es lohnt sich noch mit den Befehlen cg_predictItems, cg_smoothClients und cl_timenudge auseinander zu setzen.

cg_predictItems (0,1)
Bei "1" wird vom Client entschieden, ob man ein Item aufgenommen hat oder nicht, bei "0" erhält der Client diese Information vom Server. Bei einer guten Verbindung kann man diesen Wert auf "1" setzen, bei einer schlechten Verbindung muss man jedoch mit dem Effekt rechnen, das man laut Client ein Item aufgenommen hat und das auch angezeigt bekommt, aber der Server einem jedoch den Einsatz des Items verweigert, da man laut Server dieses Item nicht besitzt.

cg_smoothClients (0,1)
Falls aktiviert (Server- wie Clientseitig) wird die Bewegung anderer Spieler fluessiger selbst wenn sie eine schlechte Andbindung an den Server aufweisen.

cl_timenudge (+Wert,-Wert)
Dieser Wert bestimmt die Verzögerung in Milisekunden zwischen Daten-Eingabe und Auswirkung auf das Spiel. Ein anderer Ping (Latenz) wird simuliert.

Gebräuchliche Werte für Onlinespieler sind -10 und -15 (5,10,15 oder 20,aber niemals höher). Wenn ein negativer Timenudge-Wert verwendet wird sollte cg_smoothclients 0 angewandt werden.
Es spielt sich anders mit einem negativen Wert, alles Gewöhnungssache.
Die meisten Gameserver haben eine Begrenzung des negativen Timenudge-Wertes eingestellt. Ein negativer Timenudge-Wert über "-20" ist nich zu empfehlen.

Positiver Wert (für LAN Spiele)
Damit kann man den Verzögerungseffekt von langsamen Internetverbindungen simulieren (kann z.B. auf LAN helfen, anfangs mit dem niedrigen Ping zurechtzukommen, indem man sich nach und nach mit Timenudge an LAN Verhältnisse rantastet). Timenudge im positiven Bereich gestattet es also dem Spieler einen Ping zu simulieren. Das bedeutet das bei einem Timenudge-Wert von +50 ein Ping von 50ms simuliert wird.

Negativer Wert (für Online Spiele)
Im Internet trifft man viele Spieler die mit einem negativen Timenudge-Wert spielen. Das hat für den Spieler den Vorteil mit einem eigentlich niedrigeren Ping zu spielen als das eigentlich der Fall ist (man spielt quasi mit dem effektiven Ping = angezeigter Ping - negativer Timenudge-Wert).
Mit einem negativen Wert holt man sich Daten "aus der Zukunft" heran - so seltsam das klingen mag.

Der Nachteil daran ist, das Bewegungen nicht mehr interpoliert werden. Gegner können für einen selbst springen und ruckeln. Auch ruckelt man selbst für Gegner bei einem zu hohen negativen Timenudge-Wert. Mitspieler finden das natürlich nicht gut, da es schwerer wird dich zu treffen.
Deswegen ist auf den meisten Gameservern eine Begrenzung des negativen Timenudge-Wertes eingestellt. Ein negativer Timenudge-Wert über "-20" ist nich zu empfehlen.

Beispiel: Bei Timenudge -10 versucht die Engine, alle Ereignisse die du siehst, um 10 ms vorauszuberechnen. Das ist einfach, wenn ein Spieler nur in eine Richtung läuft, aber wenn er die Richtung wechselt, kann es für dich aussehen, als wenn er warpt. Denn die Engine weiss nicht mehr, wann genau die Richtung gewechselt wurde.