Problem beim Abspeichern

Alles über Age of Empires II außerhalb des Map-Design

Moderatoren: Henning, Barbarossa

Servus zusammen,
hab wieder mal ein Problem mit dem ansonsten bug-freien Spiel. ;)

Und zwar: Ich bastle grad an einem Szenario, bin schon fast fertig, und teste es hin und wieder. Und jetzt das Problem: Ich kann nämlich nur einmal abspeichern. Wenn ich ein weiteres mal abspeichere, auch unter einem anderen Namen, schmiert Age ab! :mad:

Hatte jemand schon ein ähnliches Problem, oder weiß jemand woran das liegt :confused:

Wär ja echt ärgerlich, wenn ich es hier uploade und jeder von euch kann nur einmal speichern. :rolleyes:
Ist das denn nur bei deiner Age-Kopie so? Vielleicht solltest du es mal mit einer anderen CD probieren...

Mir fallen auf die Schnelle nur zwei mögliche Ursachen ein, von denen eine unwahrscheinlicher ist als die andere und die du auch nicht beheben kannst:

1. Der SaveGame-Ordner wird bei Speichern versehentlich geschützt und verweigert dem Spiel den Zugriff. Idee: Zeigt die Firewall was an?

2. Beim Schreiben in Dateien wird ein "Stream" auf die Datei erstellt, und zwar durch die Funktion "fopen". Dadurch wird die Datei geöffnet und geleert. Per "fwrite" werden dann die Daten in die Datei geschrieben. Wenn jetzt aber aus irgendwelchen Gründen nicht "fclose" aufgerufen wird, bleibt die Datei geöffnet und damit schreibgeschützt, was bei mangelhafter Fehlerbehandlung im Programmcode durchaus zu Abstürzen führen kann.

--

Wenn ich jetzt so schreibe, fällt mir noch viel mehr ein... :D

Schau direkt nach einem Absturz bitte mal in Systemsteuerung => Verwaltung => Ereignisanzeige => Windows Protokolle => Anwendung, ob da irgendwas als "Fehler" vezeichnet ist (rotes Ausrufezeichen normalerweise). Evtl. steht in der "Quelle"-Spalte "Application Error", dann findest du den Fehler noch schneller.
Normalerweise steht da etwas - wenn da wirklich was auftaucht, poste bitte den gesamten Inhalt des Textfelds hier.
Jan, danke dir für die schnelle Antwort. Das kann ich aber leider erst heut abend ausprobieren, wenn ich wieder zu Hause bin. Kriegst dann Bescheid :)
Ja, ich schau hier nachher nochmal rein... :)
Es kann auch an einem Map-Design Fehler liegen.
Dave hatte dieses Problem früher oft.
Sieh mal nach, ob Berge zu dicht an den Szenario-Rand kopiert sind, dies führt oft zu Speicherbugs.
Desweiteren kann auch an einer anderen Stelle das Design fehlerhaft sein. Einfach mal eine Sicherheitskopie erstellen und dann mittels "Wüste" auf "groß" die gesamte Map durchkreuzen und mit Wüste "überschreiben". Stürzt dabei der Editor an irgendeiner Stelle ab, ist das Design dort fehlerhaft und bedarf einer Korrektur.
Es gibt Zufälle: Hab grad was im Forum gesucht, da fiel mir folgender Thread in die Hände:
Wunder der Technik.

