✓ Verbindung verloren / Hammermann bei Angriff im Abenteuer [24498][24524][24498]

[BB_Ondgrund]

Seit dem letzten Update sollte dieses Problem nicht mehr auftreten.

[BB_Ondgrund]

Wir untersuchen noch einige Randfälle für dieses Problem, daher habe ich die "Gelöst" Markierung für das Thema noch einmal entfernt. In den meisten Fällen sollte das Problem zwar nicht mehr auftreten, aber einige extrem lange Blocks können noch Probleme machen.

[Leatherface]

@BB_Ondgrund der Fehler ist gerade eben seit längerer Zeit wieder aufgetreten! Spiele Berglabyrinth, letztes Anführerlager angegriffen => Verbindung zum Server direkt nach Angriffstart verloren => Relog => Map aufbauen lassen und versucht rüber zum AT zu wechseln => Verbindung zum Server verloren => Zone refreshed & das in einer Reihe.
Konsole bringt die bekannte Meldung:
Error while deserializing AMF body: System.ArgumentException: Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection.
at System.IO.BinaryReader.Read (System.Byte[] buffer, System.Int32 index, System.Int32 count) [0x00000] in <00000000000000000000000000000000>:0
(Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 39)

0325730a-3a45-47bb-a6be-c8607e83f8ce:8:43527
_JS_Log_Dump blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:2935899
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:2935690
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:2934899
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:2931982
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:7510632
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:27676403
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:27676482
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:16885309
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:27704581
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:16761293
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:27674993
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:18895741
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:18894793
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31743388
dynCall_iii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
invoke_iii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:19967960
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31743593
dynCall_iiii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
invoke_iiii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:17387412
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31748860
dynCall_viii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
invoke_viii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:17386384
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:17390631
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:16756035
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:26854948
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:16455071
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31743877
dynCall_iiiii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
invoke_iiiii blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31362221
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31215772
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:3008240
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:3007432
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:4375245
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:4374485
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:4375762
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:4544529
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5758616
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5615066
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5615087
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5613816
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5605510
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:5682104
<anonym> blob:https://www.diesiedleronline.de/0325...e-c8607e83f8ce line 8 > WebAssembly.instantiate:31748151
dynCall_vi blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
dynCall blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
dynCall_wrapper blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
wrapper blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8
UnityModule blob:https://www.diesiedleronline.de/0325...c8607e83f8ce:8


Erst nach ca. 10 Minuten warten (Ingame) geht es wieder.
Nachtrag: Nach Beenden des ATs löst das Löschen / bzw. Anklicken von Nachrichten auch Verbindungsfehler aus (eigenständiges Thema, aber es scheint, als wäre dieser "Fehler" ggf. etwas umgreifender).

[altersheimer]

Zyklus der Speichernutzung

Unabhängig von der eingesetzten Programmiersprache läuft der Zyklus für die Speichernutzung immer ungefähr gleich ab:

Alloziierung/Zuweisung des benötigten Speichers.
Benutzung des Speichers (lesen, schreiben).
Freigabe des alloziierten Speichers, wenn er nicht mehr benötigt wird.

Der erste und zweite Schritt erfolgt bei allen Programmiersprachen explizit. Der letzte Schritt, die Freigabe des Speichers, wird bei Low-Level-Sprachen explizit und bei höheren Programmiersprachen wie JavaScript meist implizit vorgenommen.

Freigabe des Speichers, wenn dieser nicht mehr benötigt wird

Bei diesem Vorgang tauchen am häufigsten Probleme mit der Speicherverwaltung auf, da es keine leichte Aufgabe ist, zu entscheiden, wann der benötigte Speicher tatsächlich nicht mehr gebraucht wird. Oftmals muss der Entwickler selbst bestimmen, an welcher Stelle die Freigabe eines Speicherbereichs erfolgen soll.

Höhere Programmiersprachen setzten häufig eine Softwarekomponente namens Garbage Collector ein, dessen Aufgabe darin besteht, die Speicherallokation zu überwachen und nicht mehr benötigten Speicher wieder freizugeben. Dieser Prozess basiert auf einer Abschätzung, da das zugrundeliegende Problem - zu entscheiden, wann Speicher nicht mehr benötigt wird - unentscheidbar ist (nicht durch einen Algorithmus lösbar).

Hier vermute ich den Fehler. Das Programm verschluckt sich, WASM und GarbageCollector könnten vielleicht besser harmonieren.
ich für mich habe die indexeddb komplett deaktiviert, die multiprozessanzahl auf 4 runtergedreht und den fuchs in meinem DSO-profil per config angewiesen, den eingehenden code nur lesend abzuarbeiten/auszuführen und ich habe ein wenig am JIT-Compiler rumgeschraubt. JIT heißt in echt JustInTime. kein witz. nix davon in den speicher legen. es könnten ja auch fehlerbehaftete codeblöcke dabei sein. und wenn der fuchs erst aus dem "unity"cache liest, dann sind womöglich auch diese fehler dabei. oder der garbagecollector ist nicht ganz entscheidungsfreudig. zumindest geht das cachen bei mir reibungsloser und ich kann sehr flüssig siedeln.
wenn ich in meiner konsole in den unitycache einsehen will, finde ich nix. leer, keine einträge für diesen host. ich presse das script quasi durch. diesen fehler habe ich nicht.
ich bin nicht ganz fehlerfrei, bei mir kömmen auch ab und an refresh-meldungen. aber wirklich selten und eben fast nur meldungen ohne auswirkungen.
zumindest könnte das bei den reparaturarbeiten am script mal geprüft werden, schaden kann es nicht.
hinweis:
das ganze hat absolut nix mit ram-größen zu tun, es geht "nur" um scriptcaching.
wer selber rumfummeln will, änderungen immer in die user.js im profilordner vornehmen. nicht im blindflug unter "about:config".

