Ein NLT-Veteran spielt Drakensang

[Kunar]

Den Zwölfen zum Gruße!

Du kannst die Gegenstandslisten doch auch im SQL-Editor füllen, und dann schauen, ob das spiel kurz darauf abstürzt.

In dem 815er-Spielstand sind die Tabellen ja bereits so gefüllt, dass es kurz darauf zuviel wird. Ich habe deswegen einmal diesen Spielstand verglichen mit dem, in dem ich alle Gegenstände entfernt hatte, deren Aufenthaltsort das Hauptquartier (Ardos Anwesen) war, sowie den Spielstand danach, in dem ich den Kampf gegen die Goblins zuende führen konnte. Die mit Abstand größten Tabellen sind immer die mit den Waffen und die mit den sonstigen Gegenständen. Nach dem Kampf kommen nur hier neue Gegenstände hinzu!

815 / 815* / 816:
883 / 689 / 690 sonstige Gegenstände
1281 / 964 / 971 Waffen

Sonstiger Gegenstand 690 sind Giftzähne.
Waffen 965-971 sind Dummy, Wurfbeil, Dummy, Kurzbogen, Dummy, Kurzbogen, Dummy.

Die Dummys stehen anscheinend für die bloße Hand, mit der die verbliebenen Gegner gekämpft haben.

Es sieht wohl so aus, dass es einfach zu viele Gegenstände sind. Jetzt wäre noch interessant, herauszufinden, ob das generell gilt (allgemeine Obergrenze) oder nur für eine Art von Inventar, das in einer jeweils eigenen Tabelle gespeichert wird (bekannte Tabellen: Geschmeide, Kräuter, Munition, Schlüssel, Geld, Rezept, Schild, Rüstung, Fackel, Waffe, sonstige Gegenstände).
(...)
Die nächsten Tests müssen also näher eingrenzen, welche Gegenstandsliste genau überfüllt wird. Eventuell hilft es bereits, die ohnehin verlorenen Gegenstände (die nicht mehr aus dem Spiel heraus beschafft werden können) zu löschen.

Gegenstände wegwerfen dürfte sie doch endgültig aus dem Spiel löschen, oder?
Ist zum Testen vielleicht einfacher als sie weiterzuverarbeiten.

Das ist insbesondere deswegen sinnvoller, weil nach dem aktuellen Stand nur Waffen und sonstige Gegenstände als Auslöser für die Abstürze in Frage kommen. Da insbesondere die Waffentabelle voll ist mit Dummy- und Friedhofseinträgen, werde ich als nächstes testen, ob das Spiel wieder läuft, wenn man diese löscht.

[Rabenaas]

In dem 815er-Spielstand sind die Tabellen ja bereits so gefüllt, dass es kurz darauf zuviel wird. Ich habe deswegen einmal diesen Spielstand verglichen mit dem, in dem ich alle Gegenstände entfernt hatte, deren Aufenthaltsort das Hauptquartier (Ardos Anwesen) war, sowie den Spielstand danach, in dem ich den Kampf gegen die Goblins zuende führen konnte.

Würdest Du einen sozusagen jungfräulichen Spielstand nehmen, vom Beginn des Spiels, und dann x Gegenstände in eine Tabelle einfügen würdest, dann hättest Du den Fehler im Fall der Fälle sicher reproduziert. Darum geht es doch im Moment, oder?

[exi]

[...]
Das kann ich inzwischen aktualisieren/korrigieren: Bei einem weiteren Test stürzte das Spiel auch nach Verkauf der oben näher ausgeführten Beute aus den Blutbergen ab. Diesmal geschah das beim Speichern mitten im Kampf gegen den Goblinberserker - und zwar interessanterweise, ohne dass dieser in der betroffenen Runde gestorben wäre.
[...]
Es sieht wohl so aus, dass es einfach zu viele Gegenstände sind. Jetzt wäre noch interessant, herauszufinden, ob das generell gilt (allgemeine Obergrenze) oder nur für eine Art von Inventar, das in einer jeweils eigenen Tabelle gespeichert wird (bekannte Tabellen: Geschmeide, Kräuter, Munition, Schlüssel, Geld, Rezept, Schild, Rüstung, Fackel, Waffe, sonstige Gegenstände).

Ich würde mir die Zutaten für verschiedene Rezepte am liebsten aufheben, bis ich jeweils weiß, was das teuerste mögliche Endprodukt ist. Falls das nicht möglich ist, wären am ehesten die Kräuter zu verschmerzen, die ich inzwischen in unbegrenzter Anzahl im Garten ernten kann.

Die nächsten Tests müssen also näher eingrenzen, welche Gegenstandsliste genau überfüllt wird. Eventuell hilft es bereits, die ohnehin verlorenen Gegenstände (die nicht mehr aus dem Spiel heraus beschafft werden können) zu löschen.

... Abstürze mitten im Kampf dürften wohl vom automatischen Speichern herrühren. Derlei habe ich ausgeschalten.

Mittlerweile habe ich deinen Verkauf (Pfoten, Lederriemen, Sehnen, Zähne, Fellfetzen, Wolfsfelle) abschlägig getestet. Ich erschlage die 4 Goblins (ja: bei mir sind es 4. Zwei als Nahkämpfer, zwei mit Bogen), leere ihre Taschen, gehe nach Ferdok, leere meine Taschen und fülle sie mit 625 Pfoten, 1195 Riemen, 1064 Sehnen, 552 Zähnen (zwei habe ich von den Goblins bekommen), 1269 Fetzen, 717 Fellen und gehe zum Jäger. Nach dem Verkauf speichere ich und stürze ab.

