[Gottfried]

DecDat

Der eine oder andere erinnert sich vielleicht noch an das, ebenfalls von mir zusammengeschraubte Tool ReaDat. Das hier vorgestellte DecDat (Oder kurz: "d2") kann ungefähr als großer Bruder von ebendiesem betrachtet werden.

Aber wozu braucht man einen großen Bruder? DecDat kann etwas mehr als ReaDat, und das was ReaDat konnte in verbesserter Art und Weise.
ReaDat konnte benutzt werden um sich den Inhalt einer Dat zu Gemüte zu führen. Es wurden alle Symbole aufgelistet und über verschiedene Tabellen verteilt, Funktionen, Instanzen und Prototypen konnte man sich in Form der Parsertokens genauer ansehen.
DecDat geht noch einen Schritt weiter: Es ist möglich den Daedaluscode (fast*) in seiner Urform anzuzeigen. Das konnte der GothicSourcer auch, allerdings hat der bei schmutzigeren Angelegenheiten (Ikarus und LeCo.) gerne aufgegeben.

Neben diesem neuen Hauptaspekt, der Möglichkeit die Dat vollständig als Daedalusscript zu rekonstruieren (Über die Exportdefinition auch über mehrere Dateien verteilt) wurde das Interface überarbeitet. Es gibt nur noch eine Tabelle in der alle Symbole aufgelistet sind, dafür ist ein neues Suchfeld hinzugekommen, das mit Regulären Ausdrücken gefüttert werden kann. (Das fehlende Suchfeld hat ReaDat ziemlich nutzlos gemacht, finde ich.)
Bisher ist nur die Suche nach ID, Typ und Name möglich, mir ist bewusst dass das immer noch beschränkt ist, aber immerhin besser als nichts.

Ohne jetzt zu weit abzuschweifen: Ich habe dieses Tool aus zwei Gründen erstellt.

1. Ich habe den Quellcode von ReaDat verloren und es ist unwartbar geworden - trotz einiger Makel die ich noch ausmerzen wollte
2. Ich brauchte eine verlässliche Möglichkeit eine .dat wieder zu rekonstruieren. (Auch mit anspruchsvollerem Code, den der Gothicsourcer nicht packt.)

Das Tool kann, wie ReaDat auch, genutzt werden um den Bytecode besser zu verstehen, gleichzeitig kann es als letzter Notnagel verloren geglaubter Skripte dienen.
Zu der mysteriösen "Exportdefinition", sowieso zu den Regulären Ausdrücken und den Kürzeln der Tokens sind knappe Hilfedateien in das Programm integriert.

* Beim Parsen der Scripte gehen ein paar Informationen verloren, so kann es sein dass ein Instanzname als int interpretiert wird oä. Wer wirklich eine .dat vollständig benutzbar machen möchte, sollte auf jeden Fall die Reihenfolge der Symbole einhalten!
Desweiteren geht natürlich die Formatierung verloren.


Dieses Programm wurde entgegen der anderen Tools die ich bisher hier her geschleppt habe nicht mit C# angefertigt, sondern mit Java. (Swing für die Oberfläche.)
Ich kann bisher noch keinen fehlerfreien Export garantieren. Wer einen Fehler findet möge ihn bitte melden!

In weiser Vorraussicht hänge ich den Quellcode dieses Mal direkt an. Ich möchte ihn nicht nochmal verlieren

Ich wünsche allen interressierten ein fröhliches Dekompilieren!

MfG Gottfried

[NicoDE]

Dein Programm ist großartig!
Es wird mir in ein paar Wochen die Arbeit wesentlich vereinfachen. Vielen vielen Dank für die Mühen und das Bereitstellen der Quelltexte.

ps@Lehona: Netter Versuch

[Lehona]

Dein Programm ist großartig!
Es wird mir in ein paar Wochen die Arbeit wesentlich vereinfachen. Vielen vielen Dank für die Mühen und das Bereitstellen der Quelltexte.

Da du dich in Rätseln ausdrückst übernehm ich das mal: Wirst du uns eventuell mitteilen wofür du DecDat benutzen möchtest? Klingt ja doch sehr interessant.

Edit: Immer diese Geheimniskrämerei *mecker*

[Marcello]

hallo gottfried,

ich hoffe, ich habe das richtig verstanden: man kann mit deinem programm sozusagen kompilierte dateien manipulieren und sie wieder über die exportfunktion z.b. als .dat zusammenfügen, d.h. das original wurde dann verändert, auch wenn ein paar infos verloren gehen?

unabhängig davon gefällt es mir wirklich gut.

[Lehona]

Man kann damit kompilierte .dat-Dateien (evtl. nur die Gothic.dat) dekompilieren. Danach kannst du die Scripte natürlich mit Gothic wieder kompilieren

[Marcello]

Man kann damit kompilierte .dat-Dateien (evtl. nur die Gothic.dat) dekompilieren. Danach kannst du die Scripte natürlich mit Gothic wieder kompilieren

habs mal eben ausprobiert- funktioniert wunderbar. danke dir für die erklärung

[Bisasam]

