Reverse Engineering der NLT

[Lippens die Ente]

Ja, ganz sicher bist du nicht der einzige, denn ich will meine ganz eigene NLT erstellen und kann schon sehr viel beeinflussen.

Das nltpack bei Riva versagt, ist aber völlig egal, denn ich habe es jetzt durchschaut und kann nun alles direkt in der RIVA.ALF hexen. denn jede dieser Moduldateien steckt 1:1 in der Riva.alf drin. jetzt brauche ich nur nach einer bestimmten Folge von bytes zu suchen (z. B. den Initialen eines bestimmten Kampfes) und lasse suchen - und voila - der Kampf steht 1:1 wie in der fight.lst drin und ich kann direkt verändern und sogleich in Riva ausprobieren - und nebenbei die Struktur der Kämpfe in Riva erforschen, dort sind die Kämpfe nämlich anders aufgebaut als in Schick oder Schweif und zudem 426 bytes statt 216 lang. Auch die Kampfbeute ist anders eingegeben als in Schweif. Für jeden Gegner sind 15 statt zuvor 5 bytes reserviert. Dabei entsprechen die ersten 5 exakt denen in Schweif, die anderen 10 bieten Platz für 5 Gegenstände, die der jeweilige Gegner nach dem Kampf fallen lässt. Einfach den Hexcode eingeben. So könnten in einem Kampf theoretisch bis zu 100 Items erobert werden, es ist also für jeden Gegner einzeln einstellbar, ich habe es schon ausprobiert. Auf Grund der 15 bytes pro Gegner sind die Kämpfe auch so lang.

Toll, was so alles geht, und gehen wird!! Und nur, weil ein paar unermüdliche Spaß an der Struktur von 20 Jahre alten Dos-Spielen haben (zugegeben sehr gute)

[Alrik Alrikson]

[...]
Auf Grund der 15 bytes pro Gegner sind die Kämpfe auch so lang.
[...]

Damit ist nun aber nicht die (real)zeitliche Kampfdauer gemeint, oder?

[Shihan]

Ich bin gerade dabei, eine C++-Library zu schreiben (bzw. aus nltpack abzuleiten), die sämtliche Formate, die bekannt sind, entpacken und konvertieren kann. Beim BoPa gibt es noch einen kleinen Bug, aber das kommt noch.

@Lippens: Da bin ich anscheinend nicht der einzige der sich auf diese Library freut.

Öhm, Kollegen, bisher war nur ein Entpacken geplant, kein Einpacken

Außerdem hat mich jetzt der Ehrgeiz gepackt und ich will erstmal das 3DM-Format entschlüsseln!

[wiese.hano]

Das einfachste wäre wohl, sich ein Spiel herauszusuchen, dessen Formate komplett dekodiert sind, und daran zu üben.

Danke für den Tipp (und die Links). Vielleicht probiere ich es einmal auf diesem Weg.

[...]
Auf Grund der 15 bytes pro Gegner sind die Kämpfe auch so lang.
[...]

Damit ist nun aber nicht die (real)zeitliche Kampfdauer gemeint, oder?

Nein, keine Sorge! Er meinte die Länge der Bytes (bzw. des Codes). (Cool, dass ich auch mal etwas auf Anhieb verstehe, dass andere nicht sofort raffen. *freu*)

Wenn ich das hier so lese, was in diesem Thread geschrieben wird, beschleicht mich das Gefühl, dass jemand irgendwann in der Lage sein wird, ein völlig neues Spiel aus der Nordlandtrilogie zu machen. *g*

[Shihan]

Danke für den Tipp (und die Links). Vielleicht probiere ich es einmal auf diesem Weg.

Gerne. Bei Fragen zu spezifischen Problemen kannst du mir jederzeit eine PM schicken!

Wenn ich das hier so lese, was in diesem Thread geschrieben wird, beschleicht mich das Gefühl, dass jemand irgendwann in der Lage sein wird, ein völlig neues Spiel aus der Nordlandtrilogie zu machen. *g*

Wer weiß