Und ich habe meinen Vorschlag mit den Rezepten doch noch selbst ausprobiert. Das nutzt auch nichts.
Traldar verwandelte viel Eisen, Kohle, Riemen, Sandsteine in über hundert Bärenfallen, in tausend Wurfmesser, Speere usw. Die Elfe machte Sehnen zu Fallen und Riemen, Metallteile, Holz in Armbrüste, dazu noch Bolzen und Pfeile. Der Zwerg durfte Alchemie versuchen und Gulmondtee, Waffenbalsam, Heiltrank, KL-Elixier brauen. Nach verkaufen und abspeichern kam der Absturz.
Insgesamt hatte ich die Anzahl der Güter (im Sinne von gestapelten Einheiten) vermindert. Denn es wurden immer mehrere Stapel Rohgut in einen Stapel Endprodukt verwandelt. (Bei der Alchemie habe ich es aber nicht so genau genommen, denn hier sind Werkplatz und Händler räumlich weit getrennt.)

Insgesamt erachte ich den Spielstand 815 als hoffnungslos verfahren.

Noch was anderes: selbst wenn du mit den Rezepten warten willst, bis du alle beisammen hast und sie vergleichen kannst, empfehle ich dir die sofortige Übernahme ins Rezeptbuch. Dort gehören sie schlichtweg hin und dort vergeuden sie keinen Platz in Taschen oder Kisten.
Mittlerweile kannst du rund 80% aller Rezepte erwerben. Die Chance dass du die wertvollen Rezepte bereits erwerben kannst ist dementsprechend hoch.
Dabei ist DraSa nicht so linear gestaltet, daß es auf den Verkaufswert des Endproduktes ankommt. Ausschlaggebend ist nicht der Preis, sondern der Gewinn! Wertvolles, etwa der Zaubertank, braucht auch teure Zutaten die man nur selten im Spiel erbeutet (falls überhaupt). Und wenn du teure Zutaten kaufen mußt, dann zahlst du evtl. für die Zutaten mehr als du für den fertigen Trank bekommst.

[Kunar]

Den Zwölfen zum Gruße!

Würdest Du einen sozusagen jungfräulichen Spielstand nehmen, vom Beginn des Spiels, und dann x Gegenstände in eine Tabelle einfügen würdest, dann hättest Du den Fehler im Fall der Fälle sicher reproduziert. Darum geht es doch im Moment, oder?

Nein, es geht darum, ab welchem Datenbestand der Fehler nicht mehr auftritt. Bei der Radikallösung "alles im Hauptquartier löschen" geht es, aber das ist kein zufriedenstellender Stand, mit dem ich weiterspielen möchte. Seit klar ist, dass der unbearbeitete 815er-Spielstand nicht mehr geht und der mit deutlich weniger Gegenständen versehener 815er*, ist eine wichtige Frage, bei welcher maximalen Menge von Gegenständen, die irgendwo dazwischen liegt, das Spiel noch funktioniert.

815 / 815* / 816:
883 / 689 / 690 sonstige Gegenstände
1281 / 964 / 971 Waffen

Sonstiger Gegenstand 690 sind Giftzähne.
Waffen 965-971 sind Dummy, Wurfbeil, Dummy, Kurzbogen, Dummy, Kurzbogen, Dummy.

Die Dummys stehen anscheinend für die bloße Hand, mit der die verbliebenen Gegner gekämpft haben.
(...)
Da insbesondere die Waffentabelle voll ist mit Dummy- und Friedhofseinträgen, werde ich als nächstes testen, ob das Spiel wieder läuft, wenn man diese löscht.

Ich habe aus der _Instance_weapon mal alles gelöscht, was als Level die Angabe _graveyard_ hatte und als ID den Eintrag dummy. Das reduzierte die Anzahl an Waffen von 1281 auf 1198. Dennoch gab es noch Abstürze beim 2. Goblin. Danach habe ich generell alles aus der _Instance_weapon gelöscht, das sich im Level namens _graveyard_ befand. Damit schrumpfte die Anzahl der Gegenstände weiter auf 1011 zusammen. Damit ging dieser Kampf zuende. Beim nächsten Kampf eine Brücke weiter gab es jedoch wieder einen Absturz!

Nächste mögliche Schritte wären: Die offenen Gebiete schließen, auch wenn ich nach wie vor meine, dass das nicht Ursache der Abstürze ist. Dann könnte ich alle graveyard-Einträge aus allen Tabellen löschen und schließlich sogar alle Einträge aus bereits geschlossenen Locations.

Insgesamt erachte ich den Spielstand 815 als hoffnungslos verfahren.

Dem ist nicht so! Immerhin hatten wir bereits herausgefunden, dass sich durch Löschen von vielen Gegenständen der Kampf beenden läßt.