Enthält eine ähnliche Problembeschreibung, vielleicht trifft das ja auch ungefähr zu. Aber eine Lösung scheint es auch nicht gegeben zu haben...oder, Barbarossa? :)
Zitat Barabrossa
PC-Eigenmächtigkeit #1:
Beim Teststart eines Szenarios schmierte das Spiel aus unerfindlichen Gründen sauber ab (soweit nix ungewöhnliches), aber jetzt kommt der Hammer:
jedesmal wenn ich das Szenario wieder testen will, schmiert es unmittelbar nach der "Spiel wird gestartet"-Meldung erneut ab! Außerdem ist die Datei plötzlich von ~200 kb Größe auf 400(!) kb angewachsen, obwohl NICHTS wesentliches verändert wurde!
Der Fehler ließ sich erst beheben, als ich dem Szenario einen neuen Namen gab (z.B. A2 statt A1). Der Fehler tritt aber fortan immer auf, wenn ich ein Szenario mehr als 1 Mal unter dem selben Namen speichere und teste! Für jedes Testspiel muß ich also einen neuen Namen eingeben und die Karte unter diesem Namen öffnen.
Ansonsten funktioniert das Szenario aber immer tadellos (Schalterfehler o.ä. ausgeschlossen).
Jetzt der Hit: lösche ich eines der umbenannten (mutmaßlich fehlerhaften) Szenarios und speichere eine Nachfolgeversion unter einem bereits einmal verwendeten Namen ab(also ohne zu überschreiben), tritt der Fehler wieder auf!
Es scheint also irgendwie mit dem NAMEN zusammenzuhängen...


Genau das gleiche Prolbem habe ich mit diesem Szenario auch :mad:
@Janworks

So, hier hab ich die Datei (hoffe es ist das was du gemeint hast)

Bild
Hm, gut, das sagt mir erstmal nicht viel. Kannst du bitte mal den Inhalt von "Daten" posten? Am besten in code-Tags, dann geht die Formatierung nicht verloren...ich seh da auf die Schnelle jetzt auch nicht, woran es lag, aber vllt helfen ja die Daten...

Zu Barbas-Uralt-Thema / @Barbarossa:
Hat sich das Problem denn bei dir gelöst?
Aber eine Lösung scheint es auch nicht gegeben zu haben...oder, Barbarossa? :)
Leider nein, und der Sachverhalt war auch etwas anders.
Daher hab ich vorhin auch mein Posting abgebrochen, als ich deinen Beitrag gesehen habe (falls dein Vorschlag für Braggl hilfreich gewesen wäre).