Davon abgesehen habe ich nun die Vertices aus dem 3DM-File extrahieren können. Die Faces und die Texturzuordnung blicke ich noch nicht ganz, aber die Vertices kann man dekodieren. Ich hab's erst kompliziert probiert, mit Q-Format und ähnlichem Fixed-Point-Zeug. Ist aber komplett Integer-basiert, mit einfachen 32bit signed integers. Lustig!

Habe mir nun die Vertices von einem Marktstand exportiert, die Faces in Blender nachgebaut (Vertices angeklickt und mit Face verbunden) und darauf dann die richtigen Texturen gelegt und voilá:

(Die Rückwand fehlt, sehe ich gerade. Die Texturierung ist auch noch nicht sauber, weil ich die UV-Koordinaten gerade von Hand gesetzt habe. Mehr war da nicht zu machen. Sobald ich die auch aus der 3DM holen kann, wird das natürlich besser )

[Helios]

Sehr schön Shihan
Wenn du hilfe brauchst sag bescheid, hatte mir neulich die 3DMs auch angeschaut. Außerdem liefert die Riva.exe auch viele Anhaltspunkte (z.B. das 3DM nur auf 32Bit CPUs läuft oder aus was die Datei alles besteht)


@Lippens
Ich habe den Datenblock in sehr sehr viele Datenblöcke zerlegen können. Aber mir fehlen einfach Ideen nach was ich suchen soll. Die Itemtabellen sind noch ziemlich leicht zu identifizieren, eine Idee für die Kampffelder habe ich auch, nur die Formate sind extrem anders. Auch scheinen die IDs unterschiedlich, z.B. hat Arkandor 51 aber es gibt in den betreffenden Blöcken keinen passenden Wert.

Ich werde auch mal versuchen die X,Y Positionen der Gebäude und Städte rauszubekommen, außer jemandem sind diese schon bekannt.

[Shihan]

Sehr schön Shihan
Wenn du hilfe brauchst sag bescheid, hatte mir neulich die 3DMs auch angeschaut. Außerdem liefert die Riva.exe auch viele Anhaltspunkte (z.B. das 3DM nur auf 32Bit CPUs läuft oder aus was die Datei alles besteht)

Das mit den 32Bit habe ich jetzt auch raus, weil die Vertex-Positionen in 32bit signed ints gespeichert sind.
Aber was genau meinst du mit "aus was die Datei alles besteht"? Was hast du denn schon aus der Riva.exe herausgeholt und wie genau bist du an der DOS/4GW-Schranke vorbeigekommen? Das würde mich brennend interessieren


Ich habe die Wikiseite zum 3DM überarbeitet. Habe jetzt sämtliche Bestandteile der Datei identifiziert, bis auf einen unbekannten Datenblock. Der wird aber immerhin im Header referenziert, also scheint da ein gewisser Inhalt drin zu stehen.
Die identifizierten Blöcke sind Objekte (geteilt in Header und Daten) und Materialien (mit Texturverweisen). Allerdings sind da noch einige weiße Flecken innerhalb der Blöcke.

Ich würde die Wikiseite auch gerne updaten, allerdings ist das Wiki down. Habe Obi-Wahn bereits angeschrieben. Hoffentlich ist da nichts ernstes passiert!


NACHTRAG:
Das Wiki ist wieder online und die 3DM-Seite umfangreich erweitert. Schaut es euch an und sagt mir, was verbessert werden soll

[llm]

zu DOS/4GW und IDA

seit IDA Pro 6 gibts Support für DOS/4GW LE

und der DOS/4GW kompatible Extender Dos32a hat ein Bind Tool (SUNSYS Bind)
mit dem man den DOS/4GW Extender ersetzen - ODER ganz entfernen kann (dann gehts auch mit IDA)
http://dos32a.narechk.net/index_en.html
http://dos32a.narechk.net/manual/index.html

[Shihan]

Hey Ilm, danke für die Hinweise! Leider habe ich keinen Zugriff auf IDA 6 Pro, weil zu teuer. Die Freeware 5.0 kommt mit DOS/4GW nicht klar. Aber ich schaue mal, vielleicht gibt's da Möglichkeiten über die Uni.


