Reverse Engineering der NLT

[Cerbsen]

Anmerkungen zur ITEMS.DAT

Byte 3 hatte Wertedreher (fett)

Blocklänge: 12 Byte
Byte Funktion
1 Icon (low Byte)
2 Icon (high Byte)
3 Itemtyp
4 Anziehbar an Position / Waffengattung
5 Unterschiedlich (siehe unten)
6 Gewicht (Unzen)
7 Gewicht (Unzen)
8 Preis (Grundeinheit) (0x01 = Heller, 0x0A = Silber, 0x64 = Dukaten)
9 Preis (low Byte)
10 Preis (High Byte)
11 Sortiments-ID
12 Magisch (0x01 = magisch, 0x00 = normal)

Byte 3 (Itemtyp):
Bit Itemtyp
1 Kleidung, Rüstung, Schild
2 Waffe/Munition
3 Benutzbar
4 Essbar/Trinkbar
5 Stapelbar (zB mehrere Proviantpakete in einem Inv.Slot)
6 Trank/Gift/Kraut
7 Held gibt Gegenstand nicht mehr aus der Hand (vgl. Zauberstab)
8 Gegenstand läßt sich per 'use Object' nicht benutzen

Byte 4 (Position):
Falls Bit 1 in Byte 3 gesetzt ist (Item = Kleidung od. Rüstung):
Für Kleidung und Rüstung def. dieses Byte, an welchen Stellen sie angelegt werden können:
Wert Position
00 Kopf
01 Arme
02 Brust
05 Beine
06 Schuhe
09 Schildhand

Falls Bit 2 in Byte 3 gesetzt ist (Item = Waffe):
Für Waffen def. dieses Byte, welcher Waffengattung sie angehören:
Wert Position
00 Munition (Pfeile, Bolzen) [Waffenlos zählt nicht als Waffe]
01 Hiebwaffe
02 Stichwaffe
03 Schwerter
04 Äxte
05 Speere
06 Zweihänder
07 Schusswaffe (Bogen, ..)
08 Wurfwaffe (Wurfstern, Wurfdolch, ..)

Falls "BIT 3" und "BIT 6" in "BYTE 3" gesetzt:
Legt Verhalten von Gift/Tränken/Kräutern fest wenn versucht wird sie zu essen.
Wert Effekt
-normal
00 Gift: nicht verbraucht; normaler Effekt; Textbox(Ich bin doch nicht verrückt)
00 Kraut: verbraucht; normaler Effekt; Textbox(Kraut hat xy Lebenspunkte, etc)
01 Trank: verbraucht; normaler Effekt; Textbox(Trank hat xy Lebenspunkte, etc)
-vertauscht
01 Gift: verbraucht; kein Effekt: Textbox("Giftname")
00 Trank: verbraucht; kein Effekt: keine Textbox
01 Kraut: verbraucht; kein Efftekt; Textbox("Krautname")

Falls "BIT 4" in "BYTE 3" gesetzt:
Unterscheidung Nahrung/Getränk, Byte 5 regelt Effektwirkung
Wert Bedeutung
00 Getränk, Item wird bei Benutzung verbraucht, hinterlässt leere Flasche, Textbox("Durst gestillt")
01 Nahrung, Item wird bei Benutzung verbraucht, Textbox("Hunger gestillt")

BYTE 5:
Falls Bit 1 in Byte 3 gesetzt ist (Item = Kleidung od. Rüstung):
Position im Wertearray in SCHICKM.EXE
v3.02... Offset 0x017C37 bis 0x17C66
je 2 BYTE pro Items
[Rüstungswert][Behinderung]

