Reverse Engineering der NLT

[tommy]

ich wollte mir mit dem Tool "NLTPack" mal die Archive entpacken lassen, doch leider sprigt er mir in folgender zeile raus:
cerror << "Matching FN file (" <<fn_name<<") could not be opened.\n";

ich habe nochmal nachgeschaut, und ich besitzer für keinen der Teile ".fn" dateien. Mache ich irgendwas falsch?

[Hendrik]

ich wollte mir mit dem Tool "NLTPack" mal die Archive entpacken lassen, doch leider sprigt er mir in folgender zeile raus:
cerror << "Matching FN file (" <<fn_name<<") could not be opened.\n";

ich habe nochmal nachgeschaut, und ich besitzer für keinen der Teile ".fn" dateien. Mache ich irgendwas falsch?

Joa, das ist in der Tat etwas kompliziert.
[spoiler=Technische Erklärung]
Die Archivformate der NLT sind für alle 3 Teile recht unterschiedlich, und Teil 2 benötigt zusätzlich zu den .DAT Dateien ohnehin eine .FN (die müssen auch vorhanden sein).
Dadurch kann man z.B. auch Einträge im Archiv haben, ohne die dazugehörige Datei tatsächlich dort zu speichern. DSA2 hat das für die Aufteilung der Daten auf CD und Festplatte benutzt.
Ich habe mich damals entschieden, diesen Mechanismus verallgemeinert auch für DSA1- und DSA3-Archive zu verwenden.
[/spoiler]

Für Sternenschweif müssen solche .FN-Dateien im gleichen Verzeichnis wie die .DAT-Archivdateien vorhanden sein.
Um ein Archiv zu packen (nicht jedoch beim Entpacken), muss in jedem Fall eine passende .FN-Datei vorhanden sein. Eine solche Datei kann man mittels

Code:

./nltpack m /pfad/zum/archiv.dat

genenieren. Es wird dann eine Datei /pfad/zum/archiv.fn erzeugt, die nltpack beim Packen verwenden kann.

[Borbaradwurm]

Die Screenshots machen mich jetzt aber neugierig. Hast du eine vorgegebene Engine mit Bildern und Karten aus der NLT gefüttert, oder ist das eine Eigenentwicklung?

Abgesehen von SDL, OpenGL und PPlib ist es bisher eine Eigenentwicklung.

Sehr interessant! Sieht für mich nach Schweif mit Texturen aus der Schicksalsklinge aus?! Mehr davon!

Nee, es ist Die Schicksalsklinge mit Platzhaltertexturen für Raumdecken und -boden, mit der GUI-Maske aus Schatten über Riva im zweiten Screenshot.

Das ist kein alzugroßes Problem, diese Sprites sollten sich mit recht geringen aufwand rekonstruieren lassen. Wenn es einmal soweit ist biete ich auch gerne meine Hilfe dazu an.

Doch es ist ein nicht überwindbares Problem da Perspektive und Licht in den Sprites schon drin ist. Die nötigen Pixelinformationen sind nicht in den Spieldaten vorhanden. Die Schicksalsklinge hat keinen 3D Renderer, daher spreche ich Pseudo-3D: Im Sichtfenster wird je nach Partyposition der 2D Karte die Sicht zusammengesetzt. Der Großteil dieser Sprites sind, wenn man so will, Puzzelteile eines 3D Screenshots und keine Texturen im Sinne eines 3D Renderers.

[tommy]

Das ist kein alzugroßes Problem, diese Sprites sollten sich mit recht geringen aufwand rekonstruieren lassen. Wenn es einmal soweit ist biete ich auch gerne meine Hilfe dazu an.

Doch es ist ein nicht überwindbares Problem da Perspektive und Licht in den Sprites schon drin ist. Die nötigen Pixelinformationen sind nicht in den Spieldaten vorhanden. Die Schicksalsklinge hat keinen 3D Renderer, daher spreche ich Pseudo-3D: Im Sichtfenster wird je nach Partyposition der 2D Karte die Sicht zusammengesetzt. Der Großteil dieser Sprites sind, wenn man so will, Puzzelteile eines 3D Screenshots und keine Texturen im Sinne eines 3D Renderers.

