PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Immer noch Laggs ?


Garack
14.12.2006, 01:16
HI! Bei mir laggen immer noch trotz dem Beta Server die Gegner und Fahrzeuge und auch Mitspieler..Helis beim mitfliegen und Fahrzeuge beim mitfahren laggen- Also ich meine den typischen Netlagg. Als wenn ein paar Informationen fehlen und der Spieler ein klein wenig nach vorne ruckelt.

Die Pings sind ok, Kein desync..Frames über 30.DSL 6000 Hier, keine andres Spiel laggt. Keine Progs im Hintergrund oder Antivirescanner..Traffic ist völlig ok..

Seltsamerweise meinen manche bei Ihnen laggt es gar nicht...Eure Erfahrungen ?

Ich finde es so kaum spielbar. Klar treffe ich was..aber das ganze ist halt nicht geschmeidig..

Oder ist der Netcode generell so schlecht ??

Ich hoffe da kann man nachbesser..

GlasSchwert
14.12.2006, 03:49
Vorab: Ich hab ebenfalls eine 6Mbit Leitung - 1&1.

Ich hab da ähnliche Erfahrungen gemacht. So richtig lagfrei ist es leider nicht; trotz 30-60ms Ping. Nach meiner Meinung werden zuviele Daten übertragen. Nach einem Test mit einem Freund haben wir festgestellt das
in Armed Assault eigentlich alle Bewegungsabläufe übertragen werden.
Ich meine damit eher die "Sinnfreien" ala Kopf- und Waffenbewegungen auf allen Achsen, die feinsten Bewegungen des Characters usw. Das hätte man sich ja schon sparen können.

In anderen Spielen wird dafür extra eine Option für die Datenrate oder LAN angeboten. Zudem scheint der NetCode
auch "wichtige" Daten ala Score per UDP zu übertragen. Ein bissel TCP hät dort net geschadet. Denn dort scheinen desöfteren mal Fehler aufzutreten. Mein Bruder und ich haben da nämlich öfter mal unterschiedliche Scoreboards. :p Für Clanwars, vorallem wenns mal in der ESL ist; ist das nicht gerade geeignet. :zahn:

Im Endeffekt muss ich auch gestehen das es nicht unbedingt lagfrei ist.
Ich erwische mich nämlich desöfteren mal beim Wechsel des Servers wegen Lag. :ugly: Aber unspielbar ist es nicht...

flickflack
14.12.2006, 11:05
Vorab: Ich hab ebenfalls eine 6Mbit Leitung - 1&1.

Ich hab da ähnliche Erfahrungen gemacht. So richtig lagfrei ist es leider nicht; trotz 30-60ms Ping. Nach meiner Meinung werden zuviele Daten übertragen. Nach einem Test mit einem Freund haben wir festgestellt das
in Armed Assault eigentlich alle Bewegungsabläufe übertragen werden.
Ich meine damit eher die "Sinnfreien" ala Kopf- und Waffenbewegungen auf allen Achsen, die feinsten Bewegungen des Characters usw. Das hätte man sich ja schon sparen können.

Das ist durchaus beabsichtigt und nicht sinnfrei. Den Server sämtliche Berechnungen durchführen zulassen, hat nämlich den entscheidenen Vorteil, dass das Motto: "Keine Instanz ist ausser dem Server vertrauenswürdig!" der Spieleentwicklung fast vollständig umgesetzt worden ist.

In anderen Spielen wird dafür extra eine Option für die Datenrate oder LAN angeboten. Zudem scheint der NetCode
auch "wichtige" Daten ala Score per UDP zu übertragen. Ein bissel TCP hät dort net geschadet. Denn dort scheinen desöfteren mal Fehler aufzutreten. Mein Bruder und ich haben da nämlich öfter mal unterschiedliche Scoreboards. :p Für Clanwars, vorallem wenns mal in der ESL ist; ist das nicht gerade geeignet. :zahn:

Wie willst Du denn an die Score kommen, wenn der Server als einzige Instanz die alle Objekte und ihren jeweiligen Status kennt, diese nicht überträgt? Sollen alle Clients selbst zählen, so dass sich jeder sein Ergebnis schönen könnte?! Scheinbar passiert das in dem Skript. Normalweise stimmen die Punkte aufm Scoreboard, also das hab ich bis auf irgendwelche Anderson-Gunship-Deathmatches unter OFP noch nie erlebt ;)

Der Unterschied zwischen UDP und TCP ist, dass TCP ein verbindungsorientiertes Protokoll ist. Das heisst, dass jede Paket-Kommunikation getätigt und überprüft werden muss. Ohne ein "Okay" geht's nicht weiter, was eine zwingende 2-Wege-Kommunikation erfordert. Wenn jetzt irgendein Paket halb ankommt, muss es mit dem ganzen Prozedere wieder übertragen werden, so dass eine Dauerloop entstehen kann, es sei denn man implentiert eine eigene Art von Garbage-Collector - denn TCP ist ein Protkoll mit implementierter Fehlerbehandung.
Im Mulitplayer ist es nunmal so, dass das Runterfallen eines Paketes verkraftet werden kann, weil mit dem nächsten, der Zustand erneut übertragen wird, es läuft im Millisekundenbereich! Das Syncen übernimmt der Server, der eben aus diesem Grund auch alle Berechnungen durchführen muss, um im Falle eines Paketverlustes, das verlorengeganene Paket zwar nicht wiederholt sendet, aber einfach das nächste, in dem der aktuelle Zustand eh wieder gespeichert ist.

Grob gesagt ist UDP entwickelt worden um die Kommunikation dort zu beschleunigen, wo es total Brust ist, ob jetzt ein Paket ankommt oder nicht. Onlinespiele sind dafür ein gutes Beispiel, oder eben auch VoIP.
Ungeeignet für Übertragungen ist UDP dann, wenn eine Fehlerkorrektur erwünscht ist und die Daten tatsächlich 1 zu 1 am andere Leitungsende ankommen sollen. Siehe HTTP & FTP etc. Auf Grund der Implementierung ist TCP einfach zu langsam für große Datenmengen in Onlinespielen. Wo man vllt noch ein 16 Mann Q3 mit TCP basteln kann, wird's bei einem OFP und ARMA eben schwer. Dafür cheatet es sich aber auch in Q3 wesentlich einfacher, was natürlich nichts mit dem übertragenden Protokoll zu tun hat.

Das große Lagproblem OFPs war es, dass in den ersten Version DirectPlay aus der DirectX-Familie benutzt worden ist, dessen Implementierung afaik auf TCP beruht(e). Ich glaub mit Resistance kam dann eine eigene BI-Unix-Socket-Implementierung die auf UDP aufsetzte.

Stell Dir mal vor ein Paket wird via TCP immer hin und her geschickt, weil es zu einem Fehler kam. So - nach 20 Sekunden wird das Paket nun erfolgreich verschickt und kommt in einer Situation an, in der Du schon längst woanders bist - was tun?! Damit Du das Spiel nicht versaust in dem Du sowas zulässt, verwirfst Du das Paket einfach. Insofern kannste gleich UDP nehmen!

Im Endeffekt muss ich auch gestehen das es nicht unbedingt lagfrei ist.
Ich erwische mich nämlich desöfteren mal beim Wechsel des Servers wegen Lag. :ugly: Aber unspielbar ist es nicht...