Heute ist mir noch eine andere Idee gekommen, die auf folgenden Informationen basierte:
1. Es gibt zwar einen Zusammenhang zwischen Anzahl der Gegenstände und den Abstürzen, aber er ist nicht völlig direkt. Ansonsten hätte das Spiel funktionieren müssen, nachdem ich 270 Gegenstände aus der Waffentabelle gelöscht habe. Das deutet darauf hin, dass die Anzahl der Gegenstände ein Symptom, aber nicht die Ursache ist.
2. Die Spielstände sind jeweils eine Datenbank.
3. Jemand äußerte den Verdacht, dass die Spielstände die magische Grenze von 64 MB überschreiten. Ich hielt das erst für unwahrscheinlich als eigentliche Ursache, zumal andere Leute ebenfalls so viel mitgenommen haben wie ich (mit Ausnahme der Zufallskämpfe im Dunkelwald).
4. Wenn man vor dem Abschluss der Queste "Das Auge des Drachen" Gegenstände an die Händler Floris oder Calandor Cupinez verkauft, verschwinden sie (die Gegenstände) aus deren Inventar. Die Spielstände werden jedoch nicht kleiner.

Wer sagt denn, dass die Spielstände besonders platzsparend angelegt sind? Gerade bei Datenbanken kann es passieren, dass Speicher nicht wieder freigegeben wird, selbst wenn Datensätze gelöscht werden. Eine kurze Recherche per Google ergab, dass es für SQLite einen Befehl namens "vacuum" gibt. (Man findet zahlreiche Beispiel dafür, wie man derzeit verwendete Firefox-Versionen beschleunigt, weil diese ebenfalls SQLite-Datenbanken einsetzen...) Und so geht's (Windows):

Von www.sqlite.org/download.html die sqlite3.exe holen ("Binary"). Diese in ein Verzeichnis mit dem Spielstand kopieren. (Vorher natürlich eine Sicherheitskopie des Spielstands machen - wir sind ja keine Anfänger!) Den Spielstand in irgendetwas umbenennen, was vorne 8 Zeichen hat (alte MS-DOS-Beschränkung). Dann auf Kommandozeilenebene wechseln und dort sqlite3 <Name des Spielstands> vacuum eingeben. Man kann außerdem dasselbe mit dem Befehl reindex machen, der die Indizes der Datenbank neu aufbaut.

Ergebnis bei mir (nur vacuum):
vorher 65.528 KB / 67.100.672 Byte
nachher 64.164 KB / 65.703.936 Byte

Und siehe da - der Kampf stürzt nicht mehr ab! Ich muss jetzt noch testen, ob das auch so anhält. Wenn es wirklich die magische Grenze von 64 MB war, habe ich die bald wieder erreicht. Im Zweifelsfall könnte ich dann jedoch mit den Dummy- und Friedhofsgegenständen wieder anfangen und erneut komprimieren. Interessant wäre noch, den Speicherplatzgewinn zu testen, wenn man wie oben beschrieben viele Gegenstände verkauft hat, die tatsächlich aus dem Spiel verschwinden.

[Kunar]

Den Zwölfen zum Gruße!

Heute ist mir noch eine andere Idee gekommen, die auf folgenden Informationen basierte:
(...)
Und siehe da - der Kampf stürzt nicht mehr ab! Ich muss jetzt noch testen, ob das auch so anhält.

Auch der zweite Kampf gegen die Goblins ist überstanden. Damit komme ich bis zu Archon Megalon und Ancoron. Diese Begegnungen waren auch dringend nötig für meine Motivation, weiterzuspielen!

Im zweiten Goblinkampf sterben gleich zu Anfang, noch bevor man selbst eingreifen kann, ein Edelmann und zwei Gardisten von Tallon. Hat die jemals jemand retten können? Mir erschien es so, als hätten die jeweils nur noch etwa 10 Punkte Lebensenergie und würden so oder so einen tödlichen Schlag abbekommen.

[Crystal]

Nein. Ich denke, es ist nicht vorgesehen, dass der Edelmann und seine Eskorte überleben. Warum auch immer...

[Kunar]

Den Zwölfen zum Gruße!

Im zweiten Goblinkampf sterben gleich zu Anfang, noch bevor man selbst eingreifen kann, ein Edelmann und zwei Gardisten von Tallon. Hat die jemals jemand retten können? Mir erschien es so, als hätten die jeweils nur noch etwa 10 Punkte Lebensenergie und würden so oder so einen tödlichen Schlag abbekommen.

Nein. Ich denke, es ist nicht vorgesehen, dass der Edelmann und seine Eskorte überleben. Warum auch immer...

Man kann sie tatsächlich retten! Wenn man sich langsam herantastet (noch auf der zweiten Brücke stehend), bis die Goblins generiert werden, kann man mit einem Fernkämpfer den ersten Goblin anvisieren. Dann beginnt der Kampfmodus. Wenn man rundenweise kämpft und oft speichert, kann man es schaffen. Leider haben alle drei Menschen nichts zu sagen. Aber das Gefühl, ein weiteres Mal Leute aus einer Notlage gerettet zu haben, ist Belohnung genug!

Mit dem Fortschreiten der Queste "Die Plünderer" konnte ich endlich mit dem Kobold in Kontakt kommen. Sein Rätsel ist sehr schön gemacht und nach einem freundlichen Plausch half er sogar, das Rezept für den Meistertrank zu korrigieren. Natürlich ging es sofort zurück nach Ferdok, um Auralia als Begleiter zu gewinnen. Sie bekam direkt lederne Beinschienen und als Bewaffnung einen Rabenschnabel plus Bock.