@3DM:
Nachdem ich ein wenig mit den Vertexdaten herumgespielt habe und die Texturzuordnung fast verstanden habe, konnte ich zumindest mal die bisher relativ seltsamen T_, Q_, U_, N_, etc. Materialien verstehen. Diese Objekte sind komplett unsichtbar, bieten aber Funktionalitäten für's Spiel.

Habe die Markthalle mal Stück für Stück (ihr wollt nicht wissen, wie lang das heute gedauert hat) in Blender importiert und einfach mal die besonderen Objekte markiert und mit Kommentaren versehen, wie ich mir was vorstelle:

(Die rote vertikale Linie ganz rechts muss natürlich blau sein)

Insbesondere bei den Läden ist das interessant: Die blockierende Fläche muss wohl sein, weil man sonst durch den Laden durchlaufen könnte.

Ich weiß aber noch nicht, ob die Funktionalität über das Material kommt oder im Objekt kodiert ist und das Material nur für die Entwickler eine Art Hinweis sein sollte.

Damit kommt man wieder etwas weiter.
Es wird so langsam. Ganz langsam

[Silencer]

Mit der Fight.lst habe ich mich vor geraumer Zeit beschäftigt, dass nicht alle Kämpfe enthalten sind, war mir mit dem Viewer klar, der ja alles komfortabel anzeigt. Die Liste sollte ich mal abgleichen, um festzustellen, was davon wirklich im Spiel vorkommt/zuordbar ist. Dabei interessiert mich auch, wie die Zufallskämpfe im Spiel umgesetzt werden (es ist wohl anzunehmen, dass sich das nicht vom ersten Teil unterscheidet). In der Liste ist anscheinend immer die maximale Gegner Anzahl eingetragen. Es gibt ja gerade bei den Rastkämpfen mitunter größere Schwankungen was die Anzahl der Gegner eines bestimmten Kampfes angeht (wäre für die AP Optimierung interessant). Wo findet also dieser Zufallsfaktor Anwendung, wo ist der definiert? Einige der aufgeführten Kämpfe hatte ich auch noch nie mit diesem theoretischen Maximum, da stellt sich natürlich die Frage, wie man diese Kämpfe identifizieren und zuordnen kann und ob es diese Kämpfe überhaupt geben kann, wenn es nicht gerade offensichtlich ist, welcher Kampf gemeint ist. In welcher Datei ist dann die genauere Zuordnung zu finden, also zum Beispiel die Routen, auf denen die Reisekämpfe möglich sind? Darüber müsste es ja dann relativ leicht möglich sein, festzustellen, welche Kampfszenarien tatsächlich im Spiel vorkommen können.

Allgemein kann man wohl folgende Kampftypen unterscheiden:

Zufallskämpfe mit variierender Gegneranzahl (in der Regel Rast oder Reisekämpfe)
Kämpfe an festgelegten Orten mit variierender Gegneranzahl (mitunter auch von speziellen Auslösern abhängig, zum Beispiel im Sumpf)
Kämpfe an festgelegten Orten mit festgelegter Gegneranzahl (Beispiel Orks vor Lowangen oder Elfenveteranen)
Kämpfe an festgelegten Orten und festgelegter Gegneranzahl mit Auslöser (Beispiel diverse Kämpfe im Phextempel und Tempel des Namenlosen)

Insbesondere Kämpfe der letzten Kategorie scheinen in dieser Liste zu fehlen. Wobei ein Kampf dieser Kategorie (in der Zwergenbinge) seltsamerweise enthalten ist. Evtl. findet man die fehlenden Kämpfe, wenn man die Verknüpfung zu deren Auslöser untersucht, sofern man weiß wo diese definiert werden.

[Helios]

Das mit den 32Bit habe ich jetzt auch raus, weil die Vertex-Positionen in 32bit signed ints gespeichert sind.
Aber was genau meinst du mit "aus was die Datei alles besteht"? Was hast du denn schon aus der Riva.exe herausgeholt und wie genau bist du an der DOS/4GW-Schranke vorbeigekommen? Das würde mich brennend interessieren

mit dem man den DOS/4GW Extender ersetzen - ODER ganz entfernen kann (dann gehts auch mit IDA)

