Debug-Modus ?!

[papa69]

erst einmal recht herzlichen Dank für die Antwort(en)

...gehe ich recht in der Annahme, das eine Änderung der ~config für ein laufendes Spiel nicht mehr relevant ist ??

..aber neuer Monat - neues Spiel..

[Dwachs]

@Paco: selbes Problem wie oben, Client war zu schnell.

Original von papa69
...gehe ich recht in der Annahme, das eine Änderung der ~config für ein laufendes Spiel nicht mehr relevant ist ??

Nein, all diese Netzwerkeinstellungen werden immer aus der simuconf.tab gelesen. Also einfaches Neustarten von Client/ Server reicht.

[Hajo]

Original von Dwachs
Das dumme bei diesen Synchronisationsfehlern ist, das man vorher nicht weiss, was man loggen soll. Die '-debug n' Parameter helfen da wenig.

Ich hatte nie so recht Vertrauen in dieses synchron-halten der Clients. Irgenwann schrieb ich mal, dass ich der Meinung bin, dass das Prinzipbedingt nie klappen wird. Kann aber schon gut 10 Jahre her sein, dass ich das schrieb, zu einer zeit als die TTDPatchler versuchten eben dieses Verfahren stabil zu bekommen ...

Das war unter anderem auch der Grund, warum ich euch für die Netzwerkimplementierung nie gelobt habe. Dann hat man mir vorgworfen, ich würde die Arbeit nicht wert schätzen. Ihr habt da sehr viel Aufwand hineingesteckt, das ist wahr, aber das Verfahren ist auch das schwierigste von allen. Ich denke man hätte das besser lösen können, und mit weniger Aufwand.

Ich wollte das nur als Erklärung anmerken, warum ich die aktuelle Netzwerkimplementierung in Simutrans nie gelobt habe. Meiner Meinung nach hätte man es so machen sollen:

Es hätte gericht, die Clients als reine Anzeigeprogramme zu bauen, und den jeweils sichtbaren Auschnitt der Karte vom Server streamen zu alssen (als Sequenz von object-ids, nicht die Grafikdaten). Das wären nur ein paar KB pro Frame, und es gäbe niemals ein desync, weil es die Karte nur einmal gibt, auf dem Server. Ausserdem entfällt der zeitraubende Download der karte, und es gibt keine Probleme mit unterschiedlichen pak-Versionen.

Neben der Anzeige hätten die Clients noch die Aufgabe geahbt, die Eingaben vom Benutzer entgegenzunehmen und an den Server zu senden. Auch hier wieder 100% desync-frei weil der Server alle Eingaben auf seiner einen Karte verarbeitet.

Das Verfahren wäre sehr robust, während das was jetzt in Simutrans drin ist, beim geringsten Fehler zerbricht.

Aber ich traue euch auch zu mit noch viel mehr Zeit und Mühe als Ihr eh schon hineingesteckt habt, das dann tatsächlich stabil zu bekommen. Es ist halt nur _viel_ mehr Arbeit als notwendig.

Nun habe ich doch etwas über meine Ideen zu Simutrans verraten, und Ihr könnt das jetzt als erste umsetzen

[prissi]

Leider sind das nicht eben ein paar kB: Bei großen Bildschirmen und rausgezoom sind das auch mal mehr als 20000 Kacheln; das dürften dann leicht 100 kB pro Frame werden. Den Server, der das an 16 Spieler streamt, den möchte ich sehen. Außerdem bräuchte dann der Server die ganze Rechenzeit, ein einfacher VPS wie jetzt dürfte da kaum reichen.

So ein Client wäre übrigens leicht zu machen. Man müsste nur simview ändern.

Fast alle Spiele, die eine (fast) statische Karte verwenden, machen das gleiche wie Simutrans, d.h. lokal ist der statische Teil und die per Algorithmen erzeugten Dinge. Nur Simutrans hat locker mehr als 1000 bewegte Objekte; da fallen Abweichungen eher auf. Außerdem hat ein first Person shooter auch nur genau ein Object, was der Server wirklich verwalten muss (nämlich den Spieler).