Da sich Ancoron wohl nur der Gruppe anschließen wird, nachdem die gesamte Queste abgeschlossen ist, und (laut Drakensang-Wiki, dass sich jedoch irren kann) danach die nachrückenden Gegnerwellen außerhalb Tallons versiegen, wäre es jetzt am besten, die Kämpfe hinter sich zu bringen. Optimal wäre natürlich, jeweils eine Welle für später übrig zu lassen. Ich schau mal, was der SQLite-Browser sagt bezüglich der Anzahl der Wellen...

[cvk]

Da sich Ancoron wohl nur der Gruppe anschließen wird, nachdem die gesamte Queste abgeschlossen ist, und (laut Drakensang-Wiki, dass sich jedoch irren kann) danach die nachrückenden Gegnerwellen außerhalb Tallons versiegen, wäre es jetzt am besten, die Kämpfe hinter sich zu bringen.

Würde ich nicht drauf wetten, ich meine mich düster zu entsinnen, dass ich zumindest die Goblingruppe hinter dem Felsen nach einer der Brücken immer mal wieder ignissphärisch begrüßen durfte. Aber auch nur beim ersten Mal, als ich da noch oft hin- und hergelaufen bin, später habe ich dann immer versucht die ganze Region in einem Rutsch zu machen und derlei Dinge wortwörtlich hinter mir zu lassen. Die Laufwege sind einfach der Horror.

[Kunar]

Den Zwölfen zum Gruße!

Und siehe da - der Kampf stürzt nicht mehr ab! Ich muss jetzt noch testen, ob das auch so anhält.

Leider kam bei der 3. Welle Goblins wieder ein Absturz. Ein erneutes Bereinigen brachte nur kurzzeitig Erleichterung. Aber ich habe noch einen weiteren kleinen Knüller auf Lager:

Wer sagt denn, dass die Spielstände besonders platzsparend angelegt sind? Gerade bei Datenbanken kann es passieren, dass Speicher nicht wieder freigegeben wird, selbst wenn Datensätze gelöscht werden.

In den Spielständen fand ich eine Tabelle namens _Instance_ActionDummy mit über 3000 Einträgen. Anhand der Ortsangaben konnte ich ermitteln, dass hier die gesamte Spielhistorie bezüglich Aufenthaltsorte pro Speichern festgehalten wurde. Bisher ersichtlicher Nutzen gleich 0. Nachdem ich die Tabelle (ausgenommen den aktuellsten Datensatz) komplett geleert hatte, konnte ich den Kampf weiterführen.

Allerdings habe ich erneut nur etwa 1 MB gewonnen. 64 MB scheint wirklich die magische Grenze zu sein. Oder hat jemand einen (deutlich) größeren Spielstand?

Da man mit dem SQLite-Browser auch noch locker vom Hocker SQL-Befehle absetzen kann, sehe ich recht zuversichtlich dem Vorhaben entgegen, weitere unnötige Daten aus dem Spielstand zu löschen. Der nächste Schritt wird darin bestehen, den verbrauchten Speicherplatz je Tabelle herauszufinden. Irgendwie müssen die 64 MB ja zusammenkommen.

[Crystal]

64 MB scheint wirklich die magische Grenze zu sein. Oder hat jemand einen (deutlich) größeren Spielstand?

Da man mit dem SQLite-Browser auch noch locker vom Hocker SQL-Befehle absetzen kann, sehe ich recht zuversichtlich dem Vorhaben entgegen, weitere unnötige Daten aus dem Spielstand zu löschen. Der nächste Schritt wird darin bestehen, den verbrauchten Speicherplatz je Tabelle herauszufinden. Irgendwie müssen die 64 MB ja zusammenkommen.

Meine Spielstände sind alle nur ca. 40 - 45 MB groß. Keine Ahnung, was sich da alles bei dir ansammelt, aber das wird wohl der Grund sein, warum bei mir das Spiel nie abgesoffen ist.

[Kunar]

Den Zwölfen zum Gruße!

64 MB scheint wirklich die magische Grenze zu sein. Oder hat jemand einen (deutlich) größeren Spielstand?

Meine Spielstände sind alle nur ca. 40 - 45 MB groß. Keine Ahnung, was sich da alles bei dir ansammelt, aber das wird wohl der Grund sein, warum bei mir das Spiel nie abgesoffen ist.

Gut zu wissen! Ich habe mir einen Deiner Spielstände mit allen Begleitern geholt. Der ist ja nicht weit von der Stelle entfernt, an der ich mich im Spiel befinde. Beachtlich ist, dass Dein Spielstand nur 28 MB groß ist - also nicht einmal die Hälfte von der 64-MB-Grenze. Entweder gibt es also noch eine viel zu große Tabelle bei mir (oder einen zu großen Index) oder es ist irgendwie anders Speicher verloren gegangen. Ich werde das genauer erforschen, am besten zuerst über die Anzahl der Datensätze pro Tabelle. Wenn da die Zahlen nicht völlig auseinander liegen, hat es nichts mit der Anzahl der Gegenstände an sich zu tun.

[Kunar]

Den Zwölfen zum Gruße!

Wer sagt denn, dass die Spielstände besonders platzsparend angelegt sind? Gerade bei Datenbanken kann es passieren, dass Speicher nicht wieder freigegeben wird, selbst wenn Datensätze gelöscht werden. Eine kurze Recherche per Google ergab, dass es für SQLite einen Befehl namens "vacuum" gibt. (Man findet zahlreiche Beispiel dafür, wie man derzeit verwendete Firefox-Versionen beschleunigt, weil diese ebenfalls SQLite-Datenbanken einsetzen...) Und so geht's (Windows):