das ist mir schon klar , ich meinte nur mit ein bischen Übung in Grafikbearbeitung ist es nich alzu schwer wieder eine vollständige Textur aus den einzelnen Texturen zu malen(also ich meine schon eine neue Textur zu erstellen, die der alten aber möglichst ähnlich sieht). Und die anzahl der benötigten Texturen dürfte auch recht überschaubar sein.


@Hendrik
das werde ich nachher gleich nochmal versuchen^^

[tommy]

Für Sternenschweif müssen solche .FN-Dateien im gleichen Verzeichnis wie die .DAT-Archivdateien vorhanden sein.
Um ein Archiv zu packen (nicht jedoch beim Entpacken), muss in jedem Fall eine passende .FN-Datei vorhanden sein. Eine solche Datei kann man mittels

Code:

./nltpack m /pfad/zum/archiv.dat

genenieren. Es wird dann eine Datei /pfad/zum/archiv.fn erzeugt, die nltpack beim Packen verwenden kann.

danke hat echt super geklappt vielleicht solltest du aber trotzdem mal ne kurze Anleitung mit hochladen(also da wo der source code ist)

[HenneNWH]

Grad noch ein Bug gefunden: Wenn ich in einem Dungeon auf eine Falle latsche und diese mich verletzt bekomme ich zwar die LE abgezogen, aber der Lebensbalken wird nicht angepasst. Wechsle ich anschließend in den Charakterbogen und zurück, stimmt er wieder.

Danke. Das war einer meiner Bugs. Ist gefixt.

Allerdings habe ich in der Stadt ein paar Zaubersprüche probiert und dort wird der AE-Balken auch nicht aktualisiert.
Dieser Fehler tritt auch mit einer ungepatchten Version auf und ist somit ein Fehler von Schick.

Das habe ich auch gleich noch erledigt und ins Repo gepusht.

[Obi-Wahn]

Achtung, heiß und fettig!

[Hendrik]

vielleicht solltest du aber trotzdem mal ne kurze Anleitung mit hochladen(also da wo der source code ist)

Das habe ich gerade getan.

[Obi-Wahn]

Mal eine Hyper-hypothetische Frage:

Wäre es möglich Schick oder sogar Bright-Eyes mithilfe der NaClBox innerhalb von Chrome zu spielen? (Abgesehen von den fehlenden NLT-Rechten, um das für alle frei zugänglich zu machen )

[Rabenaas]

Nach dem, was ich bislang über NaClBox gehört habe, ist das möglich. Noch interessanter finde ich aber die Möglichkeit, BrightEyes via Emscripten nach JavaScript zu kompilieren. Spätestens, wenn auf den DosBox-Unterbau verzichtet werden kann, sollte das auch performant genug laufen.

[Obi-Wahn]

JavaScript ist ja noch besser.

P.S.: Info über Emscripten.

[Rabenaas]

Die Forumssoftware hat den Link zensiert.

[tommy]

@Hendrik

ich habe mal bezüglich deines tools "NLTPack" ein paar kompiler Warnungen die bei mir kommen, wird zwar in der Regel nichts großes sein, aber kannst du ja mal bei gelegenheit durschauen und sauber casten(ein paar sachen musste ich bereits erzetzen um das Programm überhaupt zum laufen zu ekommen)

Spoiler

warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \dsa2.cpp 22 1
warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \dsa3.cpp 253 1
warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \dsa3.cpp 275 1

warning C4244: 'Argument': Konvertierung von 'u32' in 'u16', möglicher Datenverlust \dsa1.cpp 303 1
warning C4244: '=': Konvertierung von 'u32' in 'u16', möglicher Datenverlust \dsa2.cpp 108 1
warning C4244: 'Argument': Konvertierung von 'u32' in 'const u16', möglicher Datenverlust \dsa3.cpp 65 1
warning C4244: '=': Konvertierung von 'u32' in 'u8', möglicher Datenverlust \dsa3.cpp 161 1
warning C4244: 'Initialisierung': Konvertierung von 'std::streamoff' in 'u32', möglicher Datenverlust \fileutils.cpp 129 1

@Henne_NWH

auch dein Tool habe ich getestet. Du hast einige gravierende Fehler in dein Programm eingebaut, die Wahrscheinlich entstanden sind , als du den DSA1 support eingebaut hast.
So hast du z.B. in der Datei "loader_NVF.c" die lokale Variable "size_t calc_len" in mehreren Funktionen nicht gleich definiert, dann eine if abfrage, in der du die Varible aber nur in einem Zweig definierst und hinterher eine Abfrage auf diese machst. Diese Fehler ziehen sich durch die ganze Datei und vermutlich ach noch durch die anderen. Du solltest generall darauf achten, dass du alle Variblen die du deklarierst auch sofort mit sinvollen Werten definierst und später nicht gesetzte Werte abfängst.