Laggen tut es an manchen Stellen das stimmt, aber ich glaub das ist auch ein OFP-ähnliches Problem. Wenn du einmal pro RenderScene() die Netzwerkkommunikation handlest und Dein Client kommt mit dem Wald nicht klar, dann braucht der eben länger um das Paket zu senden und ein neues zu empfangen, als Kisten, die schneller sind und daher dementsprechend den Sync selbst garantieren. Schnelle Systeme empfinden dann die lagsameren als Lagger. Das kann natürlich in Fahrzeugen kaskadierend wirken, weil Du dich als Mitfahrer im Szenengraph neusortierst und abhängig von dem Menschen bist, der das Fahrzeug steuert. Wenn der jetzt einen langsamen Compu hat, dann dauert der Weg von ihm zum Server und von dem zu Dir, eben deutlicher länger, was dann Du als Lag des Servers auffasst, obwohl der gar nichts dafür kann.

Desyncs und Lags haben vielfältige Ursachen und sind nicht von Hause aus ein Systemproblem des Servers. UDP ist für Echtzeitonlinespiele bei der Kommunikation die beste Wahl genau dann, wenn es 1. unwichtig ist, ob ein Paket verloren gegangen ist und 2. wenn es auf Schnelligkeit und Sync ankommt - bei rundenbasierten Spielen kann man aber auch locker TCP nehmen, wäre da auch wichtiger ;)

Edit: Wenn der Server an einem Heim-DSL-Anschluss hängt, dann ist meist der geringe Upstream am Syncverlust und Lag schuld. Ich sag's nur, weil im Moment ziemlich viele Server an Heimanschlüssen zu hängen scheinen ^^

Garack
14.12.2006, 12:22
SAuber!

Das nenne ich mal ne kompetente Antwort. Da hab ich dazugelernt ! Danke !

Eine Frage noch : Was genau beschreibt denn der Desync in der Ping Anzeige von ArmA ? Die verlorenen Pakete ?

Das alles würde erklären warum ich immer zuckelnde Spieler sehe und auch BeifahrerLaggs(a la Söldner) ziemlich krass sind obwohl die Pings ok sind.(Und auch kein Desync bei keinem Mitspieler angezeigt wird).

Ich spiele zwischen 20 (In ExtremsituatiOnen aber nur) und 50 Frames auf 1280, Schatten aus, AA normal, AF aus, Rest auf Normal außer Shader hoch.

mit einer hochgetakteten x1800XT 512MB einem AMD 4000+ und 2 GB DDR500 RAM@500 mit maxmem=1000 und einer Raptor HD.

Nach der obigen erklärung fallen die Laggs weg, wenn ich sagen wir konstant 50 Frames habe oder ?

GlasSchwert
14.12.2006, 13:55
Danke, aber ich weiss was TCP/UDP ist. Ich selbst bin in der Entwicklung beruflich tätig. Ich wollte damit nur sagen das viele "wichtige" Strings nicht übertragen werden weil sie wahrscheinlich im UDP spurlos verwinden. Das Spiel an sich sollte "natürlich" auf keinen Fall in UDP geschrieben werden; das war ja der totale Reinfall - das ist ja logisch. Aber Login, Scores oder andere wichtige Elemente. Das hab ich dort oben damit sagen wollen, sorry das ich mich unverständlich ausgedrückt hab. Es kann natürlich sein das die Packete nicht verschwinden sondern ansich das Spiel bzw. die Scripts buggy sind...ja, das könnte wahrlich sein.


Das ist durchaus beabsichtigt und nicht sinnfrei. Den Server sämtliche Berechnungen durchführen zulassen, hat nämlich den entscheidenen Vorteil, dass das Motto: "Keine Instanz ist ausser dem Server vertrauenswürdig!" der Spieleentwicklung fast vollständig umgesetzt worden ist.

Es ist in unserer Zeit aber einfach nicht Möglich solche Kapazitäten für "gross angelegte" Spiele ala über 100 Spieler zu nutzen. Vielleicht in 5 Jahren oder mehr. Eine kleine Option für die Bandbreite wär für einige Nutzer gar nicht mal so übel gewesen; wie´s bereits erwähnt in vielen anderen Spielen verfügbar ist.

Naja, ich will mich da nicht drum streiten. Du programmierst so, ich so und BIS eben so. :D Die werden schon wissen wie man sowas designed & programmiert. Wenn´se sagen die haben nen guten Netcode; dann hamse auch einen. ;)

