1. #1
    Avatar von CookieButton Kam, sah und tippte
    Registriert seit
    Dec 2018
    Beiträge
    279

    Desyncs und eine Maßnahme diese evtl. seltener Auftreten zu lassen

    Hallo Community,

    ich habe mich nochmals näher mit dem Spiel beschäftigt und seine Funktionsweise im Disassembly erörtert um zu verstehen was wo und wie passiert und was man (selber) vielleicht machen kann.
    Durch diese Analyse bin ich zu folgender Funktionsweise gekommen (ich versuche das für Laien verständlich zu erklären):

    Wie ein Desync erkannt wird:
    Das Spiel arbeitet in Ticks. Man kann sich das so ähnlich vorstellen wie ein Bild von dem Spiel, das auf dem Bildschirm dargestellt wird.
    Ein Tick repräsentiert den logischen Status des Spieles (wo steht welche Einheit, was macht diese etc.).
    Sowohl in festgelegten Intervallen als auch zufällig vereinbaren alle Spielparteien, bestimmte Ticks zu vergleichen und auf Unterschiede zu testen.
    Dazu wird entweder der ganze Tick oder evtl. ein festgelegter zufälliger Teil davon (das weiß ich nicht so genau, die Hashberechnung sollte aber zumindest heutzutage aufgrund der verwendeten Art sehr sehr schnell sein) serialisiert (Speicherstände sind zum Beispiel die Karte + serialisierte Restlogik + Komprimierung zwecks Größenersparnis). Diese Prüfsumme (in diesem Falle eine CRC Prüfsumme) wird dann untereinander ausgetauscht und mit dem eigenen Ergebnis verglichen. Kommt es zu unterschiedlichen Prüfsummen für denselben Tick, dann sind die einzelnen Spiele nachweislich nicht mehr synchron.

    Wie der Multiplayer funktioniert:
    Die einzelnen Spieler kriegen über das Netzwerk die Eingabeaktionen der anderen Spieler zugesendet zu einem bestimmten Tick (in der Zukunft), und machen diesen dann alle zusammen. Wieso das so ist erkläre ich gleich.

    Beispiel:

    Das Spiel hat einen Standardverzögerungswert von 500ms. Bei 30 Ticks pro Sekunde wäre das eine Verzögerung von 15 Ticks.

    (Momentaner Tick): Aktion

    (100): Spieler rot will einen markierten Soldaten bewegen und klickt auf die entsprechende Kartenposition. Das Spiel sendet den Befehl, dass gemeinsam bei Tick 115 diese Aktion ausgeführt werden soll.
    (101): Keine Aktion
    (102): Keine Aktion
    (103): Keine Aktion
    ...
    (115): Alle Computer erinnern sich daran, dass jetzt Spieler rot diesen einen Soldaten da und da hin bewegen will, und führen den Befehl gemeinsam aus.

    Das Problem ist natürlich folgendes: Wenn eine Spielpartei diesen Befehl bekommt, ist einige Zeit vergangen und das eigene Spiel ist schon einen Tick oder mehr weiter. Dies passiert aufgrund der Netzwerkverzögerung. Viele Lösungen z.B. Server der Source-Engine haben mehrere Ticks gespeichert und "spulen" dann das Spiel zurück und entscheiden so z.B. über Treffer oder Verfehlung. Diese Lösungen sind zentralisiert und der Server entscheidet letzten Endes was passiert. Das führt dann gerne zu Unmut bei den Spielern ("Ich hab den doch getroffen").
    Siedler IV umgeht dieses Problem teilweise. Das eigene Spiel selbst wird wie gezeigt lokal verzögert dargestellt (Die Source-Engine macht das auch, aber bitte schlagt mich jetzt nicht bei den Details tot, das ist nur zur Veranschaulichung). Das passiert auch im Einzelspieler. Man kann das selber leicht sehen:
    Erfahrenen Spielern ist z.B. bestimmt schonmal aufgefallen, dass bei einer Baustelle, die pausiert und fortgesetzt wird, wenn die Priorität gesetzt ist, dass ganze etwas verzögert auftritt und hin und her flackert. Das Einzelspielerspiel ist auch hier verzögert und simuliert die Spielereingaben zu einer späteren Zeit. Das Einzelspielerspiel ist im Prinzip auch ein Mehrspielerspiel.

    AI Berechnungen sind kostbar. Häufig ist mir auch bei größeren Kämpfen aufgefallen, dass das Spiel ruckelt, auch wenn es glaube ich nur mit 30 Ticks pro Sekunde läuft (auf jeden Tick folgt ein Bild).
    Nun gibt es ein Problem, wenn das Spiel bei den Spielern unterschiedlich schnell läuft und diese Eingabeaktion als Paket erst dann kommt, wenn der Tick bereits ausgeführt ist. Das Spiel selbst hat nicht die Möglichkeit zurückzuspulen. Und die Verzögerung reicht nicht mehr.

    Das obige Beispiel nochmal:

    Alle Parteien sind bei Tick 115. Aufgrund eines Rucklers bei Spieler Rot liegt dieser genau 533ms bzw. 16 Ticks zurück, bei Tick 99.

    (Roter Spieler bei Tick 99): Spieler rot will einen markierten Soldaten bewegen und klickt auf die entsprechende Kartenposition. Das Spiel sendet den Befehl, dass gemeinsam bei Tick 114 diese Aktion ausgeführt werden soll.
    (Andere Parteien bei Tick 115): Erhalten den Befehl bei Tick 114 den Soldaten zu bewegen. Der Befehl wird guten Willens ausgeführt, obwohl die Ausführung zu spät ist.
    ...
    (Roter Spieler hat schnell hintereinander ein paar Ticks berechnet um wieder aufzuholen und ist bei Tick 114 angelangt):
    Rots Computer führt den Befehl bei Tick 114 aus. Weil das Spiel bei Tick 114 einen anderen Zustand hat als bei 115, verlaufen die Spiele unterschiedlich und diese Unterschiede kaskadieren.

    Der Lösungsansatz

    Genauergenommen ist dies kein Lösungsansatz. Er verändert nicht, wie das Spiel sich in diesem Falle verhält. Sollte die Erklärung aber richtig sein, wird es die Wahrscheinlichkeit, und nur die Wahrscheinlichkeit verringern, dass es zu einem Desync kommen sollte, ein Paket also durch Performanceunterschiede zu spät ankommt.
    Diese "Verzögerung" ist im Spiel einstellbar.

    Es handelt sich um die Variable "NetworkTimeDelta" unter "/Config/Network.cfg".
    Standardwert ist hier bei 500ms. Große Werte können das Spiel beim Kartenladen abstürzen lassen. 1000 z.B. geht.
    Das setzt voraus, dass alle Spielparteien denselben Wert eingegeben haben!!!

    Möglichkeiten seitens der Entwickler dies zu beheben/verbessern, wären z.B.:
    -Resynchronisation nach Erkennung eines Desyncs
    -Verbesserung der Performance
    -Kurze verabredete Pausierungen von Spielern die im Vergleich zu anderen etwas "voraus" sind im Laufe des Spieles, weil sie schneller und/oder weniger Berechnungen durchführen lassen. -> Das Spiel besitzt die Fähigkeit clientenabhängig zu pausieren, damit andere Spieler aufholen können. In welchem Rahmen und wie gut/ob das funktioniert, kann ich nicht beurteilen
    -Erkennung verpasster Befehle und entsprechende Neuverabredung (die Neuverabredung müsste dann in obigem Beispiel aber auch rechtzeitig beim roten Spieler ankommen, bevor dieser seinen Schritt ausführt. Das Ganze wird komplizierter umso mehr Spieler an dem Spiel teilnehmen.)

    Vorausgesetzt meine Einschätzung stimmt.
    Es kann natürlich sein, dass trotz gleicher Eingaben zur gleichen Zeit unterschiedliche Systeme zu anderen Ergebnissen und damit Spielaktionen kommen können. Das geht z.B. durch Zufallszahlen, Gleitkommaberechnungen, unterschiedliche Betriebssysteme, Hardware, Multithreading, usw., und dass es dann dadurch zu Desyncs kommt.
    Beispielsweise können verschiedene Computer für dieselbe Zahlenberechnung unterschiedliche Ergebnisse rausbekommen. Dies ist bei Gleitkommaberechnungen der Fall, da diese nur eine begrenzte Präzision haben, weil eine Kommazahl im Speicher immer denselben Speicherplatz hat, aber für den Menschen unterschiedlich komplexe Zahlen speichern muss.

    Beispiel:
    15.5 vs. 15.13 vs. 15.(Periode)15

    In unserer Darstellung sind diese Zahlen 3, 4 oder unendlich viele Ziffern lang. Bei Computern legt man hier eine Genauigkeitsgröße fest und belässt es dabei. Diese betrifft sich nicht auf Nachkommastellen, sondern eine Kombination nach der Formel:
    m*b^e

    b ist idR festgesetzt auf 2.

    Die mehr oder wenig beliebig gewählt werden um Zahlen mit derselben Speichergröße im Binärformat so präzise wie möglich darstellen zu können.

    Beispiel Gleitkommazahlberechnung mathematisch korrekt:
    15.0 / 2.0 = 7.5

    Wäre bei einem Computer z.B.
    15.00001 / 1.99999 = 7.4997

    Da Systeme anders funktionieren können, kann das Ergebnis auf einem anderen Computer so aussehen:
    14,9999 / 2.0001 = 7.5001

    Mehrere Berechnungen hintereinander sorgen natürlich dafür, dass der Berechnungsfehler unterschiedlich groß ausfällt.

    Sind solche Berechnungsfehler schuld daran, dass das Spiel auf unterschiedlichen Rechnern unterschiedlich läuft, kann der oben genannte Trick z.B. gar nicht helfen.

    Achso, übrigens, nochmal an BB falls hier einer mitliest.
    Ich würde gerne unentgeldlich an S4 arbeiten und die Fehler (es sind ja ehrlich gesagt extrem viele kleine und aber auch große das Spiel kaputt machende) beseitigen. S4 war das erste von mir selbst gekaufte Spiel in meinem Leben und ich würde es gerne nach 18 Jahren vernünftig spielen können. Ich wohne in der Nähe von Düsseldorf. Vielleicht geht sowas in Form eines unbezahlten Praktikums? Meine PNs sind offen.

    Gute Nacht Leute und frohes Siedeln!

    EDIT vom 04.04.2019: Mehr Details und Beispiele, Tippfehler korrigiert.
     7 people found this helpful
    Share this post

  2. #2
    Avatar von Morphoiz Neuzugang
    Registriert seit
    Mar 2011
    Beiträge
    7
    Danke für deine interessante Einschätzung! War auch für einen Laien wie mich ein interessanter Einblick.

    Viel Glück im Hinblick auf deinen letzten Absatz, es wäre für die Community nur von Vorteil, wenn jemand der offensichtlich so leidenschaftlich beim Thema dabei ist, bei BB mitarbeitet. ;-)
     2 people found this helpful
    Share this post

  3. #3
    Avatar von TheNicklander Neuzugang
    Registriert seit
    Jan 2019
    Beiträge
    2
    Ich denke mal, Ubisoft ist den Spielern was schuldig. Irgendwie muss der Kaufpreis ja auch gerechtfertigt werden, ganz zu schweigen davon, dass Versprechen eingehalten werden müssen. Da die momentanen Entwickler ganz offensichtlich massive Probleme haben die Fehler zu beheben, kommt mir der Vorschlag von Cookie wie ein Segen. Fakt ist, dass Cookie/MuffinMario mit Fixes, Community Tools und Analysen bis jetzt mehr geleistet hat als so manch bezahlter Angestellter. Man erinnere sich, viele HE-Features gab es schon für das Original in der Form von Mods und Patches. Siehe zB meinen Widescreen Fix von 2014! Bitte nicht in den falschen Hals kriegen, aber die Kindheitskrankheiten sind nun mal immer noch da und das ist ein grosses Problem weil somit der Siedelspass gegen 0 tendiert.

    Liebes Ubisoft Team, ich hoffe doch sehr Ihr geht auf diese einmalige Chance ein und zeigt somit Engagement gegenüber der Community. Im Gamedevelopment macht man keine halben Sachen, entweder man zieht es durch oder man lässt es. Die History Edition ist eine sehr schöne Hommage an die Fans. Ich hoffe es gibt noch viele weitere Updates, Bugfixes und neue Features. Ich bin davon überzeugt, dass eine enge Zusammenarbeit mit der Community sich auch vorteilhaft auf die Verkaufszahlen auswirkt !
     1 people found this helpful
    Share this post

  4. #4
    Avatar von lolerboon2010 Neuzugang
    Registriert seit
    Feb 2019
    Beiträge
    8
    Ich kann nicht verstehen warum CookieButton nicht helfen darf er möchte ohne gegenleistung eure Probleme lösen
    Warum lässt man ihn dann nicht
    Mann hätte es ihn wenigstens probieren lassen können zb das desync problem zu behen
    weil Wem hätte das geschadet

    also wenn mir jemand anbieten würde mir gratis bei der arbeit zu helfen würde ich auch nicht nein sagen....


    ich glaube auch das er um ein vielfaches mehr interessiert ist siedler 4 zu fixxen als eurer komplettes team.....


    und als dank für sein angebot gibts noch nicht mal eine antwort

    was ist billiger ein unbezahlter praktikant der mehr leisten kann und will
    oder jemand aus eurem team dem das ganze nach feierabend eh am ar.... vorbei geht???

    veränderter code kann man sich vorher ja angucken testen und dann wird man ja sehen ob der praktikant sein werk versteht......

    Vieleicht habt ihr ja auch angst um den sourcecode-.- Da solltet ihr euch eben vorher schriftlich absichern......

    Die Community möchte Siedler 4 spielen können ohne nervige fehler die es schon damals gab und wenn das zuviel vom team verlangt ist weil ihr ja auch alle anderen Teile Fixxxen müsst ... dann fragt mal CookieButton der mit dem herzen dabei wäre/ist
    Share this post

  5. #5
    Avatar von Shadowbow1989 Neuzugang
    Registriert seit
    May 2020
    Beiträge
    1
    Zitat von CookieButton Go to original post
    Es kann natürlich sein, dass trotz gleicher Eingaben zur gleichen Zeit unterschiedliche Systeme zu anderen Ergebnissen und damit Spielaktionen kommen können. Das geht z.B. durch Zufallszahlen, Gleitkommaberechnungen, unterschiedliche Betriebssysteme, Hardware, Multithreading, usw., und dass es dann dadurch zu Desyncs kommt.
    Beispielsweise können verschiedene Computer für dieselbe Zahlenberechnung unterschiedliche Ergebnisse rausbekommen. Dies ist bei Gleitkommaberechnungen der Fall, da diese nur eine begrenzte Präzision haben, weil eine Kommazahl im Speicher immer denselben Speicherplatz hat, aber für den Menschen unterschiedlich komplexe Zahlen speichern muss.
    Das mit den unterschiedlichen Systemen/Hardware glaube ich nicht. Denn das Problem tritt auch auf, wenn alle Teilnehmer den exakt selben Rechner nutzen. Das es ein Threading Problem ist denke ich ebenfalls nicht, denn die Spiellogik läuft singlethreaded. Nur für das Rendering gibt es einen separaten Thread.

    Eigentlich tritt das Desync Problem doch fast nur auf, wenn Computerspieler an der Partie beteiligt sind oder nicht? Darauf gehst du in deinem Post nicht ein. Hast du dazu schon was untersucht?

    Meine Vermutung ist, dass ein Teilnehmer irgendwie ein klein wenig schneller ist als die anderen und irgendwann kommt es dann zum Desync. Je mehr Code ausgeführt wird, desto eher wird dieses Ungleichgewicht in der Ausführungsgeschwindigkeit zum Problem. Irgendwann ist ein Computer dann einen Tick weiter vorn und berechnet dann natürlich daraufhin eine falsche Prüfsumme. Das könnte erklären, warum es mit Computerspielern häufiger auftritt als ohne, da dann mehr Code ausgeführt werden muss. Das ist aber auch nur eine Vermutung.

    Ich arbeite grade an einem Holzhammer Fix mit einer Proxy DLL, die einen zweiten Socket öffnet. Im Falle eines Desyncs wird einfach der Zustand (= alle Daten, die zur Berechnung der Prüfsumme herangezogen wurden) eines ausgewählten Teilnehmers an alle anderen verteilt. Die wenden den dann einfach an und überschreiben ihren eigenen damit. Ich zwinge sozusagen alle Teilnehemer durch den Prüfsummenhook dazu die selbe Prüfsumme zu erhalten. Erste Versuche von mir sind vielversprechend, aber es gibt ein paar Probleme.
    Zuerst löste ich die Desyncs zum Testen künstlich aus (also einfach von außen mit WriteProcessMemory) und wartete dann ab. Meine Methode scheint dies erfolgreich fixen zu können. Das Problem sind dann die echten Desyncs. Nachdem ich die Zustände ein paar mal überschrieben habe, treten diese Desyncs immer häufiger auf. So häufig, dass praktisch ständig der Zustand neu übertragen werden muss. Das zeigt wie du schon vermutest, dass es in irgendeiner Form ein Timing Problem ist. Ich weiß nur noch nicht, wie ich das fixen soll. Das Spiel muss beim betroffenen Teilnehmer tatsächlich "zurückgespult" oder "vorgespult" werden. Ich versuche das, indem ich einfach das Spiel bei den anderen jeweils anhalte (also den Thread suspende), das funktioniert aber nicht wirklich und ist auch verdammt schwierig zu debuggen. Hast du da schon mehr rausgefunden?

    Eine andere Idee ist, das Spiel beim Desync durch seine spieleigene Speicherfunktion zu speichern und dann diesen Spielstand über die Sockets an die anderen Teilnehmer zu verteilen (anstatt meines Memgehackes). Dann würde jeder Teilnehmer die spielinterne Ladefunktion mit diesem Spielstand nutzen. Das habe ich aber noch nicht wirklich ausprobiert.

    VG
    Share this post

  6. #6
    Avatar von DonAlfonso Junior Mitglied
    Registriert seit
    Mar 2006
    Beiträge
    63
    Meine Frau und ich können zu zweit gegen 4 bzw. 6 KI Gegner spielen seit der History Edition. Wenn es mal zu einem Desync kam, hat neuladen bisher jedesmal funktioniert.
    Wir hatten heuer nur einen Desync und das war auf der Map Deadsimple. Unsere Beobachtung ist auch, dass Desyncs auf größeren Karten eher auftreten, daher ist unsere maximale Kartengröße 768 und kleiner (die Größe unter Deadsimple).
     1 people found this helpful
    Share this post

  7. #7
    Avatar von CookieButton Kam, sah und tippte
    Registriert seit
    Dec 2018
    Beiträge
    279
    Zitat von Shadowbow1989 Go to original post
    Das mit den unterschiedlichen Systemen/Hardware glaube ich nicht. Denn das Problem tritt auch auf, wenn alle Teilnehmer den exakt selben Rechner nutzen.
    Portabilitätsprobleme sind nicht nur von der Hardware abhängig. Es reichen unter Umständen auch kleinste Unterschiede in den benutzten Bibliotheken (Nachtrag: Mehr dazu ganz am Ende des Posts).

    Zitat von Shadowbow1989 Go to original post
    Das es ein Threading Problem ist denke ich ebenfalls nicht, denn die Spiellogik läuft singlethreaded. Nur für das Rendering gibt es einen separaten Thread.
    Kannst du das genau belegen? Bei der HE ist zum Beispiel eine sehr antike Threading-Library geupdatet worden, was sich auf das Spiel scheinbar nicht auswirkt (die alte Lib konnte ich im Internet nirgendwo finden), aber aufzeigt, dass doch mehrere Threads verwendet werden. Bedenke, Netzwerkverbindungen sind blockierend und müssen entsprechend ausgelagert werden, was normalerweise zwar keine Probleme verursachen sollte, aber das Spiel...

    Zitat von Shadowbow1989 Go to original post
    Eigentlich tritt das Desync Problem doch fast nur auf, wenn Computerspieler an der Partie beteiligt sind oder nicht? Darauf gehst du in deinem Post nicht ein. Hast du dazu schon was untersucht?
    Deine Annahme mit den Bots ist korrekt. Dazu gibt es von mir keine genaue Untersuchung, aber da liegt entweder die Ursache, oder zumindest ein großer verstärkender Faktor. Der Einfluss auf die Desyncs bzw. der Unterschied ist so groß/krass, dass man das ausnahmsweise mit Annekdoten (also Ergebnissen aus der Community und deren "Tests") belegen kann.

    Zitat von Shadowbow1989 Go to original post
    Meine Vermutung ist, dass ein Teilnehmer irgendwie ein klein wenig schneller ist als die anderen und irgendwann kommt es dann zum Desync. Je mehr Code ausgeführt wird, desto eher wird dieses Ungleichgewicht in der Ausführungsgeschwindigkeit zum Problem. Irgendwann ist ein Computer dann einen Tick weiter vorn und berechnet dann natürlich daraufhin eine falsche Prüfsumme. Das könnte erklären, warum es mit Computerspielern häufiger auftritt als ohne, da dann mehr Code ausgeführt werden muss. Das ist aber auch nur eine Vermutung.
    Diese Anfangsvermutung hatte ich auch, allerdings gibt es dazu drei Gegebenheiten, die das widerlegen.
    1) Die Prüfsummenverabredung ist einmal geplant, einmal pseudozufällig, bezieht sich aber auf einen Spielstand zu einem bestimmten Tick, nicht zu einer bestimmten Zeit.
    2) Das Spiel ist in der Lage individuell zu pausieren. Sonst wäre ein Spielen über das Netzwerk/Internet (vor allem damals) gar nicht möglich gewesen.
    3) Alle Spielaktionen werden wie oben erklärt im Voraus für in die Zukunft verabredet um gerade dieses Problem des "zu weit Gehens" auch zu vermeiden, sodass es nicht unbedingt zu 2) kommen muss.

    Ich habe kein Profiling durchgeführt, teure Implementierung ist daher durchaus möglich, ich möchte aber an der Stelle darauf hinweisen, dass das "I" in "KI" bei solchen Spielen auch rein altersbedingt ein Euphemismus ist. Die KI ist sehr sehr einfach gescripted und sollte(!) performancetechnisch eigentlich zu keiner absoluten Belastung führen. Bei RaceConditions wäre das natürlich relativ zu betrachten, entsprechend sieht die Sache dann wieder anders aus.

    Zitat von Shadowbow1989 Go to original post
    Ich arbeite grade an einem Holzhammer Fix mit einer Proxy DLL, die einen zweiten Socket öffnet. Im Falle eines Desyncs wird einfach der Zustand (= alle Daten, die zur Berechnung der Prüfsumme herangezogen wurden) eines ausgewählten Teilnehmers an alle anderen verteilt. Die wenden den dann einfach an und überschreiben ihren eigenen damit. Ich zwinge sozusagen alle Teilnehemer durch den Prüfsummenhook dazu die selbe Prüfsumme zu erhalten. Erste Versuche von mir sind vielversprechend, aber es gibt ein paar Probleme.
    Zuerst löste ich die Desyncs zum Testen künstlich aus (also einfach von außen mit WriteProcessMemory) und wartete dann ab. Meine Methode scheint dies erfolgreich fixen zu können. Das Problem sind dann die echten Desyncs. Nachdem ich die Zustände ein paar mal überschrieben habe, treten diese Desyncs immer häufiger auf. So häufig, dass praktisch ständig der Zustand neu übertragen werden muss. Das zeigt wie du schon vermutest, dass es in irgendeiner Form ein Timing Problem ist. Ich weiß nur noch nicht, wie ich das fixen soll. Das Spiel muss beim betroffenen Teilnehmer tatsächlich "zurückgespult" oder "vorgespult" werden. Ich versuche das, indem ich einfach das Spiel bei den anderen jeweils anhalte (also den Thread suspende), das funktioniert aber nicht wirklich und ist auch verdammt schwierig zu debuggen. Hast du da schon mehr rausgefunden?
    Hallo, dein Ansatz mit dem Zustandssenden ist an sich ganz gut. Dass das Spiel in einen Zustand kommt, in dem Ungenauigkeiten trotz scheinbarer Behebung immer häufiger auftreten und schwieriger zu beherrschen sind, ist eine Beobachtung, die ich auch mit den FEs machen konnte.
    Du hast natürlich zusätzlich die Schwierigkeit bei deinem Ansatz, dass du einen fixen Einstiegspunkt benutzen musst(!). Das bezieht sich nicht nur auf den Spielzustand in Ticks, sondern auch darin, dass du mit Hooks/Trampolinen die exakt selbe Stelle im Instruktionsablauf unterbrechen musst. Was du machst, und das ist ein weiteres Problem, ist dass du "a posteriori" eingreifst. Du müsstest eigentlich, wie das Spiel aus sonst vorgeht, die Korrektur vorverabreden. In etwa tust du ja, wenn auch dynamisch, das was Leute mit häufigem Speichern tun. Die Ergebnisse decken sich mit deinen.
    Wie gesagt, die Erklärung in meinem Eingangspost ist nur als Erläuterung des Spielablaufs zu verstehen. Damals sah ich nur Hinweise darauf, dass das Spiel bei einzelnen Teilnehmern pausiert werden kann. Der Titel ist daher leider irreführend, weil er, wenn auch sehr gering gehalten von mir, doch die Möglichkeit verspricht, dass die Vergrößerung der Planungsspanne helfen könnte. Ich verstehe das so, dass, wenn du "Timing" meinst, du von dem prinzipiellen Grundfall des Desyncs bei Fixed-Timestep-Umsetzungen sprichst, den ich in meiner Spielablauferklärung abgebe. Dass das zu Problemen führt, ist wie gesagt nicht mehr mein aktueller Wissensstand.
    Mein Eingangspost sollte entsprechend von mir ein bisschen umformuliert werden, da könnte ich auch einige Kleinigkeiten der Korrektheit halber beheben. So ist die Angabe mit den 30 Ticks Käse, das Interval ist bei normaler Spielgeschwindigkeit 71ms.

    Zitat von Shadowbow1989 Go to original post
    Eine andere Idee ist, das Spiel beim Desync durch seine spieleigene Speicherfunktion zu speichern und dann diesen Spielstand über die Sockets an die anderen Teilnehmer zu verteilen (anstatt meines Memgehackes). Dann würde jeder Teilnehmer die spielinterne Ladefunktion mit diesem Spielstand nutzen. Das habe ich aber noch nicht wirklich ausprobiert.
    Das ist wie gesagt meines Wissens nach so schon ausprobiert worden. Es bleibt natürlich die Spekulation inwiefern nicht schon eine Entropie auftrat und diese heimlich mitgespeichert worden ist.
    Meine Empfehlung ist, einfach nicht mit Bots zu spielen. Ich spiele die GoldEdition auch regelmäßig ohne Benutzung von Häfen und Marktplätzen (und Lager meide ich auch), es ist schwierig genau zu quantifizieren wie selten FEs bei mir auftreten, weil es ja nur Logs bei Crashes gibt, und nicht beim normalen Spielablauf (zumindest dauerhaft, die werden scheinbar gelöscht), aber ich kann davon ausgehen, dass ich durchschnittlich pro Woche zwei volle Runden spiele (das wären so 4 Stunden insgesamt), und ich nach Logs dieses Jahr noch gar keinen FE hatte.
    Was du versuchst, und ich versucht habe, ist letztendlich auch "nur" Mitigierung dieser Probleme. Nach meiner Erfahrung sind diese 3 Probleme für uns nicht fixbar (Desyncs, FEs, TOOL-Abstürze). Schwarz auf Weiß habe ich das für TOOL-Abstürze.
    Die Community wird auch entsprechend beeinflusst, das Problem nicht beim Schopfe zu packen. Das ist nicht der erste Rerelease eines Siedlerspieles bei dem nichts gefixt worden ist. Und das wird sich auch nicht ändern, solange Ubi gutes Geld damit machen kann. Die wollen verständlicherweise auch nur Gewinne machen, und das geht halt am besten mit dem Minimalprinzip.
    Ich glaube bei den Desyncs auch nicht an eine einfache Lösung, weil es zu Zeiten als Ubi aktiv am Spiel gearbeitet hat (bis zum Patch 2.irgendwas1516), auch nur Updates zur Mitigation gab. (Gut, damals waren die Zeiten noch anders und BB hatte einige Probleme.) Wir spielen ja mit komplett anderen Regeln, wenn wir an dem Spiel arbeiten. Selbst einfache Konstanten zu ändern, kann auch bei beruflichen Spezialisten in unserer Situation entsprechend lange dauern. Bei dem Stundenlohn, den die Leute verlangen dürfen und sollten, möchte ich mir die Kosten nicht ausrechnen.

    Ich möchte abschließend sagen, dass FixedTimeStep ansich, wenn es funktioniert eine sehr elegante, vorallem netzwerkschonende (und daher früher so beliebt, weil die Traffickomplexität konstant ist). Das ist aber in etwa so aussagekräftig wie am Stammtisch zu behaupten, dass Java plattformunabhängig ist. Compile once, debug everywhere!
    Leider muss man peinlichst auf Probleme achten, die sich unterteilen in:

    1) RaceConditions
    2) Portabilität:
    -Unterschiedliche CPUs und Instruktionsumsätze, die in dem den Algorithmus beeinflussenden Rahmen eigentlich ausschließlich bei Gleitkommaoperationen auftreten können
    -Unterschiedliches OS/Bibliotheken
    -Bibliotheken, die verwendet werden, über deren Portabilität man aber keine Aussagen machen kann
    -Es fällt mir gerade ein, und der Vollständigkeit halber sollte ich das vielleicht anschneiden. Man sollte es generell nicht tun, aber in Projekten in schlechtem Zustand, die in unmanaged Sprachen umgesetzt werden, sollte man bedenken, dass Zeiger (auch wenn sie anwendungsspezifisch gegeben sind und entsprechend nochmal übersetzt werden) theoretisch auch andere Werte haben könnten. Ich habe in den letzten Tagen beobachtet, dass (vielleicht auch kompilerbedingt) S4 gerne mit Zeigern rumjongliert, was zum Beispiel absolut dagegen spricht, dass man LAA anschalten sollte.
    Share this post