Dann ist mir noch bei DSA1 aufgefallen, dass du manchmal scheinbar das Dateiformat nicht sauber schreibst, ich habe einige Dateien, die mein "Paint Net" nicht öffnen kann, die aber durch ein anderes Konvertierungsprogramm korrekt konvertiert werden.

Und zu guter letzt habe ich auch noch ein paar Kompillerwarnungen für dich.

Spoiler

warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \dump_tga.c 22 1
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \loader_nvf.c 180 1
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \loader_nvf.c 226 1
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \loader_nvf.c 335 1
warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \loader_nvf.c 449 1
warning C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. \nvf2tga.c 35 1

warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \dump_tga.c 60 1
warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \dump_tga.c 65 1
warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \loader_nvf.c 195 1
warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \loader_nvf.c 247 1
warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \loader_nvf.c 362 1
warning C4018: '<': Konflikt zwischen 'signed' und 'unsigned' \pp20.c 44 1
warning C4018: '<=': Konflikt zwischen 'signed' und 'unsigned' \pp20.c 94 1
warning C4244: '=': Konvertierung von 'unsigned long' in 'char', möglicher Datenverlust \pp20.c 95 1
warning C4018: '<=': Konflikt zwischen 'signed' und 'unsigned' \pp20.c 119 1

P.S. ih würde mich sehr freuen wenn du das Tool bei gelegenheit noch vollenden könntest, so das Wirklich alle Dateien aus DSA1 ausgelesen werden können


und dann noch mal ne generelle Frage, kann man das nicht abstellen, dass brighteyes die Passwortabfrage aktiviert?

[ConjurerDragon]

...
und dann noch mal ne generelle Frage, kann man das nicht abstellen, dass brighteyes die Passwortabfrage aktiviert?

War nicht genau der Gedanke es der dazu führte das Jowood die Passwortabfrage weggelassen hatte und damit die Wahlmöglichkeit zwischen Anfänger- und Expertenmodus auch ausgeschaltet hatte?

Die Passwortabfrage sollte aber kein Problem sein - bei der Heldenedition sind die Passwörter ja dabei und bei drei Versuchen weiss man doch spätestens die dritte Frage auswendig.

[Arbosh]

Bei mir ist bei BrightEyes die Passwortabfrage inaktiv und ich werde gefragt ob ich Anfänger oder Fortgeschrittenen-Modus möchte..

[tommy]

Bei mir ist bei BrightEyes die Passwortabfrage inaktiv und ich werde gefragt ob ich Anfänger oder Fortgeschrittenen-Modus möchte..

ja so war es bei mir bisher auch

[HenneNWH]

@Henne_NWH

auch dein Tool habe ich getestet. Du hast einige gravierende Fehler in dein Programm eingebaut, die Wahrscheinlich entstanden sind , als du den DSA1 support eingebaut hast.
So hast du z.B. in der Datei "loader_NVF.c" die lokale Variable "size_t calc_len" in mehreren Funktionen nicht gleich definiert, dann eine if abfrage, in der du die Varible aber nur in einem Zweig definierst und hinterher eine Abfrage auf diese machst. Diese Fehler ziehen sich durch die ganze Datei und vermutlich ach noch durch die anderen. Du solltest generall darauf achten, dass du alle Variblen die du deklarierst auch sofort mit sinvollen Werten definierst und später nicht gesetzte Werte abfängst.

Hm, Du hast völlig recht. Bei Schick ist das mit den Dateiformaten etwas komplizierter und ich habe wohl den Überblick verloren.

Beim schreiben dieses Tools habe ich auch weder an Portabilität gedacht, noch an automatisches Testen. Ich werd das Programm nochmal überdenken und den Bug fixen, bzw. das Programm klarer strukturieren.

Btw, welchen MSVC Kompiler nutzt Du überhaupt?

Dann ist mir noch bei DSA1 aufgefallen, dass du manchmal scheinbar das Dateiformat nicht sauber schreibst, ich habe einige Dateien, die mein "Paint Net" nicht öffnen kann, die aber durch ein anderes Konvertierungsprogramm korrekt konvertiert werden.