Fazit: Es lagt halt noch...auch wenn nur 4 Spieler spielen. Wahrscheinlich liegst auch daran das einige Computer einfach zu schwach sind und immer wieder Aussetzer und Ruckler haben wo´s den Ping kurzfristig hochdrückt. Bums, Beng, Out. :D

GlasSchwert
14.12.2006, 14:23
EDIT:

Man kann nicht lange editieren, also muss ich nen neuen Beitrag aufmachen. Es heisst: ***auf keinen Fall in TCP*** - nicht UDP ;)

Garack
14.12.2006, 16:13
Ok, aber meine Fragen sind noch (halb)offen.

flickflack
14.12.2006, 17:00
SAuber!

Das nenne ich mal ne kompetente Antwort. Da hab ich dazugelernt ! Danke !

Eine Frage noch : Was genau beschreibt denn der Desync in der Ping Anzeige von ArmA ? Die verlorenen Pakete ?

Das alles würde erklären warum ich immer zuckelnde Spieler sehe und auch BeifahrerLaggs(a la Söldner) ziemlich krass sind obwohl die Pings ok sind.(Und auch kein Desync bei keinem Mitspieler angezeigt wird).

Ich spiele zwischen 20 (In ExtremsituatiOnen aber nur) und 50 Frames auf 1280, Schatten aus, AA normal, AF aus, Rest auf Normal außer Shader hoch.

mit einer hochgetakteten x1800XT 512MB einem AMD 4000+ und 2 GB DDR500 RAM@500 mit maxmem=1000 und einer Raptor HD.

Nach der obigen erklärung fallen die Laggs weg, wenn ich sagen wir konstant 50 Frames habe oder ?

Was genau den Desync beschreibt, kann ich nur vermuten, weil der Netcode Closed-Source ist. Das müssen kompetentere Leute erklären ;) Ich vermute es sind Paketverluste.

Es wäre interessant zu wissen, in welchem Intervall die Pakete verschickt werden. Alles von den Frames abhängig zu machen, bringt in der Spieleprogrammierung eine Menge Probleme und ist glaube ich bei ArmA, auch für die Kommunikation so nicht implementiert.

Stell Dir mal vor, die Bewegungen Deines Avatars wäre abhängig von den Frames, dass heisst Du baust Dein Spiel so, dass je nach erkannter Bewegung, in jedem Frame die Bewegung berechnet wird.
Würde man das jetzt genau so, einmal in der DisplayLoop des Spieles, also einmal pro Frame machen, dann würde das für Leute mit 50 FPS bedeuten, das ihre Tastatur und ihre Bewegung 50x pro Sekunde abgefragt und berechnet wird. Der Mensch mit nur 15 FPS, hätte dementsprechend einen netto Verlust von 35 FPS, er hätte also 35 Abfragen und Berechnungen pro Sekunde weniger. Das bedeutet, der Spieler mit den 50 FPS ist schneller und hat Vorteile - erklärt sich aber denke ich auch von alleine.

Also benutzt man Timer für Bewegungen in der Szene, die man zum Syncen einsetzt. Das heisst, die Bewegung wird nicht mehr an die Frames gekoppelt, sondern an den Timer, der bei allen gleich läuft, das System Zeit ist physikalische Grundlage ;) Es wird so bspw. die Tastatur bei allen alle 20 ms abgefragt um Fairness herzustellen.