Von www.sqlite.org/download.html die sqlite3.exe holen ("Binary"). Diese in ein Verzeichnis mit dem Spielstand kopieren. (Vorher natürlich eine Sicherheitskopie des Spielstands machen - wir sind ja keine Anfänger!) Den Spielstand in irgendetwas umbenennen, was vorne 8 Zeichen hat (alte MS-DOS-Beschränkung). Dann auf Kommandozeilenebene wechseln und dort sqlite3 <Name des Spielstands> vacuum eingeben. Man kann außerdem dasselbe mit dem Befehl reindex machen, der die Indizes der Datenbank neu aufbaut.

Ergebnis bei mir (nur vacuum):
vorher 65.528 KB / 67.100.672 Byte
nachher 64.164 KB / 65.703.936 Byte

Und siehe da - der Kampf stürzt nicht mehr ab! Ich muss jetzt noch testen, ob das auch so anhält. Wenn es wirklich die magische Grenze von 64 MB war, habe ich die bald wieder erreicht.

Übrigens hat auch der SQLite-Browser eine Funktion, um Datenbanken zu komprimieren. Man braucht also nicht unbedingt die sqlite3.exe, um die Spielstände kleiner zu machen.

Beachtlich ist, dass Dein Spielstand nur 28 MB groß ist - also nicht einmal die Hälfte von der 64-MB-Grenze. Entweder gibt es also noch eine viel zu große Tabelle bei mir (oder einen zu großen Index) oder es ist irgendwie anders Speicher verloren gegangen. Ich werde das genauer erforschen, am besten zuerst über die Anzahl der Datensätze pro Tabelle.

Glücklicherweise kann man mehrere Instanzen des SQLite-Browsers gleichzeitig aufmachen, wie ich erst jetzt festgestellt habe. Damit konnte ich zunächst feststellen, dass es nicht die Anzahl der im Spiel befindlichen Gegenstände ist, die den Spielstand so groß macht. Denn die Zahlen aus den betreffenden Tabellen weichen zwischen dem Spielstand von mir und dem von Crystal nicht so stark ab, dass sie diesen krassen Unterschied in der Größe der Spielstände erklären würden. Ich muss mir also nicht überlegen, irgendetwas zwangsweise zu verkaufen, zu verarbeiten oder gar wegzuwerfen.

(Ohnehin hatte ich bereits früher festgestellt, dass es diesbezüglich nichts bringt, Gegenstände zu verkaufen oder wegzuwerfen. Inventare von Händlern aus geschlossenen Gebieten bleiben komplett im Spielstand. Das Inventar der Händler Floris und Calandor Cupinez wird nach dem Abschluss der Queste "Das Auge des Drachen" zurückgesetzt bzw. erweitert. Alle Gegenstände, die man ihnen verkauft hat, bleiben jedoch im Spielstand und haben nach wie vor die Angabe, wo sie verkauft worden sind, also Ugdanhafen oder Grafenstadt. Wirft man Gegenstände weg, erhalten sie die Angabe "_graveyard", werden aber ebenfalls nicht aus dem Spielstand entfernt. Wenn überhaupt, muss man also knallhart Datensätze aus der Datenbank löschen und diese dann komprimieren.)

Leider kam bei der 3. Welle Goblins wieder ein Absturz. Ein erneutes Bereinigen brachte nur kurzzeitig Erleichterung. Aber ich habe noch einen weiteren kleinen Knüller auf Lager:
(...)
In den Spielständen fand ich eine Tabelle namens _Instance_ActionDummy mit über 3000 Einträgen. Anhand der Ortsangaben konnte ich ermitteln, dass hier die gesamte Spielhistorie bezüglich Aufenthaltsorte pro Speichern festgehalten wurde. Bisher ersichtlicher Nutzen gleich 0. Nachdem ich die Tabelle (ausgenommen den aktuellsten Datensatz) komplett geleert hatte, konnte ich den Kampf weiterführen.

Allerdings habe ich erneut nur etwa 1 MB gewonnen. 64 MB scheint wirklich die magische Grenze zu sein. (...)
Der nächste Schritt wird darin bestehen, den verbrauchten Speicherplatz je Tabelle herauszufinden. Irgendwie müssen die 64 MB ja zusammenkommen.

Der Vergleich der beiden Spielstände ergab drei große Unterschiede: Zum einen war das die o.g. Tabelle, die bei mir 3001 Datensätze enthielt, bei Crystal 237. Zweitens ist das die Tabelle _ProbeTable, die bei mir 1520 Datensätze enthielt, bei Crystal 295. Aber der wirklich große Brocken ist bei mir die Tabelle _Instance_EffectBox, die bei mir 152.879 Datensätze enthält (und damit mehr als alle anderen Tabellen der Datenbank zusammen - locker geschätzt sogar mehr als ein Vielfaches!), bei Crystal hingegen 17.569, also eine Dezimalstelle weniger. Damit sind drei Speicherfresser identifiziert! Mal sehen, wie die drei Tabellen bei einem neuen Spiel aussehen. Das dürfte Aufschluss geben über wirklich benötigte Datensätze.

[Kunar]

Den Zwölfen zum Gruße!

