Makeobj bricht Stapelverarbeitung, bei Fehler in einer dat ab

[The Transporter]

Makeobj wird per Script angewiesen, unser Grafikset zu paken. Pro Aufruf wird 1 Unterordner abgearbeitet. Hat 1 dat im gerade bearbeiteten Ordner einen Fehler bricht makeobj ab. Die restlichen Objekte werden nicht bearbeitet. Die in der Logdatei gespeicherten (falls überhaupt) Fehlermeldungen sind aber keiner dat zugeordnet.
Gespeichert wurde das fehlen einer Ladungsgrafik, aber ohne verweiß auf die betroffene dat. Nicht gespeichert wurde der Hinweis auf eine nicht vorhandene Grafikposition.
Die Fehlersuche war recht mühsam. Am Schluß habe ich die Fehler, nur durch das einzelne paken, aller in Frage kommenden Objekte, gefunden.

[prissi]

So, was willst du denn geändert haben? Makeobj gibt im verbose Modus viel mehr Meldungen aus.

Allerdings gibt es ein printf: "Reading file: xyz.dat", das irgendwo vor dem fehlerhaften Kommando stehen sollte.

[partyschreck]

Ich kämpfe auch gerade mit dem Problem.
Das einzig Sinnvolle,was mir einfällt, ist die Stapeldatei, jeweils in zwei Hälften zu teilen, anstatt jedes Objekt einzeln zu testen, um die fehlerhafte Datei zu entdecken.
Die Meldung "There is a possibility of not operating correctly though the makeobj work ended" erfüllt einen auch nicht gerade mit Weisheit.

[The Transporter]

Das ist aber nur eine wirklich gute Lösung bei genau 2 Objekte im Ordner
Die bei uns betroffenen Ordner enthalten 10 bzw. 17 Objekte. Da ist auch bei einer 2teilung immer noch genügend Platz um den Fehler zu suchen.
Am meisten Zeit hat die Einkreisung der Fehlerursache gekostet.
Wenn aus einem Ordner 17 neue Objekte generiert werden sollen, aber nur 1 rauskommt, und keine Fehlermeldung dazu vorhanden ist, kannste erstmal suchen, wo der Fehler liegt. Anfangs war die Meldung vom ignorieren des Alphakanals da. Nachdem ich alle Grafiken mit Gimp überprüft, und die eine korrigiert hatte, wurde immer noch nur 1 pak generiert. Es war aber jetzt keine Fehlermeldung mehr vorhanden. Nach dem mühsamen durchsuchen der dat habe ich dann die paks einzeln mit pakhelper erstellt, und immer die Logdatei von Pakhelper geprüft. Da erst erhielt ich eine Fehlermeldung, und in der Log stand dann die Ursache.

In der Pakhelper Log steht die Fehlermeldung von makeobj. Beim einzelnen paken reicht die Meldung vollkommen aus, da ja eindeutig klar ist, um welche dat bzw. png es sich handelt. Bei einer Stapelverarbeitung wäre es schön, wenn in der Fehlermeldung auch die dat angezogen wird. Dann weiß man wenigstens, bei welcher dat der Fehler liegt.
Bei der Stapelverarbeitung wird eine andere Reihenfolge abgearbeitet, als sie im Dateimanager angezeigt wird. Dadurch kann man von der letzten erfolgreich bearbeiteten Datei nicht automatisch auf die nächste zu verarbeitende Datei schließen.

Die Meldung "There is a possibility of not operating correctly though the makeobj work ended"

Da ist meistens noch ein Alphakanal in der Grafik enthalten. Der wird zumindestens bei einzelverarbeitung ignoriert. Ob der "Fehler" Hinweis eine Stapelverarbeitung abbrechen kann, weiß ich nicht.

[Wurzelgnom]

Welche pak-Dateien zuletzt erzeugt wurden erkennt man am Zeitstempel, der zumindest auf die Minute erfasst.

An Hand der Namen sollte sich dann auch der betreffende Ordner finden lassen.

Ich hab/hatte immer ne create.bat/sh in jedem Ordner, mit der ich bei Änderungen immer die pak-Dateien des Ordners erstellt hab, bis alles korrekt funktioniert.

Also wenn ne dat-Datei geändert wurde sollte man schon testen ob dann auch ne pak-Datei korrekt erzeugt wird.

Sollte ein SVN zu Grunde liegen sollten da wiederum eben nur getestete und damit funktionierende Dateien hoch geladen werden.


Also von daher sind fehlerhafte Dats bei Setgenerierung Entwicklerfehler und nicht ein Fehler/Problem von Makeobj.

@partyschreck
Da ist es sinnvoller in die Stabel-Datei "Pause" an den Zeilenanfang dazwischen zu schreiben.
Die Verarbeitung hält dann an und geht erst nach Tastendruck weiter.

Dann kann man auch die Textausgabe kontrollieren und auf Fehler abklopfen. Gerade die Pfade stimmen bei Fehlern dann oft nicht mehr.

@The Transporter
Im allgemeinen werden Dateien in einer bestimmten Reihenfolge eingelesen.

Welche jetzt Makeobj benutzt weis ich nicht.

Würde aber auf Alphabetisch tippen.
Demzufolge wäre es die 2. Dat-Datei bei alphabetischer Sortierung.

[The Transporter]

Das ganze ist beim "Probepacken" vor dem hochladen ins SVN geschehen.
Der Ordner ist von vornherein klar, da ja von dem betroffenen Ordner die Objekte nicht gepakt wurden. Es geht nicht um Ordner, sondern um eine Angabe der betroffenen (fehlerhaften) dat.

Also von daher sind fehlerhafte Dats bei Setgenerierung Entwicklerfehler und nicht ein Fehler/Problem von Makeobj.

Das ist ja auch nirgends behauptet worden!!!

Würde aber auf Alphabetisch tippen.

Dem ist leider nicht so, da wäre ja die Fehlersuche recht schnell erledigt gewesen.

[Wurzelgnom]

Würde aber auf Alphabetisch tippen.

Dem ist leider nicht so, da wäre ja die Fehlersuche recht schnell erledigt gewesen.

Alternative, sofern der Ordner bekannt ist

Alle Dats umbenennen in .dat_ und dann einzeln zurück benennen und Makeobj aufrufen.

Da wo dann keine korrekte/plausible pak-Datei entsteht ist der Fehler.

[The Transporter]

Das einzeln paken ist mit Pakhelper dann wesentlich leichter und schneller.

[partyschreck]

Ich habe jetzt nicht mehr weiterprobieren können, weil ich den Fehler schnell gefunden hatte.
Zumindest, wenn der Fehler darin liegt, dass eine png Datei fehlt, scheint es mir einfach zu lösen, da hier bei mir eine Pak-Datei erstellt wurde, die aber an der Größe von 1KB zu entdecken war.
Ich weiß aber nicht, ob das bei Fehlern innerhalb der dat Datei auch so ist.
Da werde ich mich dann an den Halbierungsmechanismus halten, da reduziert man die notwendigen Arbeitsschritte schon stark.

[The Transporter]

Das pak ist immer 1kb (Angezeigt) groß, wenn ein Fehler in der dat auftritt, der verhindert, das die Grafik dazugepackt wird. Eine 1kb große pak Datei zeigt immer an, das etwas schief gelaufen ist. Das was zu finden ist eine andere Sache. Oft hilft die Log datei weiter, aber nicht immer.