Selbst wann man nun die Kommunikation an einen Timer koppelt, löst das trotzdem nicht das Netzwerk-Sync-Problem, das sukzessive entsteht. Es kann sein, dass erst gezeichnet wird und dann die Position verschickt, oder aber es wird erst die Position berechnet, verschickt und dann lokal gezeichnet. Total egal: die erste Variante ist sofort wieder von der Zeichengeschwindigkeit der lokalen Maschine abhängig, die zweite Variante nach dem startenden Frame. Selbst wenn man das parallelisiert, wird das Paket erste veschickt, wenn ein anderer Schritt im Programm, als auslösendes Kriterium zum Einsatz kommt - ergo: Latte wie Hose. Das Problem bleibt -> Schleifende Clients sorgen für Desync. Wenn alle gute Pings haben, der Server was aushält und über eine ordentlichen Anbindung verfügt, und alle ohne große Ruckler, oder andere Flaschenhälse verbunden sind, läufts auch ruckelfrei - sollte es zumindest. Denn eins kann man sagen: Wenn es trotz der Auflösung aller physikalisch bedingten Flaschenhälse laggt, dann ist der NetCode scheisse - egal welcher Name da auf dem Produkt steht.

Es ist in unserer Zeit aber einfach nicht Möglich solche Kapazitäten für "gross angelegte" Spiele ala über 100 Spieler zu nutzen. Vielleicht in 5 Jahren oder mehr. Eine kleine Option für die Bandbreite wär für einige Nutzer gar nicht mal so übel gewesen; wie´s bereits erwähnt in vielen anderen Spielen verfügbar ist. Klar, aber dabei gilt es eine performante Lösung zu finden, die on-the-fly decoden und encoden kann. 'Nen schneller PackAlgo kann auf diese Packetgröße durchaus effektiv angewendet werden, zumal Suma oder Maruk (keine Ahnung genau) schon gesagt hat, dass sich die Paketgrößen im Gegensatz zu den Größen in OFP verringert haben.

Es gibt auch keinen wirklichen Bedarf in anderen Spielen, solche Datenmengen zu übertragen, die Komplexität ist schlicht nicht gegeben. Die Anpassung der Datendurchsatzrate, ist eventuell auch nur eine Art Komprimierung im Hintergrund anderer Spiele.

Selbst wenn man weiss wie man programmiert, zaubert einem das aber noch lange nicht die Fähigkeiten zu sauberen und optimiertem Code in den Körper ;)

Die UDP/TCP Erklärung war auch für alle die gedacht, die sich nicht damit auskennen und einen kleine erklärenden Einblick lesen wollen. Jemand der sich damit auskennt, der schweigt und überliest ;)

Garack
14.12.2006, 18:00
Hmm, ich hoffe der Netcode is nicht schuld..Grade eben: 45 Frames in nem BMP and der Kanone frei sicht auf ein Feld, Der Feind laggt da nur so durch..immer kleine vorwärtssprünge--Echt müllig sowas--Pings waren ok bei allen.

flickflack
14.12.2006, 18:10
Naja, der Netcode war bei OFP bis 1.46 auch totaler Müll. Ab 1.75 und Resistance fand ich das dann durchaus in Ordnung. Hoffe wir mal, es dauert diesmal nicht so lange mit den Optimierungen - falls da was überhaupt etwas kommt. Ich glaub's aber schon :D

Garack
15.12.2006, 14:43
Ich hoffe auch ... Schauen wir mal.

Garack
16.12.2006, 20:34
Also selbst im COOP Mode (Size the Base) zuckelt die KI....Kein desync,gute Pings, 60 Frames---Was nun ? Patsch 1.2 is drauf. Kann nicht an einer übertakteten CPU liegen oder ??? Laggt die KI auch so bei Euch ? oder die anderen =?

mckee14
18.12.2006, 10:08
jep, die "beamende" KI ist immer mal wieder mit von der partie. teilweise startet der server und die KIs bewegen sich flüssig und plötzlich beginnen sie rumzuzappeln.

daher bediene ich mit vorliebe das m249, LOL. "ungefähr" vorhalten, ein magazin durchrattern und dann 20 sek. beobachten wie immer mal wieder irgend einer irgendwo zusammenklappt

Garack
18.12.2006, 13:47
Tja, Ich glaub ich steig auch auf die Knarre um...Und hoffe dass die Jungs von Bis nicht so einen Mist wie Söldner wiederholen.