@Braggl:
Soweit ich verstanden habe, ist es aber bei dir doch etwas schlimmer? Weil bei mir hat die Namensänderung ja noch was gebracht - bei dir wirkt scheints ja noch nicht einmal das! :(

Soweit ich mich erinnern kann, ist der Fehler damals zeitweise nach einem Neustart wieder verschwunden, später aber wieder aufgetreten. Ist allerdings auch ne ganze Ecke her, aber die scx (das heutige Arcanea) dürfte in seiner Endversion diesen Fehler noch heute (zumindest bei meinem Age) in sich tragen.
als Bytes

0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 61 67 65 ure age
0018: 32 5f 78 31 2e 65 78 65 2_x1.exe
0020: 20 30 2e 37 2e 32 36 2e 0.7.26.
0028: 38 30 39 20 69 6e 20 61 809 in a
0030: 67 65 32 5f 78 31 2e 65 ge2_x1.e
0038: 78 65 20 30 2e 37 2e 32 xe 0.7.2
0040: 36 2e 38 30 39 20 61 74 6.809 at
0048: 20 6f 66 66 73 65 74 20 offset
0050: 30 30 31 38 39 33 63 31 001893c1
0058: 0d 0a ..

als Wörter

0000: 6c707041 74616369 206e6f69 6c696146
0010: 20657275 65676120 31785f32 6578652e
0020: 372e3020 2e36322e 20393038 61206e69
0030: 5f326567 652e3178 30206578 322e372e
0040: 30382e36 74612039 66666f20 20746573
0050: 38313030 31633339 0a0d

EDIT: Ich kann übrigens so oft speichern (unter gleichem oder anderem Namen) bis ich diesen Spielstand lade. Er lässt sich ohne Probleme laden, aber danach kann man nicht mehr speichern, ohne dass Age abschmiert

EDIT2: Szenario umbenennen hab ich noch gar nicht probiert. Du meinst ja nicht im Szenarioeditor neu abspeichern sondern im Age-Ordner in Windows umbenennen, oder?
@Fehlermeldung:

Gut, daß ist die übliche Fehlermeldung bei einem Absturz von AoK in der Dateiverwaltung. Daran kann man aber kaum ablesen, WARUM genau das scx nun abschmiert. :(

Zum Sachverhalt:

Bei mir damals ging es auch nicht um eine savegame, sondern um das scx selbst. Ich konnte das fehlerhafte einfach kein zweites Mal starten, selbst als cpx nicht.
Dazu mußte ich jedesmal einen neuen Namen verwenden - SPIELSTÄNDE konnte ich aber soweit ich mich erinnere aber dann ganz normal anlegen und laden.
So, hab jetzt alles ausprobiert. Hab das Szenario in Age umbenannt, auch in Windows, hab eine Cpx draus gemacht. Nützt alles nix :mad:

Liegt aber nicht an Age allgemein. Bei jedem anderen Scx klappts prima

Grad jetzt, in so ner späten Phase. Des nervt echt voll :KopfgegenWand:
@Braggl:

Hm, sagt mir zwar was, aber nicht viel mehr als im Text darüber steht.
Hab außerdem noch ein bisschen recherchiert, aber nichts dazu gefunden.

Wenn wir den Quellcode hätten, wäre dieses Problem bestimmt zu lösen - ansonsten kann ich dir nicht mehr weiterhelfen. :(

EDIT: Hast du vllt einmal das AOKTS angewandt?
Was ich grad noch festgestellt habe: Wenn man ein zweites mal speichert, also nachdem man den spielstand geladen hat und während age dann abschmiert, hat die gax-Datei ca. 700kb mehr als nach dem ersten speichern :confused:

EDIT: Ich wollte es mal in AOKTS öffnen, aber das ging nicht (siehe meinen anderen Thread).
Oha...kannst du mir das mal schicken? Ich muss es selbst sehen, sonst kann ich nicht viel machen... :)
Ok, E-mail hab ich dir geschickt.

Bringt dir eigentlich auch die Meldung was, die Age dirket nach dem Abschmieren bringt?

EDIT: Ich weiß jetzt wie MappingFan sich fühlt :(
EDIT: Ich weiß jetzt wie MappingFan sich fühlt :(
Jap, es ist beschissen. :( Alles ist nicht mal weg, aber wertlos.
Hab zwar noch ein Backup, bei dem der Fehler nicht auftritt, aber da müsste ich alle 350 Schalter nochmal eingeben. Das wird ein Spaß :rolleyes:
Das mit der plötzlichen Dateigrößenerhöhung trat bei mir damals auch auf.
Das ist halt eine sehr leidige Sache mit solchen unvorhersehbaren und folgenreichen Crashs.
Ich hab seinerzeit auch Zeter und Mordio gebrüllt - gerade WEIL ich beim Mappen eigentlich schon immer sehr systematisch vorgegangen bin. :KopfgegenWand:

Ich habs mir seither zu Gewohnheit gemacht, nicht nur immer in fortlaufenden Versionen Backups zu erstellen (notfalls jeden Tag!! eine neue Version), sondern auch von der allerneuesten immer ZWEI Dateien absolut synchron zu halten: einmal das eigentliche Szenario (z.B. "Map v1.22" ) und ein Klon davon ("Map v1.22 TEST" ), der regelmäßig von ersterer überschrieben wird und AUSSCHLIESSLICH für Tests verwendet wird.
Die richtige Map dagegen wird NIEMALS selbst getestet.
Das ist IMO die einzig effektive Vorgehensweise, um das Fehlerpotential solch verhängnisvoller Crashs maximal zu reduzieren. Nämlich auf höchstens den Verlust der Arbeit eines einzigen Tages...
Hab zwar noch ein Backup, bei dem der Fehler nicht auftritt, aber da müsste ich alle 350 Schalter nochmal eingeben. Das wird ein Spaß :rolleyes:
*Idee*
K.A. ob das funzt (ggf.z.B. Findig mal anschreiben) - aber möglicherweise kannst du das fehlerhafte scx im Triggerstudio öffnen und die Schalter in die (in einem zweiten Triggerstudio) geöffneten Backup-Datei kopieren?