Genauso habe ich es gemacht
Kann die Daten auch gerne zur Verfügung stellen, nur als .idb wird es nicht viel Sinn machen. Da eine 5.0 wohl keine 6.1 Version verarbeiten kann.

Insbesondere Kämpfe der letzten Kategorie scheinen in dieser Liste zu fehlen. Wobei ein Kampf dieser Kategorie (in der Zwergenbinge) seltsamerweise enthalten ist. Evtl. findet man die fehlenden Kämpfe, wenn man die Verknüpfung zu deren Auslöser untersucht, sofern man weiß wo diese definiert werden.

Bin mir ziemlich sicher, dass dafür FNEIBOUR.DAT zuständig ist. Also zumindest die Kampfauslöser für Dungeons sind da drin.

[Lippens die Ente]

es fehlen sogar noch ein ganzer Haufen Kämpfe. All diese fehlenden Kämpfe haben eines gemeinsam: sie finden in Dungeons statt und werfen keine Beute ab. Definiert müssen sie aber irgendwo sein. In Schick sind definitiv auch die festen Kämpfe in Dungeons drin. In Riva scheint auch alles da zu sein. Warum haben sie es ausgerechnet in Schweif anders gemacht? klingt unlogisch, aber wenn es jemand herausfindet, dann garantiert einer von uns!

Die fruchtbaren Einträge in der Wiki zu Riva/dat sind dein Werk, Helios, Stimmts? Vielen Dank. Ohne dies wäre ich anhand meines Wissenstandes garantiert nicht dahinter gekommen, dass die Gegenstände in Truhen und Behältern nicht in chest oder spoil, sondern in einer eigenen Datei im selben Modul gespeichert sind, und auch das Format ID-ID-Anzahl, da muss man erst mal drauf kommen, Respekt.

[Helios]

Die fruchtbaren Einträge in der Wiki zu Riva/dat sind dein Werk, Helios, Stimmts? Vielen Dank. Ohne dies wäre ich anhand meines Wissenstandes garantiert nicht dahinter gekommen, dass die Gegenstände in Truhen und Behältern nicht in chest oder spoil, sondern in einer eigenen Datei im selben Modul gespeichert sind, und auch das Format ID-ID-Anzahl, da muss man erst mal drauf kommen, Respekt.

Danke Lippens
Das Format ist sogar noch etwas seltsamer, Anzahl-ID-ID-Anzahl. Wobei die 2. Anzahl bei Kräutern auch etwas niedriger sein kann, wird aber wieder mit der 1. gleichgesetzt wenn man weitere Kräuter hinzu packt. Ich hatte erst die Vermutung es könnte ein Timer oder sowas sein, also wann Kräuter in den trockenen Zustand übergehen. Konnte das aber bisher nicht bestätigen. Vielleicht war es aber mal dazu gedacht, also danach würde zuerst die Anzahl und ID der Items kommen und dann die ID des neuen Items wenn die Zeit abgelaufen ist.
Ansonsten hätte man sich diese Einträge wirklich sparen können. Da sie aktuell anscheinend keine Wirkung haben.

Ich werde nachher noch weiter machen, habe fast alle anderen DATs entschlüsselt und in der RIVA.EXE auch noch einige interessante Dinge gefunden, wie zum Beispiel eine Tabelle mit allen Maps (pro Map 74 Byte).

[Shihan]

[..] und in der RIVA.EXE auch noch einige interessante Dinge gefunden, wie zum Beispiel eine Tabelle mit allen Maps (pro Map 74 Byte).

Ah, das hört sich doch interessant an. Was steckt da an Infos drin?

Wenn du magst, kannst du auch noch Infos zu den anderen Dateiformaten aus der DUNGEON.ALF heraussuchen, also z.B. DSC, NEI, PPD, TAB. Mich würde immer noch interessieren, wo so Dinge wie Türen, Kisten etc. gespeichert sind, d.h. woher Riva bei der 3D-Karte weiß, dass da jetzt eine Kiste ist und was da drin ist.

[Lippens die Ente]