Tritt der Fehler immer bei den gleichen Bildern? Wenn ja, sag mir mal bei welchen.
Bei dump2tga.c habe ich mich an TGA V1.0 gehalten. Da auch noch TGA V2.0 existiert kann es sein, dass mache Programme mit V1.0 nicht klarkommen. Jetzt werde ich das Schreiben des Headers etwas überarbeiten.
Vielleicht löst das dein ja dein Problem. Falls nicht baue ich V2.0 ein.

...
und dann noch mal ne generelle Frage, kann man das nicht abstellen, dass brighteyes die Passwortabfrage aktiviert?

War nicht genau der Gedanke es der dazu führte das Jowood die Passwortabfrage weggelassen hatte und damit die Wahlmöglichkeit zwischen Anfänger- und Expertenmodus auch ausgeschaltet hatte?

Jowood hat sich mit dem Maschinencode vertan. Bei Bright-Eyes wird es richtig gemacht.

Im Moment wird die Passwortabfrage nur deshalb übersprungen damit ich schneller testen kann.
Wenn sich 5 aktive Tester melden, die die Passwortabfrage jetzt schon freigeschalten haben möchten, werde ich das natürlich tun.

[Arbosh]

So mal wieder was neues: BrightEyes ist bei mir heut zum zweiten mal mit 'nem Segfault abgestürzt. Beim ersten Mal hatte mir die Shell noch keinen Coredump gemacht, aber diesmal war ich vorbereitet, hier ist's passiert:

Code:

Program terminated with signal 11, Segmentation fault.
#0  0x08207f8a in host_readd (nvf=0xb5623f28 "\003") at ../../../../include/mem.h:94
94        return *(Bit32u *)off;
(gdb) p *off
Cannot access memory at address 0x0
(gdb) bt
#0  0x08207f8a in host_readd (nvf=0xb5623f28 "\003") at ../../../../include/mem.h:94
#1  M302de::process_nvf (nvf=0xb5623f28 "\003") at seg002.cpp:226
#2  0x081fce2b in seg002 (offs=<value optimized out>) at schick_m302de.cpp:890
#3  0x08058d75 in CPU_CALL (use32=false, selector=1728, offset=3794, oldeip=5726) at cpu.cpp:1072
#4  0x0806b94b in CPU_Core_Normal_Run () at core_normal/prefix_none.h:564
#5  0x0804df2f in Normal_Loop () at dosbox.cpp:133
#6  0x0804de5e in DOSBOX_RunMachine () at dosbox.cpp:245
#7  0x08055756 in CALLBACK_RunRealInt (intnum=16 '\020') at callback.cpp:106
#8  0x081ede67 in DOS_Shell::Execute (this=0xacdf368, name=0xbff73190 "schickm", args=0xbff7425b "") at shell_misc.cpp:492
#9  0x081eaf13 in DOS_Shell::DoCommand (this=0xacdf368, line=0xbff74254 "schickm") at shell_cmds.cpp:153
#10 0x081e573c in DOS_Shell::ParseLine (this=0xacdf368, line=0xbff74254 "schickm") at shell.cpp:251
#11 0x081e6f05 in DOS_Shell::Run (this=0xacdf368) at shell.cpp:329
#12 0x081e674c in SHELL_Init () at shell.cpp:653
#13 0x081205f8 in main (argc=1, argv=0xbff75524) at sdlmain.cpp:1868

Leider läßt sich das ganze nicht zuverlässig reproduzieren. Ich habe den Coredump aber erstmal gesichert falls noch mehr Infos nötig sind (z.B. Variableninhalte aus höheren Stackframes).

[Obi-Wahn]

Kannst du vielleicht irgendeinen Hinweis darauf geben, wo oder wie dir das passiert ist? Dann könnte ich das unter Umständen mal austesten und gucken, ob ich auch nen Absturz bekomme.

[Arbosh]

Das erste mal ist es mir auf Ljahlsdal im Tempel des Namenlosen passiert (bin mir nicht mehr sicher ob im Kampf oder nicht), das zweite mal während eines Kampfes in Daspota. Ich werde heute abend selbst auch nochmal probieren das zu reproduzieren, da es nicht weit vom letzten Spielstand entfernt war. Interessant wäre vermutlich wie man provozieren kann, dass in off eine 0 steht, vielleicht wäre das ein guter Startpunkt.