Falls Bit 2 in Byte 3 gesetzt ist (Item = Waffe):
Position im Wertearray in SCHICKM.EXE
v3.02... Offset 0x017A70 bis 0x17C2F
je 7 BYTE pro Items
[Würfelanzahl][+Bonus][KK-Bonus][Bruchfaktor][?Schusswaffen?][AT-Bonus/Malus][PA-Bonus[Malus]

Falls "BIT 3" in "BYTE 3" gesetzt:
Wert Bedeutung:
01 Itembenutzung: Heldenauswahlmenu, Arcano +2 MR (stackbar), 5 Anwendungen
02 Trankrezepte vmtl. per Itemid an SCHICKM.EXE gebunden, da nur leere Textbox bei anderen Items
03 Schriftstücke vmtl. per Itemid an SCHICKM.EXE gebunden, da nur leere Textbox bei anderen Items
04 Itembenutzung: Heldenauswahlmenu, Armatrutz(Stärke x) x bestimmt Benutzerklasse, 3 Anwendungen
05 Itembenutzung: Flim Flam, 6 Anwendungen
06 Itembenutzung: Textbox ("Inhalt des Schuldscheins")
07 Itembenutzung: Textbox ("Inhalt der Orkdokumente")
08 Gifte EXPURGICUM..VOMICUM.. vmtl. per Itemid an SCHICKM.EXE gebunden
....da benutzt auf andere Items Itemerzeuger erschaffen werden (Lakritze: Benutzung erschafft Wurfaxt
..., Bonbons erschaffen Zweihänder, Schnaps erschafft Wurfstern, je ein Item pro Benutzung im Inventar)
09 Itembenutzung: MIASTHMATICUM.. (nur im Kampf)
0A Itembenutzung: HYLAILER FEUER.. (nur im Kampf)
0B Itembenutzung: Textbox("Aus dem Buch scheinen magische Ströme zu fliessen...")
0C Itembenutzung: Löst Fackelanzündenaktion aus (Fackeln/Laternen/Zunder benötigt)
0D Itembenutzung: Textbox("Der Staub aus dem Beutel wird davongeweht, obwohl kein Luftzug...")

Falls "BIT 3" und "BIT 6" in "BYTE 3" gesetzt:
Bedeutung unklar, keine Veränderung bei Wertänderung festgestellt
00 bei Tränken
08 bei Giften

Falls "BIT 4" in "BYTE 3" gesetzt:
Menge des gestillten Hungers/Dursts
01 Balken sinkt um einen "Strich"
64 Balken sinkt auf 0 zurück (Hunger/Durst komplett gestillt)

Items.dat, gegliedert nach Typ, sortiert nach Byte 5

Spoiler

[tommy]

@Hendrik:

Ist dir beim Reverse Engeneering von Sternenschweif eigentlich mal irgendwo die Weltkarte oder das Reiserouten system untergekommen?

[Hendrik]

@Hendrik:

Ist dir beim Reverse Engeneering von Sternenschweif eigentlich mal irgendwo die Weltkarte oder das Reiserouten system untergekommen?

Nein, diese Ecke von Sternenschweif kenne ich noch nicht. Momentan grüble ich über diesen verflixten 3D-Dateien. Ich kann mittlerweile einzelne "Zeltstangen" der Marktplatz-Zelte bewegen (klingt besser, als es ist), aber so ganz blicke ich da noch nicht durch.

[tommy]

immerhin, du musst du ja wenigstens schon einen Teil entschlüsselt haben

[Borbaradwurm]

@Hendrik:

Ist dir beim Reverse Engeneering von Sternenschweif eigentlich mal irgendwo die Weltkarte oder das Reiserouten system untergekommen?

Also die Weltkarten-Textur der Überlandreisen heisst ORKLAND.AIF und ist in STAR.DAT zu finden. Die Reiserouten vermute ich in der Datei ROUTES.DAT (auch aus STAR.DAT).

[tommy]

Also die Weltkarten-Textur der Überlandreisen heisst ORKLAND.AIF und ist in STAR.DAT zu finden. Die Reiserouten vermute ich in der Datei ROUTES.DAT (auch aus STAR.DAT).

Ahh danke dann weiss ich jetzt wenigstens was ich als nächstes bei meinem Tool in Angriff nehmen kann sobald ich wieder etwas Zeit habe

[Borbaradwurm]

DDT-Header (4 Byte)
2 Byte Integer (unsigned) = realtives Offset der Türen-Liste
2 Byte Integer (unsigned) = realtives Offset der Treppen-Liste

DNG-Ebene (320 Byte)
256 Byte Feld [16*16 Byte] des Ebenen-Status look-up-table der pseudo-3D Ansicht

Linkes Nybble:
[Wert = Was? (verwendete Sprite-Indexe der Dungeonskin-Texturen (SHIPSL.NVF, STONESL.NVF und MARBLE.NVF)/begehbar?/Farbe im Automap (HTML-Notation)]
0x0 = Gang (-/ja/#282828)
0x1 = geschlossene Tür (22-36/nein/#821400)
0x2 = geöffnete Tür (22-36, 54/ja/#821400)
0x3 = Treppe/Leiter runter (48-50/ja/#0000FF)
0x4 = Treppe/Leiter rauf (45-47/ja/#00FFFF)
0x5 = ausgelöste Fallgrube in der Raumdecke (41-44/ja/#00FF00)
0x6 = ausgelöste Fallgrube im Fußboden (37-40/ja/#3C7D3C)
0x7 = Blocker-Sprite (51-53/nein/#FF0000)
0x8 = Schatztruhe (55-57/nein/#9E4D00)
0x9 = eingeschlagene Tür (22-36, 54/ja/#821400)
0xA = noch nicht geöffnete/gefundene Geheimtür (3-21/nein/#FF0000)
0xB = Illusionswand (3-21/ja/#FF0000)
0xC = Gang, als Wand im Automap, verwendet in F051.DNG ("Spinnenhöhle") (-/ja/#FF0000)
0xD = Gang, als Wand im Automap, nicht verwendet? (-/ja/#FF0000)
0xE = Gang, als Wand im Automap, nicht verwendet? (-/ja/#FF0000)
0xF = Wand (3-21/nein/#FF0000)

Rechtes Nybble: Funktion unbekannt

64 Byte Feld [32*16 Bit] true = Automap aufgedeckt, false: Automap nicht aufgedeckt = false.
Achtung: jede Zeile dieses Feld ist 32 Bit breit obwohl das Ebenenlayout selbst nur 16 Byte breit ist, es werden also nur die ersten zwei Byte benutzt. Dies ist bei den DAT-Dateien der Städte genauso, wobei nur bei den "großen Städte" (PHEXCAER.DAT, PREM.DAT und THORWAL.DAT) das gesamte Feld benutzt wird.




Im übrigen gibt es wohl eine Logik nach welcher bestimmte Dateien in die Savegame-Dateien (die Dateien aus dem TEMP-Verzeichnis DAT/DNG/NPC usw.) kopiert werden. Wenn diese Logik entschlüsselt ist wäre es möglich z.B. in einem Savegameeditor das Automap einer Stadt oder Dungeons aufzudecken.

[tommy]

da war ja jemand fleißig, ich hoffe doch du bleibst da dran und schaust dir noch ein paar andere Dateien an

[Borbaradwurm]

Container-Datei-Struktur der Spielstandsdateien (.GAM)

Nach meinen bisherigen Beobachtungen stellt es sich so dar: Die Spielstandsdatei teilt sich in drei Abschnitte.

1. Statische Daten: Versionsheader, Spielstand usw.: Größe versionsabhängig (z. B. 6908 Byte bei v1.06, 7116 Byte bei v3.02)
2. Variabele Daten #1: modifizierte Dateikopien aus SCHICK.DAT ((DAT (Städte)/DNG/NPC/usw.)
3. Variabele Daten #2: Charakere (die CHR-Dateien die im Spielverzeichnis beim Spielstart waren)

Wichtig für die Container Struktur:
1. Offsets 16-19 (direkt nach dem Versionsheader): 4 Byte Integer (unsigned) Offset von Abschnitt 3: Variabele Daten #2; Anzahl Charaktere = (Spielstandsdateigröße - Offset-Variable-Daten-#2) / 1754 (CHR-Dateigröße)
2. Die letzten 1144 Byte der statischen Daten sind ein Feld von 286 Variablen je 4 Byte Integer (unsigned) und beschreiben die jeweiligen Dateigrößen von Variable Daten #1. Wobei Dateinamenliste aus SCHICKM.EXE für die SCHICK.DAT als Index fungiert: ist eine der 286 Variablen des Dateigrößenfelds größer 0 dann ist die Datei die and diesem Index in SCHICKM.EXE steht in den Variablen Daten #1 der Spielstandsdatei enthalten. Und zwar in der Reihenfolge aus der SCHICKM.EXE-Dateinamensliste. Das Hinzufügen von Dateien die ich nicht in den gesehen habe (z.B. LTX, NVF) habe ich nicht getestet, auslesen und hinzufügen von Dateien funktioniert soweit ich es mit den mir vorliegenen Savegames testen konnte. Aufgefallen ist mir das in meinen Spielständen ausschließlich die DAT (Städte), NPC, FIGHT.LST, und DNG Dateien im Savegame gespeichert werden.

[Borbaradwurm]

Container-Datei-Struktur der Spielstandsdateien (.GAM) Teil 2

Okay, da mein vorheriger Beitrag nur die Container-Struktur von Die Schicksalsklinge behandelte gibt es heute von mir dasselbe für Sternenschweif und Schatten über Riva.

Nach dem Versionsheader (16 Byte) ist die Strukutr der .GAM Dateien von Sternenschweif und Schatten über Riva Chunk basiert.

Ein Chunk besteht aus:
1. Chunk-Header (4, 6 oder 10 Byte):
4 Byte Chunk-ID
2 Byte Größe Chunk-Daten (Achtung: bei Chunk-ID = "DESC" ist keine Größe im Header enthalten, bei "DESC"-Chunks sind die Chunk-Daten immer 256 Byte groß.)
4 Byte Größe Chunk-Daten (Achtung: nur enthalten wenn die 2 Byte Chunk-Größe = 0xFFFF (65535) bei Daten deren Größe sich nicht in 2 Byte Integern abbilden lässt.)
2. Chunk-Daten

"TEMP"-Chunks
Die "TEMP"-Chunks sind die Spieldateien die sich während des Spielens von Sternenschweif und Schatten über Riva im TEMP-Unterverzeichnis zu finden sind. Diese Chunks haben folgende Struktur:
15 Byte Dateiname (C-String: 1-14 Zeichen und terminierendes Nullbyte)
danach die Datei (Dateigröße = Chunk-Größe - 15 Byte), wobei diese Dateien in Schatten über Riva komprimiert werden ("RIVAPACK").

[Obi-Wahn]

Taucht der Bug mit der Magieresistenz eigentlich auch bei BrightEyes auf? Also ist der Bug in BrightEyes behoben, oder nicht? Im Moment wäre ja eine super Gelegenheit eine neue Version von BrightEyes rauszubringen!

[Hendrik]

Hallo,
bin gerade dabei, ein paar Bilder aus Sternenschweif zuzuordnen. Bei folgenden Bildern frage ich mich, wo man sie zu Gesicht bekommt. Falls es eine Rolle spielt, die Bilder stammen aus der englischen Version.

Karte von Lowangen
   

Helden in Gefängniszelle?
   

Zauberbuch
   

[Crystal]

Die Stadtkarte ist diejenige, die man im Lowangener Hesinde-Tempel unter die Nase gehalten bekommt, wenn man den Geweihten nach "Lowangen" fragt.

Das Gefängnis-Bild könnte auch aus Lowangen stammen, wenn man Kerkerhaft wegen zuviel Waffen im Gepäck oder Angriff auf Gardisten im Gardehaus abzusitzen hat. Vielleicht auch das Ergebnis einer Verhaftung aufgrund eines fehlgeschlagenen Einbruchs im Schauhaus der Künste, wo man für Dragan eine Brosche klauen soll.

Das Zauberbuch kenne ich jetzt auch nicht.

[Obi-Wahn]

(Sehr) Gute Nachricht: Henne hat mal wieder ein paar Änderungen ins Bright-Eyes-Repo hochgeladen.

Schlechte Nachricht: Ich bekomme den Windows-Build nicht hin... Der Fehler liegt vielleicht hier:

Code:

1>BSCMAKE: error BK1506 : Datei ".\Release\hardware.sbr" kann nicht geöffnet werden: No such file or directory

Grundlage war ein ganz frischer Download von Github, also kein Update.

[Hendrik]

(Sehr) Gute Nachricht: Henne hat mal wieder ein paar Änderungen ins Bright-Eyes-Repo hochgeladen.

Schlechte Nachricht: Ich bekomme den Windows-Build nicht hin... Der Fehler liegt vielleicht hier:

Code:

1>BSCMAKE: error BK1506 : Datei ".\Release\hardware.sbr" kann nicht geöffnet werden: No such file or directory

Grundlage war ein ganz frischer Download von Github, also kein Update.

Seltsam. Das Problem ist ein Windows/VisualC-Problem, unter Linux klappt der Build anstandslos. Habe mal in die Makefile.am geschaut im Verzeichnis src/hardware, nichts Verdächtiges, wieso er z.B. die cmos.sbr findet und die hardware.sbr nicht.
Wozu braucht der VisualC-Compiler eigentlich die .sbr-Dateien? "Source Browser" klingt jetzt nicht unbedingt nach etwas, das zum Komplieren einer .exe notwendig wäre.

EDIT: Hier mal der Changelog vom Git-Repository für die letzten Änderungen:

(Achtung Coderwelsch)

M302de: add callback for set_audio_track()
M302de: bypass init_ani_busy_loop()
M302de: bypass show_citizen(). Shows the, not so amused, citizen of a house.
M302de: add speed macro. When too much functions are bypassed, some sequences are very quickly gone.
M302de: add more constants
M302de: add callback for handle_gui_input()
M302de: bypass show_storytext()
M302de: activate enter_map()
DOSBox-custom: handle function pointer call instruction. Besides the 5 Byte (0x9a) far call there exists also an instruction which is only 3 Byte (0xff) and reads the adress from memory.
M302de: bypass (not really ) draw_loc_icons()
M302de: bypass has_intro_letter()
M302de: bypass count_map_parts()
M302de: add seg072 infrastructure
M302de: BC: Borlandify seg027.cpp
M302de: BC: Borlandify seg000 and seg006 headers
M302de: BC: borlandify FIG_draw_enemy_pic
M302de: BC: borlandify FIG_get_hero_ptr
M302de: BC: reorder local variables in FIG_draw_figures()
M302de: remove some useless casts
M302de: BC: mark 2 functions as identical and move one
M302de: BC: borlandify seg006 completely. Now it compiles with BCC.
M302de: BC: add struct screen_rect
M302de: BC: borlandify seg006

[Obi-Wahn]

Problem gefunden. War eine Mischung aus Windows und Linux verwöhntem Benutzer.

Tja das Coderwelsch...
Ersetzte Funktionen und Bestandteile:

Unfreundlicher Hausbewohner
Storytext-Anzeige
Anzeige und Zählung der Kartenteile
Borland Kram...

Passt das so ungefähr? Habe jetzt nur das genommen, was ich verstanden habe.

Neue Version verfügbar!

[Hendrik]

Super, Obi! Ja, die Zusammenfassung trifft's ganz gut.
Klasse, dass du den Fehler so schnell beheben konntest.

[Hendrik]

Die Stadtkarte ist diejenige, die man im Lowangener Hesinde-Tempel unter die Nase gehalten bekommt, wenn man den Geweihten nach "Lowangen" fragt.

Das Gefängnis-Bild könnte auch aus Lowangen stammen, wenn man Kerkerhaft wegen zuviel Waffen im Gepäck oder Angriff auf Gardisten im Gardehaus abzusitzen hat. Vielleicht auch das Ergebnis einer Verhaftung aufgrund eines fehlgeschlagenen Einbruchs im Schauhaus der Künste, wo man für Dragan eine Brosche klauen soll.

Das Zauberbuch kenne ich jetzt auch nicht.

Ja, das Gefängnis-Bild bekommt man in Lowangen zu sehen, wenn man sich mit der Garde anlegt. Fehlt nur noch das Zauberbuch. In der USE.LTX, die Texte zu benutzten Gegenständen enthält, gibt es einige Texte zu magischen Büchern (Nr. ist einfach die Zeile in der USE.LTX)
Nr. 23: "Aus dem Buch scheinen magische Ströme zu fliessen."
Nr. 73: "Das Buch ist in einer Euch unbekannten Schrift verfasst, strömt aber eine sehr beklemmende Aura aus."
Kommt das jemandem bekannt vor?

[Crystal]

Nr. 23: "Aus dem Buch scheinen magische Ströme zu fliessen."

Das Heptagon-Buch aus der Spinnenhöhle der Schicksalsklinge. 100 %.

Nr. 73: "Das Buch ist in einer Euch unbekannten Schrift verfasst, strömt aber eine sehr beklemmende Aura aus."

Das müsste eins der schwarzmagischen Bücher aus dem Rivaner Magierturm sein. Vielleicht das "Buch des Zurbaran". Andererseits könnte es auch das Dämonenbuch aus der Rivaner Zwergenbinge sein, wo Manresh den gehörnten Dämonen beschwört.

[Zurgrimm]

Andererseits könnte es auch das Dämonenbuch aus der Rivaner Zwergenbinge sein, wo Manresh den gehörnten Dämonen beschwört.

An das dachte ich auch schon. Da gibt es ja auch eine gerenderte Video-Sequenz zu. Aber soweit ich Hendrik verstanden habe, geht es nur um Szenen aus Sternenschweif. Und da fällt mir beim besten Willen keine Szene ein, wo man in dieser Weise ein Buch zu sehen bekommen könnte. - Sicher, den Text vom magischen Buch aus der Spinnenhöhle, den gibt es auch in Schweif (weil man das ja unbenutzt importieren kann). Aber die Rivaner Bücher kann es dort eigentlich noch nicht geben.

Also, mir scheint dieses Buch-Bild ein Teil des Spiels zu sein, der es nicht ins fertige Spiel geschafft hat.