Der Vergleich der beiden Spielstände ergab drei große Unterschiede: Zum einen war das die o.g. Tabelle [_Instance_ActionDummy], die bei mir 3001 Datensätze enthielt, bei Crystal 237. Zweitens ist das die Tabelle _ProbeTable, die bei mir 1520 Datensätze enthielt, bei Crystal 295. Aber der wirklich große Brocken ist bei mir die Tabelle _Instance_EffectBox, die bei mir 152.879 Datensätze enthält (und damit mehr als alle anderen Tabellen der Datenbank zusammen - locker geschätzt sogar mehr als ein Vielfaches!), bei Crystal hingegen 17.569, also eine Dezimalstelle weniger. Damit sind drei Speicherfresser identifiziert! Mal sehen, wie die drei Tabellen bei einem neuen Spiel aussehen. Das dürfte Aufschluss geben über wirklich benötigte Datensätze.

Ich habe jetzt folgendermaßen gelöscht: Aus der _Instance_ActionDummy alles bis auf den neuesten Datensatz, aus der _ProbeTables alles und aus der _Instance_EffectBox alles bis auf die erste Kombination aus _Level und Name. Danach habe ich per sqlite3.exe und den Befehlen vacuum und reindex dafür gesorgt, dass nicht mehr benötigter Speicher freigegeben wurde. Vorher hatte der Spielstand eine Größe von 63,2 MB (64.795 KB), nachher 22,1 MB (22.717 KB). Mit anderen Worten: Mehr als 40 MB bzw. fast 2/3 unnötiger Speicherverbrauch je Spielstand! Das ist gelinde gesagt hochnotpeinlich, wenn man sich mit Datenbanken beruflich befasst.

Mein Problem scheint damit dauerhaft gelöst, aber ich komme nicht über die Ursache hinweg. Ohne entsprechende Datenbankkenntnisse (und Hilfe hier aus dem Forum) hätte ich keine Chance gehabt, das herauszufinden! Besonders getroffen bin ich davon, dass das Zumüllen des Spielstands durch jedes Speichern geschieht. Wer also wie ich sehr vorsichtig spielt, wird mit größeren Spielständen bestraft. Ebenso bestraft wird ein freies Herumreisen in der Welt, sprich jeder Ortswechsel. Das ist schon sehr hart.

[cvk]

Ebenso bestraft wird ein freies Herumreisen in der Welt, sprich jeder Ortswechsel. Das ist schon sehr hart.

Könnte aber auch der technische Grund für das Schließen von Gebieten sein: man hat zu spät gemerkt, dass man bei den Datenbanken Mist gebaut hat und musste dann eine kurzfristige Lösung finden. Und rein spekulativ ist das Schließen von alten Gebieten leichter umzusetzen, als die Umstrukturierung eines Datenbanksystems.

Ansonsten ist es halt immer sehr unwahrscheinlich, dass Spiele funktionieren, wenn man sie auf eine Weise spielt, die nicht vorhergesehen wurde. Eine gute Ausnahme, die mir im Augenblick einfällt ist Patrizier II. Das Spiel erfreut sich in einer kleinen Gemeinde bis heute großer Beliebtheit - vor allem wegen seiner Robustheit. Aus Sicht der "PowerGamer" (Ich sehe den Begriff nicht despektierlich, wie viele klassische Rollenspieler) wurde zB der Geldüberlauf dort utopisch niedrig angelegt, während er aus Sicht der Programmierer utopisch hoch angelegt war (irgendwo bei ein paar Milliarden). Allerdings stürzt das Spiel nicht ab, wenn man ihn erreicht, sondern kippt ins Minus und läuft dann von dort wieder hoch ...

Ohne entsprechende Datenbankkenntnisse (und Hilfe hier aus dem Forum) hätte ich keine Chance gehabt, das herauszufinden!

Da frage ich mich natürlich auch, ob ohne ein "Herumspielen" an der Spielmechanik das Problem überhaupt aufgetreten wäre. Ansonsten bin ich auch da wieder bei den Überlegungen zu absehbaren Spielarten: damit konnten die Programmierer nun wirklich nicht rechnen und mit einem Umgehen vorgesehener Sperren mittels Drittprogramm mussten sie auch nicht rechnen.
Ich hatte gerade noch einmal nachgesehen, und kein Spielstand bei mir kam über die 40 MB hinaus, selbst jene, bei denen ich (aus meiner Sicht - aus deiner wahrscheinlich noch nicht einmal im Ansatz ) exzessiv zwischen Städten hin- und hergereist bin, so lange sie offen waren, um Begegnungen zu provozieren. (Und gerade am Ende noch sehr häufig, da die letzten beiden ja dauerhaft offen bleiben)

PS.: Ich glaube jede Firma würde sich über dich als Betatester riesig freuen.

[Rabenaas]

Allerdings stürzt das Spiel nicht ab, wenn man ihn erreicht, sondern kippt ins Minus und läuft dann von dort wieder hoch ...

Das ist für Dich robust?

PS.: Ich glaube jede Firma würde sich über dich als Betatester riesig freuen.

Volle Zustimmung.

[Zurgrimm]

PS.: Ich glaube jede Firma würde sich über dich als Betatester riesig freuen.

Volle Zustimmung.

Das habe bei Lektüre dieses Threads auch schon das eine oder andere Mal gedacht. Mein nächster Gedanke war dann allerdings, ob die Zeit, die Kunar für einen Spieldurchlauf benötigt, nicht den Rahmen für jedes Testings sprengen würde.

[Kunar]

Den Zwölfen zum Gruße!