[BB_Ondgrund]

Wir wissen, dass es hier noch Sonderfälle bei extrem langen Kämpfen gibt, die weiterhin zu dem Problem führen können. Das liegt unseren Entwicklern auch weiter vor. Der betroffene Kampf hatte wahrscheinlich sehr viele Kampfrunden, was dann ein Problem mit der dadurch generierten Datenmenge verursacht.

[boerdelaender]

Dazu möchte ich noch anmerken dass das GC wie hier vorgeschlagen unter Unity WebGL nicht funktioniert, dafür kann Ubi nix, es funktioniert einfach nicht so wie es soll, ist ein Problem von WebGL und Javascript und auch Unity bekannt.
GC ist vorhanden, aber kann nicht so angesprochen werden wie bei anderen Programmen.

Garbage Collector gibt es, aber funktioniert unter Unity WebGL nicht so wie es aus anderen Anwendungen bekannt ist, macht es den Entwicklern dann auch nicht unbedingt einfacher. Abhilfe geht halt über Speicherbegrenzung, max. Werte festlegen, Speichergrößen insgesamt minimieren, kleine Scripte schreiben usw. aber irgendwann fällt unter bestimmten Umständen dann doch zuviel an und es kommt zu Fehlermeldungen und Verbindungsabrüchen.

[Leatherface]

Ich habe langsam den Eindruck, dass aufgrund das, was geschrieben wird, Unity WebGL nicht wirklich für solch ein umfassendes Browserspiel geeignet ist.
@BB_Ondgrund das kann schon sein. Allerdings habe ich ca. eine Woche zuvor mit der gleichen "Taktik" gearbeitet, da ist es nicht passiert. Allerdings würde ich bei zu hoher Datenmenge eher ein "Out of Memory" erwarten und keinen Verbindungsfehler, der selbst nach einem Relog noch anhält.
Allerdings sind beim Bergklan noch die anderen Probleme, beispielsweise dass der Nebel respawnt, das Questbuch aktualisiert sich oft nicht (bzw. abgeschlossene Quests verschwinden und erst nach einem Inselwechsel sind sie wieder da) & teilweise massive Verzögerungen beim Angriff von Genis (das merkt man z.B. daran, dass beim Blocken die Genis nicht bündig hintereinander angreifen, sondern ein Delay von 1-2s haben (was den Block natürlich verhaut)). Ggf. gibt es generell ein Problem bei der Unternehmung oder es ist einfach Glücksache / Pech.

[BB_Ondgrund]

Die Anzahl der Kampfrunden kann oft stark variieren. Auch wenn alles gleich ist, kann ein Angriff mehr als doppelt so lange dauern wie ein anderer Angriff mit genau den gleichen Einheiten. Einige Dinge im Kampfsystem hängen eben vom Zufall ab, und können dann große Unterschiede bei der Kampfdauer verursachen. Und bei diesem Problem ist die Anzahl der Kampfrunden wichtig, da das Problem nur bei extrem langen Kämpfen auftritt. Daher kann es beim gleichen Angriff mal auftauchen und mal nicht, je nachdem wie lange der Kampf tatsächlich dauert.

[altersheimer]

Ich habe langsam den Eindruck, dass aufgrund das, was geschrieben wird, Unity WebGL nicht wirklich für solch ein umfassendes Browserspiel geeignet ist. ...

doch, unity webgl ist geeignet. aber es gibt viele stolperfallen und die entwickler hatten womöglich einfach zu wenig vorlaufzeit, beim ersatz von flash. und ich vermute, dass die inhouse-entwickler nocht nicht wirklich fit, für die programmierung mit unity waren.
auch die browsersoftware selbst muss berücksichtigt werden. die haben ja ihre eigenen gedanken/engine zu javascript. nehmen wir nur mal die firefoxfamilie:
JIT-Compiler mit WARP( heißt wirklich so ), wasm, webgl, und und und. da kann man selbst hand anlegen, einiges ist so erst gar nicht aktiviert oder für dso unglücklich konfiguriert. das liegt daran, dass mozilla und co eben immer nur ein ausgewogenes profil weitergeben um jedem user sein "surferlebnis" zu ermöglichen. und leider scheint dort auch niemand dso zu spielen. und eine user.js oder eine all.js in ein profil einbringen, ist wirklich nicht jedermann sache.
die chromebrowser sind da nicht besser und aus meiner sicht, auch weniger gut "nachkofigurierbar".

es stimmt, der nicht optimal schuftende GC wirkt sich aus. als entwickler könnte man ja für fehleranalysen heap-momente anlegen. die dev-tools im firefox sind da nützlich. mir hat das rumschrauben was gebracht, aber vielleicht nicht jedem. das wichtigste hierbei ist das eigene profil für dso. das angemerkte kleinhalten der codemodule für das script-caching ist enorm wichtig. das hat der kollege aus der alten heimat dankenswerter weise schon oft angemerkt.
aber ich erhoffe mir/uns, dass die entwickler aus den hinweisen den richtigen nutzen ziehen können. denn nicht alle siedler können an ihrer software rumschrauben um das ganze performanter zu machen. momentan läuft das script so für mich persönlich, ziemlich gut. in spitzenzeiten nur 48sec ladezeit und praktisch keine ausfälle. der hinweis auf einen fehler kommt, aber der fehler nicht. erklären kann ich es nicht besser. ich spiele einfach weiter.

ABER!! am ende warten wir alle auf den großen ruck oder das stöpsel ziehen beim spieleanbieter. damit hier mal wieder eine richtig freundliche gesprächskultur zu lesen ist.

[Leatherface]

@BB_Ondgrund & @altersheimer danke für die Erklärung.