Blöde Frage: Wie bringt man das Ding in Gang?

In der DecDat1.0a.zip finde ich ein paar txt-dokumente und eine .jar mit der ich nichts anfangen kann.

[Milky-Way]

Hast du Java installiert? Dann solltest du die .jar ausführen können.

[Bisasam]

Kein Java. Hab grad nach gegoogelt aber der lädt mir das immer nur als Browser-Plugin. Nehme an das ist falsch, denn das bringt rein gar nichts was die datei angeht.

[Umfi]

Kein Java. Hab grad nach gegoogelt aber der lädt mir das immer nur als Browser-Plugin. Nehme an das ist falsch, denn das bringt rein gar nichts was die datei angeht.

DIE JRE sollte reichen:
http://www.oracle.com/technetwork/ja...s-2133155.html

Sollte es mit Java 8 nicht laufen, hier die 7er:
http://www.oracle.com/technetwork/ja...ad-432155.html

[Bisasam]

Ah gut, jetzt hab ich das Ding endlich aufgekriegt.
Leider exportiert das Programm (zumindest soweit ich das gesehen habe) nicht so sauber wie der Gothic-Sourcer das könnte wenn er nicht bei Ikarus den Löffel abgeben würde.
Mir wird fast alles in eine Content.d geklatscht. Wenn ich damit versuche ein Backup aufzuspielen...

Oder habe ich die Auswahl nur übersehen, mit der man die dat sauber in ihre Ursprungsdaten zerlegen kann?

[Lehona]

Nein, aber du darfst dir nächstes Mal ruhig die Hilfedateien anschauen (zugegeben, die jeweiligen Menüpunkte haben aus irgendeinem Grund die entsprechende Datei nicht gefunden)

Exportdefinition ist hier der Stichpunkt - wenn du wirklich die komplette Ordnerstruktur rekonstruieren willst, ist das eine Menge arbeitet. Aber meistens reicht es ja, in der einen Content.d entsprechende Dinge nachzuschauen.

[Herobrine]

DecDat hat Fehler bei Conditional Statements: Wenn man mehrere Bedingungen an einem if Statement setzt, die aus "Und" und "Oder" Verknüpfungen bestehen, dann gibt es ein Problem bei der Klammersetzung. Wenn man "Oder" Verknüpfungen miteinander verbinden möchte, dass sie anschließend als "Und" Verknüpfungen weiterverwendet werden können, dann lässt DecDat die Klammern um die verbundenen "Oder" Verknüpfungen einfach weg.

So sollte es aussehen:

if (((condition_1) || (condition_2)) && (condition_3)) { };

So sieht es aus:

if ((condition_1) || (condition_2) && (condition_3)) { };

[Milky-Way]

Bist du dir sicher, dass Gothic das nicht beides gleich interpretiert, weil von links nach rechts ausgewertet wird?

Sprich, weil keine Klammern vorhanden sind, zuerst
(condition_1) || (condition_2)
und dann
<Ergebnis> && (condition_3)

Du kannst meine Vermutung ja mal im Spiel ueberpruefen und ausserdem anschauen, was aus
if ((condition_3) && ((condition_1) || (condition_2))) { };
wird. Hier waere die Reihenfolge ja wichtig, und ich vermute, dass die Klammern korrekt gesetzt werden.

[Lehona]

Der &&-Operator bindet stärker als der ||-Operator, also im Prinzip das, was Milky sagt (auch wenn es nichts mit "von Links nach Rechts" zu tun hat).

if (a && b || c) ist äquivalent zu if ((a && b) || c).

Edit: Ich bin anscheinend ein Idiot, der Posts nicht richtig lesen kann Wenn DecDat sich tatsächlich so verhält, ist das ein Bug.

[benjaminfoo]

Gute Arbeit, freut mich zu sehen, dass es immer noch verrückte Devs gibt !

P.S. - Kannst du deinen Code auf Github oder ähnlich hochladen?

[Lehona]

An DecDat wird meines Wissens eh nicht weiter gearbeitet, warum genau brauchst du den Code auf GitHub? Wenn du hier eine verbesserte Version hochladen willst, kannst du das gerne tun Notfalls kann ich das nächste Woche auch gerne bei GitHub hochladen

[daharn]

Kann die Sache mit den conditions mittlerweile jemand bestätigen?
Hat es jemand geschafft, damit eine Gothic.dat zu laden und dann zu exportieren?

[werauchimmer]

Kann die Sache mit den conditions mittlerweile jemand bestätigen?

Ja, verschachtelte Conditions werden verkehrt aufgelöst.

PS: Der Fehler gilt übrigens auch für Rechenoperationen, d.h. aus (a + b) * c wird a + b * c.
Es werden also die Prioritäten der Operatoren allgemein falsch rum ausgewertet.

[N1kX]

I understand correctly, since decdat indicates an error
unhandled exception occured: java.lang.ArrayIndexOutOfBoundsException: -1


it turns out that gothic.dat compiled with errors? I met this in a recent update of Odyssee 2.6.4, an error pops up in the function b_addon_piratesgohome (64070 ID)
in version 2.6.3 this is not.