Könnte aber auch der technische Grund für das Schließen von Gebieten sein: man hat zu spät gemerkt, dass man bei den Datenbanken Mist gebaut hat und musste dann eine kurzfristige Lösung finden. Und rein spekulativ ist das Schließen von alten Gebieten leichter umzusetzen, als die Umstrukturierung eines Datenbanksystems.

Dagegen spricht, dass die wenigsten Datensätze beim Wechseln des Gebietes entstehen (dort nur eben automatisch zusätzlich, auch wenn man nicht speichert), sondern bei jedem Speichern. Dazu kommt, dass ich bisher so wenig wie möglich gereist bin, sondern wenn eben möglich in einem Gebiet geblieben bin.

Nein, wenn man dieses Mitloggen als Problem identifiziert hätte, wäre die einzige vernünftige Lösung gewesen, das auszustellen. Ich kenne natürlich nicht den Quellcode und weiß daher nicht, ob das an einer Stelle zentral geregelt wurde oder ob das zum Beispiel in zig Unterfunktionen drin war. Sinnvoller wäre natürlich, eine zentrale Loggingfunktion zu haben, die dann jeweils aufgerufen wird. Aber man merkt, es wird sehr technisch, und ich möchte keine Leser verschrecken.

Ansonsten ist es halt immer sehr unwahrscheinlich, dass Spiele funktionieren, wenn man sie auf eine Weise spielt, die nicht vorhergesehen wurde.

Da frage ich mich natürlich auch, ob ohne ein "Herumspielen" an der Spielmechanik das Problem überhaupt aufgetreten wäre. Ansonsten bin ich auch da wieder bei den Überlegungen zu absehbaren Spielarten: damit konnten die Programmierer nun wirklich nicht rechnen und mit einem Umgehen vorgesehener Sperren mittels Drittprogramm mussten sie auch nicht rechnen.

Das Wiederfreischalten der Gebiete alleine hat die Spielstände nicht vergrößert. Außerdem bin ich nach Avestreu und Moorbrück nur jeweils einmal gereist, also kam auch fast nichts durch Reisen hinzu.

Wenn denn meine Herangehensweise an die Zufallskämpfe in den Blutbergen so "nicht vorgesehen" war: Ja, warum haben die Entwickler denn dann überhaupt so viele Zufallskämpfe und nachrückende Gegnerwellen definiert?

Ohne die Drittprogramme wie SQLite-Browser und sqlite3.exe wäre Drakensang bei mir nicht mehr spielbar. Insofern kann ich noch froh sein, dass kein proprietäres Format bei den Spielständen verwendet wurde, denn dann hätte ich gar nichts mehr hinbiegen können!

Ich hatte gerade noch einmal nachgesehen, und kein Spielstand bei mir kam über die 40 MB hinaus, selbst jene, bei denen ich (aus meiner Sicht - aus deiner wahrscheinlich noch nicht einmal im Ansatz ) exzessiv zwischen Städten hin- und hergereist bin, so lange sie offen waren, um Begegnungen zu provozieren. (Und gerade am Ende noch sehr häufig, da die letzten beiden ja dauerhaft offen bleiben)

Wie schon oben erwähnt: Ich bin so selten wie möglich zwischen den einzelnen Orten hin- und hergereist.

PS.: Ich glaube jede Firma würde sich über dich als Betatester riesig freuen.

Volle Zustimmung.

Das habe bei Lektüre dieses Threads auch schon das eine oder andere Mal gedacht. Mein nächster Gedanke war dann allerdings, ob die Zeit, die Kunar für einen Spieldurchlauf benötigt, nicht den Rahmen für jedes Testings sprengen würde.

Immer wenn man ein Kompliment bekommt, ist Zurgrimm zur Stelle, um einen wieder zu erden. Und es soll auch nicht anders sein.

Tatsächlich habe ich beruflich oft genug mit Datenbanken und Tests zu tun gehabt. Insofern ist das kein neues Gebiet für mich. Mein Hang zum Detailfanatiker, der Extremsituation berücksichtigt, hat da schon oft genug den Unterschied zwischen Erfolg und Misserfolg ausgemacht.

Ich weiß natürlich auch, dass Tests immer gewisse Grenzen haben. Man hat nicht unendlich Budget und Zeit. Die Sache mit der Spielstandsgröße fällt etwa nur dann auf, wenn man sehr häufig speichert - was allerdings gerade bei Tests schnell vorkommen kann. Vielleicht waren die mitgeloggten Informationen sogar für Testzwecke eingesetzt worden. Man kann ja zumindest grob nachvollziehen, was der Spieler bisher alles gemacht hat. Der Fehler ist deswegen so peinlich, weil es eine so grundlegende Sache ist. Ein Spielstand direkt nach Spielstart hat etwa eine Größe von 20 MB. Bei mir in Tallon sind es etwa 22 MB. Das bedeutet, dass ein Großteil aller Spielstände nur aus Datenmüll besteht, den keiner braucht.

[Silencer]

Wenn denn meine Herangehensweise an die Zufallskämpfe in den Blutbergen so "nicht vorgesehen" war: Ja, warum haben die Entwickler denn dann überhaupt so viele Zufallskämpfe und nachrückende Gegnerwellen definiert?

Ohne die Drittprogramme wie SQLite-Browser und sqlite3.exe wäre Drakensang bei mir nicht mehr spielbar. Insofern kann ich noch froh sein, dass kein proprietäres Format bei den Spielständen verwendet wurde, denn dann hätte ich gar nichts mehr hinbiegen können!