Das klingt ja interessant. Ich glaube aber nicht, dass Kräuter in einen anderen Zustand übergehen können. Es gibt zwar das Trockenwirselkraut mit stärkerer Heilwirkung und zweimal trockene Einbeeren, einmal mit Heil- und einmal mit Schadwirkung. Diese Wirkung ändert sich aber glaube ich nie von selbst, entweder sind sie von Anfang an schlecht oder von Anfang an gut. Die einzige Möglichkeiten, etwas zu verändern, ist der Zauberspruch abvenenum, der die schlechten Einbeeren in normale verwandelt. Das ist aber eine normale Umwandlung während des Spiels und müsste dann nicht bei den Truheninhalten vermerkt werden. Ich kann also keinen Sinn hinter einem solchen Timer erkennen. Wenn man von der Windsbraut zurückkommt, verdirbt zwar ein Großteil der Kräuter, die sind dann aber ganz verschwunden und der Rest ist stinknormal, da braucht man auch keinen Timer. Es scheint also wirklich überflüssig zu sein

noch ein Satz zur Kampfbeute: sind unter den Gegenständen stapelbare dabei, bedeutet ein Eintrag 10 dieser Art: 0A 00 steht zum Beispiel für 10 Pfeile, die ein bestimmter Gegner fallen lässt. In Schick und Schweif bedeutet dieser Code nur 1 Pfeil.

Wenn du schon beim Forschen bist, sage ich dir gleich mal, was mich derzeit am dringendsten interessiert:

1. wo sind die restlichen Kämpfe in Schweif gespeichert?
2. Kann man einen Tempel in Riva umtaufen? Kann man überhaupt ein Gebäude mit Funktion einbauen, eventuell die Warenschau aktivieren?

[Helios]

Ah, das hört sich doch interessant an. Was steckt da an Infos drin?

Ich weiß es leider noch nicht, sieht ziemlich kryptisch aus. Wahrscheinlich Flags und Offsets.

Wenn du magst, kannst du auch noch Infos zu den anderen Dateiformaten aus der DUNGEON.ALF heraussuchen, also z.B. DSC, NEI, PPD, TAB. Mich würde immer noch interessieren, wo so Dinge wie Türen, Kisten etc. gespeichert sind, d.h. woher Riva bei der 3D-Karte weiß, dass da jetzt eine Kiste ist und was da drin ist.

Kann ich gerne versuchen, es scheint auch sowas wie einen Editor oder ähnliches zu geben der aber deaktiviert ist. Bisher waren meine Versuche den zu aktiven auch nicht erfolgreich.
Aber man kann viele Sachen wie Kollision, PolygonSort und ähnliche Dinge einstellen.
TAB beinhaltet die Fog-Tables, also wie stark der Nebel ist. Den Rest versuche ich auch zu finden.
Mir ist bisher auch nicht klar wie die Zuordnung der Kisten usw. funktioniert. Hatte gehofft es gäbe dazu in den 3DM Dateien etwas.

Das klingt ja interessant. Ich glaube aber nicht, dass Kräuter in einen anderen Zustand übergehen können. Es gibt zwar das Trockenwirselkraut mit stärkerer Heilwirkung und zweimal trockene Einbeeren, einmal mit Heil- und einmal mit Schadwirkung. Diese Wirkung ändert sich aber glaube ich nie von selbst, entweder sind sie von Anfang an schlecht oder von Anfang an gut. Die einzige Möglichkeiten, etwas zu verändern, ist der Zauberspruch abvenenum, der die schlechten Einbeeren in normale verwandelt. Das ist aber eine normale Umwandlung während des Spiels und müsste dann nicht bei den Truheninhalten vermerkt werden. Ich kann also keinen Sinn hinter einem solchen Timer erkennen. Wenn man von der Windsbraut zurückkommt, verdirbt zwar ein Großteil der Kräuter, die sind dann aber ganz verschwunden und der Rest ist stinknormal, da braucht man auch keinen Timer. Es scheint also wirklich überflüssig zu sein

Ich war mir eigentlich ziemlich sicher sowas schon mal erlebt zu haben. Also die Umwandlung von Wirselkraut zu Trocken Wirselkraut. Allerdings im Inventar. Vielleicht täusche ich mich auch oder es war in einem anderen Teil.

1. wo sind die restlichen Kämpfe in Schweif gespeichert?