[Hajo]

Ja, die Bandbreitenprobleme waren damals der grund warum ich es verworfen hatte. Heute hat man jedoch mehr Bandbreite, und es werden Filme gestreamt, dann müsste auch ein Simutrans-Bild gehen. Ich weiss auch nicht warum Du auf First Person Shooter verweist, ich habe nie an einem solchen gearbeitet und keine Ahnung wie diese gemachst sind, das also ganz sicher nicht als Grundlage für meine Nachricht genommen.

So ein Client wäre übrigens leicht zu machen

Äh. Das war doch der Punkt meines vorigen Beitrags, dass es auch einfacher geht. Ihr versteift euch auf ein fehlerträchtiges und dazu noch kompliziertes Konzept.

Aber das ist jetzt ja nicht mehr mein Problem, also werde ich mich wieder in schweigen hüllen, sobald die aktuelle Unruhe hier vorüber und vergessen ist. Eigentlich wollte ich nur nach der Lizenz fragen, habe jetzt aber Probleme das Ende zu finden, und nicht mehr zu antworten, vor allem wenn auf meine Beiträge bezug genommen wird.

[Paco_m]

Um nochmals darauf zurückzukommen:

Original von Paco_m
PS: Derzeit hab ich
additional_client_frames_behind = 4
und serverseitig 2, ich setz dann letzteres mal hinauf und berichte

Hab nun serverseitig 5 Frames festgeelgt und bei mir am Client die 4 belassen, also insgesamt 9.
Die Desyncs sind weniger geworden, würde fast sagen auf die Hälfte reduziert aber es gibt sie immer noch und die ursache scheint nach wie vor zu sein, daß der Client vorausläuft - jedesmal die Meldung mit "wanted to execute in the past".

Allerdings hat das Ganze auch einen stark spürbaren Nachteil weshalb ich den Wert auch nicht weiter erhöhen möchte, die generelle Flüssigkeit des Spiels leidet sehr darunter; insbesondere Aufrufe des Fahrplanfensters eines Fahrzeuges dauern nun20-40 Sekunden während mit der vorherigen Einstellungen das Fenster sofort öffnete (außer man flog gleich wegen Desync raus versteht sich )

Man kann also nur zwischen zwei Nachteilen gewichten was dann doch eher bescheiden ist. Auf den Entropy-Servern wurde da offenbar noch großzügiger mit den server_frames_ahead gearbeitet weil dort dauert der Aufruf eines Fahrplans bis zu 5 Minuten - da akzeptiere ich dann lieber höufigere Desyncs

Auch wenns nur noch etwas hakt muß ich doch mal erwähnen, daß sich im Vergleich zu vor eineinhalb Jahren als wir das letzte Spiel laufen hatten einiges verbessert hat - wochenlang nun schon ohne einen einzigen Servercrash und mit einer deutlich größeren Karte als bei den anderen Netzwerkspielen online =)

[Dwachs]

Man kann auch server_frames_between_checks auf einen kleineren Wert (zB 8 oder 16) setzen. Dann schickt der Server seine Sync-Information oefter, und die Clients koennen ihre Geschwindigkeit besser einstellen.

[papa69]

Auch ich habe etwas mit den frame-Werten "gespielt" ... und muss auch sagen, dass das Spiel weniger "abstürzte".

Den letzten Beitrag von Dwachs werde ich auch noch versuchen...und bei Gelegenheit davon berichten...

________________________________________________________
...als Nachtrag noch: Mir kommt es so vor, dass die desyncs (schreibt man das so ??) häufiger vorkommen, jemehr Mitspieler online sind (was ja auch logisch erscheint, da ja dann auch mehr/öfter Fahrpläne, Strassen ... erstellt/geändert werden).

Falls noch Bedarf an ~.log-Dateien besteht: ich werde den Server weiterhin im Debug-Modus laufen lassen...
________________________________________________________

Auf jeden Fall hat sich die Spielbarkeit erhöht --> das freut mich sehr. Daher nochmal ein ausdrückliches [size=18]LOB, wie auf die Belange der "Spieler" eingegangen wird...