Da die Ursache für dieses Problem (Größe der Datenbank) bisher nicht eindeutig identifiziert werden konnte, sehe ich auch keinen Grund, deine Spielweise explizit als Hauptursache dafür anzunehmen. Es mag irgendwie damit zusammenhängen, zumindest würde man das wohl zunächst vermuten, könnte aber letztendlich auch etwas ganz anderes sein. Insofern sich in deinen Dateien scheinbar ein zuviel an Datenbankeinträgen angestaut hat, würde mich natürlich schon interessieren, ob dies ebenfalls aufgetreten wäre, wenn du anders gespielt hättest, aber evtl. findet man die eigentlich Ursache nie und beim nächsten Mal, tritt das Problem in dieser Form garnicht erst auf. Deine bisherigen Erkenntnisse werfen ja eher noch mehr Fragen auf, aber zumindest konntest du den wahrscheinlichsten Grund für diese Abstürze ermitteln und anscheinend beheben. Ich habe auch nochmal bei meinen letzten Savegames nachgeschaut und deren Größe liegt trotz Itemansammlung auch nur zwischen 30 und 40 MB. Btw wieviele Spielstände hattest du insgesamt angelegt?

[Crystal]

Aber man merkt, es wird sehr technisch, und ich möchte keine Leser verschrecken.

Kannst du ja gesondert im technischen Forum behanden, wenn du möchtest.

Btw wieviele Spielstände hattest du insgesamt angelegt?

Der Zahl seines zur Verfügung gestellten Savegames nach zu urteilen, mindestens 815. Man müsste hier Kunar eher fragen, wie groß seine Plattenpartition bzw. wieviel davon noch frei ist. Mir wäre ja die Scrollerei im Ladefenster zu unübersichtlich, aber jeder wie er mag.

Zur Speicherfrage: Ich spiele selbst hauptsächlich mit nur einem Spielstand, bestenfalls mit zweien, selten bis gar nicht mit dreien oder mehreren. Wenn ich am Ende angekommen war, hab ich mir jeweils immer den Endspielstand behalten oder habe die Savegames gelöscht, die mit älteren Revisionen bespielt wurden bzw. ohne Mods.

Dabei bin ich jedes Mal nicht annähernd an die 64 MB-Marke gekommen. Sehr seltsam. Bin gespannt, was Kunar weiter rausfindet.

[Kunar]

Den Zwölfen zum Gruße!

Btw wieviele Spielstände hattest du insgesamt angelegt?

Der Zahl seines zur Verfügung gestellten Savegames nach zu urteilen, mindestens 815. Man müsste hier Kunar eher fragen, wie groß seine Plattenpartition bzw. wieviel davon noch frei ist. Mir wäre ja die Scrollerei im Ladefenster zu unübersichtlich, aber jeder wie er mag.

Beim Anlegen eines neuen Spielstands wird die höchste Zahl aller vorhandenen Spielstände genommen und um eins erhöht. Die Zahl 815 bedeutet also nicht, dass es auch tatsächlich 815 Spielstände sind, da ich ja zwischendurch einige gelöscht haben kann (was ich auch wirklich gemacht habe). Es sind mehrere Hundert Spielstände, die ich jedoch größtenteils auf eine externe Festplatte ausgelagert habe, weil es zu viele wurden und sie zuviel Platz wegnahmen.

Da die Ursache für dieses Problem (Größe der Datenbank) bisher nicht eindeutig identifiziert werden konnte, sehe ich auch keinen Grund, deine Spielweise explizit als Hauptursache dafür anzunehmen. Es mag irgendwie damit zusammenhängen, zumindest würde man das wohl zunächst vermuten, könnte aber letztendlich auch etwas ganz anderes sein. Insofern sich in deinen Dateien scheinbar ein zuviel an Datenbankeinträgen angestaut hat, würde mich natürlich schon interessieren, ob dies ebenfalls aufgetreten wäre, wenn du anders gespielt hättest, aber evtl. findet man die eigentlich Ursache nie und beim nächsten Mal, tritt das Problem in dieser Form gar nicht erst auf. Deine bisherigen Erkenntnisse werfen ja eher noch mehr Fragen auf, aber zumindest konntest du den wahrscheinlichsten Grund für diese Abstürze ermitteln und anscheinend beheben. Ich habe auch nochmal bei meinen letzten Savegames nachgeschaut und deren Größe liegt trotz Itemansammlung auch nur zwischen 30 und 40 MB.

Es ist eine gute Herangehensweise, nicht automatisch davon auszugehen, dass meine Spielweise die Größe der Spielstände ausgelöst hat, nur weil das das einzige bisherige Unterscheidungskriterium zwischen meinen Spielständen und denen anderer Spieler ist. Allerdings sehe ich es inzwischen als erwiesen an, dass tatsächlich die zu großen Spielstände die Abstürze auslösten. Dazu kommt, dass ich wieder etwas weitergespielt habe und sich zwei der drei erwähnten Tabellen wieder etwas gefüllt haben (nur die für die Proben nicht - aber Proben habe ich in der Zwischenzeit auch nicht abgelegt). Die Spielstände sind auch schrittweise um einige MB gewachsen. Das ist für mich der letzte Beweis, dass häufiges Speichern die Tabellen zumüllt und das wiederum die Spielstände unnötig groß macht.