Wie gesagt, ich tippe auf die Schweif.exe. Vielleicht werden nur die Daten der FDEFMAT.DAT mit der aus der Anwendung ergänzt. Es gibt wie gesagt einige Datenblöcke die Ähnlichkeit haben aber viel zu klein sind. Aber gerade die ganzen Dats die mit F beginnen, also etwas mit den Kämpfen zu tun haben, sind noch nicht entschlüsselt.

2. Kann man einen Tempel in Riva umtaufen? Kann man überhaupt ein Gebäude mit Funktion einbauen, eventuell die Warenschau aktivieren?

Da sprichst du zwei interessante Punkte an.
Also ich bin mir ziemlich sicher, dass im Prinzip alle Götter implementiert sind. Zumindest einige Strukturen haben genug Einträge. Aber wie die eigentlich Zuordnung funktioniert ist mir halt unklar, wie weiter oben schon geschrieben.

[Wetzer]

Nachdem ich ein wenig mit den Vertexdaten herumgespielt habe und die Texturzuordnung fast verstanden habe, konnte ich zumindest mal die bisher relativ seltsamen T_, Q_, U_, N_, etc. Materialien verstehen. Diese Objekte sind komplett unsichtbar, bieten aber Funktionalitäten für's Spiel.

Ich denke "T_" könnte für "Trigger" stehen.

Insbesondere bei den Läden ist das interessant: Die blockierende Fläche muss wohl sein, weil man sonst durch den Laden durchlaufen könnte.

Ich weiß aber noch nicht, ob die Funktionalität über das Material kommt oder im Objekt kodiert ist und das Material nur für die Entwickler eine Art Hinweis sein sollte.

Könnte das vielleicht eine Vorform einer Collisionbox sein? Nur zweidimensional? Das ist wahrscheinlich Resourcen-schonender als mit einer Physik-Lib jede Kante eines 3D-Objektes zu überprüfen.

Was auch interessant sein könnte:
* Wie wird die durchgehbare Wand in der Katakombe unter dem Boronsacker dargestellt (sichtbar, aber durchgehbar)?
* Es werden in den Katakomben nach gewissen Aktionen andere Texturen dargestellt (abgebrannte Bücherregale, abgenommes Symbol zur Gruft). Wie wird das gemacht?
* welche Karten ausser der Markthalle haben noch einen leeren, unbekannten Daten-Block in der 3DM? Vielleicht sind da Kämpfe hinterlegt (Markhalle hat keine) oder Lichtquellen?
*Für eine Zuordnung zwischen dem Weltkoordinaten und den Objektkoordinaten müsste man wohl sowas wie einen Nullpunkt am Objekt definieren. Von dort aus wird das Objekt aufgebaut. Nullpunkt des Objektes = Koordinate (Standort) im Weltsystem? Hier könnte wieder die Markhalle interessant sein: Die Wände der Halle oder eine Ecke davon könnte mit dem Weltsystem 0,0,0 übereinstimmen. Von da aus könnte man auf eine Objektkoordinate schließen.
* Wie werden animierte Texturen (Wasser) angesteuert? Es gibt da eine .DSC-Datei. Ich vermute die steuert nur die Geschwindigkeit der einzelnen Bilder. Welche Textur und welche einzelnen Bilder dargestellt werden steht da nicht drin.

[Helios]

Kleiner Nachtrag.
Habe Informationen zu D_EXPOSA.DAT, LOC_GODS.DAT und LOC_DEIT.DAT ergänzt. Also theoretisch könnte man die Tempel "umtaufen". Aber praktisch funktioniert es nicht. Von D_EXPOSA bin ich auch enttäuscht, da Riva die Änderungen jedes mal überschreibt.

Edit:

* Wie werden animierte Texturen (Wasser) angesteuert? Es gibt da eine .DSC-Datei. Ich vermute die steuert nur die Geschwindigkeit der einzelnen Bilder. Welche Textur und welche einzelnen Bilder dargestellt werden steht da nicht drin.

Doch steht drin. Die Texturen sind die Dateien im PIX Format. Und die Namen sind identisch. Folgend mal die DSC von BORON2.

# ANIMATIONS-TEXTUREN:
# --------------------

# Typ: Dateiname: Frames: Breite: Höhe:

MAP: BO2_FLAM 10 64 64

# ANIMATIONS-ABLÄUFE:
# -------------------

# Typ: Name: Frame-Nr,Dauer (in Hundertstel Sek.)...

PHASE: FACKEL 0,10 1,10 2,10 3,10 4,10 5,10 6,10 7,10 8,10 9,10

# BEWEGTE ODER ANIMIERTE OBJEKTE:
# -------------------------------

# Typ: Objektname: Höhe: Speed: Texture: Frames: Ablauf:

OBJECT: 21L9999_02 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 24L9999_T1 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 08L9999_01 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 31L9999_01 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 27L9999_08 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 04L9999_01 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 05L9999_01 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 03L9999_02 0.0 0.0 BO2_FLAM 10 FACKEL
OBJECT: 07L9999_02 0.0 0.0 BO2_FLAM 10 FACKEL

OBJECT: 01N8001_T1 100.0 200.0 - 0 -
OBJECT: 33N8007_01 100.0 200.0 - 0 -
OBJECT: 32N8006_01 100.0 200.0 - 0 -
OBJECT: 23N8002_01 100.0 200.0 - 0 -
OBJECT: 30N8005_01 100.0 200.0 - 0 -
OBJECT: 28N8004_01 100.0 200.0 - 0 -
OBJECT: 25N8003_01 100.0 200.0 - 0 -

[Helios]

@Shihan
Die .NEI sind wohl dafür zuständig die Abschnitte einer Map zu verbinden. Danach wäre die erste Zahl die ID oder Index, die nächsten Zahlen stellen dann die Abschnitte dar die damit (optisch) verbunden werden.

Beispiel:

1,6,21
Meint das der Eingang (1) mit zwei weiteren Abschnitten verbunden wird.

6,1
Danach ist 6 ein Raum der nur mit dem Eingangsabschnitt verbunden ist.

21,1,22
Wäre ein weiterer Gang, der wieder mit dem Eingangsabschnitt und einem weiteren Eintrag verbunden ist.
usw.

PPD müsste die Animation des Himmels, vielleicht auch des Wassers enthalten.

[Shihan]

Könnte das vielleicht eine Vorform einer Collisionbox sein? Nur zweidimensional? Das ist wahrscheinlich Resourcen-schonender als mit einer Physik-Lib jede Kante eines 3D-Objektes zu überprüfen.

Ja, eben. Aber die Frage ist, ob das ausschließlich über das zugewiesene Material gesteuert wird (Half-Life 1 hatte das bspw. so gemacht) oder ob es noch einen anderen Switch dafür in der 3DM gibt

*Für eine Zuordnung zwischen dem Weltkoordinaten und den Objektkoordinaten müsste man wohl sowas wie einen Nullpunkt am Objekt definieren. Von dort aus wird das Objekt aufgebaut. Nullpunkt des Objektes = Koordinate (Standort) im Weltsystem? Hier könnte wieder die Markhalle interessant sein: Die Wände der Halle oder eine Ecke davon könnte mit dem Weltsystem 0,0,0 übereinstimmen. Von da aus könnte man auf eine Objektkoordinate schließen.

Die Markthalle z.B. macht keinen Unterschied zwischen Welt- und Objektkoordinaten. Wenn ich die Vertices untransformiert übernehme und alle Objekte in eine Blender-Szene packe, habe ich alles am richtigen Platz. Eventuell gibt es bei komplexeren Karten eine Unterscheidung! Das muss man noch herausfinden!

@Shihan
Die .NEI sind wohl dafür zuständig die Abschnitte einer Map zu verbinden. Danach wäre die erste Zahl die ID oder Index, die nächsten Zahlen stellen dann die Abschnitte dar die damit (optisch) verbunden werden.

[..]

PPD müsste die Animation des Himmels, vielleicht auch des Wassers enthalten.

Alles klar, also so eine Art Portalsystem wie bei der Source-Engine. Das ist interessant. Werde mich in den nächsten Tagen mal an die anderen Karten setzen und sehen, was ich da herausfinden kann. Aber die Erkenntnisse über die NEI sind gut!