Modding-Tools für die NLT

[Hendrik]

Super, HenneNWH, danke für den Fix.

[Tronde Swafnildson]

Wie funktioniert das nun?
(Entweder stehe ich komplett auf dem Schlauch oder mhh)

[Rabenaas]

z.B. so:

Code:

nltpack m schick.dat
nltpack l schick.dat
nltpack x schick.dat

Das zeigt zuerst den Inhalt von schick.dat an, und extrahiert ihn dann.

[Sannah]

Hmn, wie wäre es den Packer einfach in den TotalCommander einzubinden? Dann könnte man sich den ganzen CMD Quatsch sparen. Ich habe schon einige Spiele gemodded, da war der TC eigentlich immer sehr vorteilhaft um schnell was zu packen/entpacken, zumal das Teil schon ne Menge Packerformate für andere Games unterstützt mit den richtigen Plugins.

[Hendrik]

Hallo Sannah,

eigentlich eine gute Idee. Für das Entpacken ließe sich das sicher ohne großen Aufwand bewerkstelligen, es wäre dann natürlich nicht mehr plattformunabhängig, sprich, als Linuxnutzer könnte ich mit dem Plugin nix anfangen, auch wenn ich unter Windows den TC gerne benutze.

Technisch ist auch eher das Packen ein Problem. Alle drei Teile der NLT sind empfindlich, was die Reihenfolge und Anzahl der Dateien in den Archiven betrifft. Deshalb auch die - zugegebenermaßen nicht sehr elegante - Lösung mit dem "m"-Switch. Man könnte also nur Dateien ersetzen, die schon im Archiv drinstecken, und müsste verhindern, dass der User irgendeine Datei ins Archiv steckt bzw. ein neues Archiv anlegt.

[Sannah]

Naja, war auch nur ne Idee Gibt es eigentlich noch ein lebendes Projekt zur NLT, wo man das Tool auch nutzen kann? Im Modding-Bereich hab ich leider nichts gefunden.

[Hendrik]

Hatten wir die Frage nicht gerade erst?

Die angegebenen Links dürften so ziemlich alles zusammenfassen, was es an Modding-Tools zur NLT bisher gibt. Dass wir noch einiges an Plänen haben und sporadisch daran gearbeitet wird, hat Rabenaas ja schon erwähnt. Meine persönliche Priorität liegt momentan darauf, den DosBox-Logger auf Sternenschweif auszuweiten. Anschließend hatte ich vor, einen Bildformat-Konverter zu schreiben, mit dem man übliche Formate (jpg, png) in Bilder für die NLT(.nvf, .ace, .bob) zu konvertieren, aber das ist noch ein großes Stück Arbeit.

[Hendrik]

Aus akutellem Interesse an der Konvertierung von Bildern aus der NLT in gängige Grafikformate (und umgekehrt) möchte ich hier mal meine Überlegungen teilen, die schon seit längerer Zeit zu dem Thema in meinem Kopf herumgeistern.
Es ist ja ganz schön, dass wir NVF-Dateien und auch .ACE zu schönen Bildern (bmp/tga) machen können. Auch sollte es möglich sein, den umgekehrten Weg zu gehen und aus einem .bmp-Bild oder einem anderen üblichen Grafik-Format mit ein paar Zusatzinformationen ein .NVF oder .ACE zu bauen.

Allerdings gehen beim Konvertieren der Bilder der NLT in gängige Formate Informationen verloren: Crunchmode, Animations-Parameter, Zusammenhang der Bilder einer Animation u.s.w. Das sind Metainformationen, die man bei BMP, TGA und Konsorten so nicht findet. Und es wäre schön, wenn man diese Metainformationen zusammen mit dem Bild bzw. der Animation speichern könnte. Dann könnte man z.B. einen "Meta-Editor" schreiben, der diese Metainformationen bearbeiten kann und z.B. für einzelne Frames aus der Animation das Lieblings-Grafikprogramm aufruft.

Meine Frage ist folgende: Welches gängige Grafikformat ist für diesen Zweck am besten geeignet? Ich sehe 2 Lösungen:
1.) Wir finden ein Grafikformat, das nicht nur mehrere Bilder (Animationen!) unterstüzt, sondern auch Platz für die Meta-Informationen bietet (z.B. codiert in einem Kommentar-Feld). Mag sein, dass wir dafür einen kleinen Extra-Editor benötigen, aber die Informationen lassen sich alle zuverlässig in der einen Datei speichern und verschwinden nicht bei der Bearbeitung mit einem Grafikprogramm. Die Frage ist nur, gibt es da ein geeignetes Format?
2.) Wir basteln uns unser eigenes Meta-Format. Da stelle ich mir so etwas vor wie eine ZIP-Datei, die neben den einzelnen Bildern eine XML-Datei enthält mit den Metadaten. Hier wäre dann ein Meta-Editor praktisch, der neben der Bearbeitung der Metadaten erlaubt und mit dem man z.B. einzelne Bilder zum Bearbeiten temporär aus dem Archiv holen kann.

Wie ist eure Meinung dazu? Welches Format wäre geeignet, oder gibt es noch eine bessere Idee?

P.S.: Eine grobe Übersicht über benötigte Metainformationen (nebst Vorschlägen für eine DTD) habe ich schon einmal gemacht.

[Rabenaas]

Warum denn so ein Aufwand? Es reicht doch auch ein Konvertierer, der eine XML-Datei als Argument bekommt, welche die Metainformationen enthält und die Bitmaps referenziert.

[tommy]

ein gängiges Bildformat zu verwenden halte ich für sehr problematisch, da mir keins bekannt ist, was allen anforderungen gerecht werden kann.

Die für mich sinnvollste Lösung ist selber ein Tool zu schreiben, welches NVF dateien bearbeiten kann und auch die nötigen Metadaten enthällt. Das sollte mit relativ geringen aufwand möglich sein, problematisch dabei ist nur, das gerade bei DSA1 öfters die farbpalette fehlt und es sehr aufwendig ist die Farbpaletten manuel einzugeben.

[Hendrik]

Warum denn so ein Aufwand? Es reicht doch auch ein Konvertierer, der eine XML-Datei als Argument bekommt, welche die Metainformationen enthält und die Bitmaps referenziert.

Ja, viel mehr wollte ich auch nicht - nur dass man die Bilder noch in ein .ZIP reinpackt und einen kleinen Editor für die Metadaten bereitstellt. Aber du hast recht, das ist nicht wirklich nötig.

ein gängiges Bildformat zu verwenden halte ich für sehr problematisch, da mir keins bekannt ist, was allen anforderungen gerecht werden kann.

Die für mich sinnvollste Lösung ist selber ein Tool zu schreiben, welches NVF dateien bearbeiten kann und auch die nötigen Metadaten enthällt. Das sollte mit relativ geringen aufwand möglich sein, problematisch dabei ist nur, das gerade bei DSA1 öfters die farbpalette fehlt und es sehr aufwendig ist die Farbpaletten manuel einzugeben.

Gerade das halte ich für rech aufwändig. Wieso ein Grafikprogramm neu erfinden, wenn es so viele gute gibt? Ohnehin hat jeder sein Lieblingsprogramm. Dann lieber ein Konsolentool, was aus einer XML-Datei und einem Haufen Bilder ein NVF macht (und umgekehrt), und evtl. einen Editor für die XML-Daten (für sowas gibt es ja Toolkits, mit denen man in wenigen Minuten einen Editor zusammenstellen kann). Und die Bearbeitung der Bilder würde ich lieber den Experten überlassen (Gimp, Photoshop, ...).

Was die Farbpalette angeht: Na ja, wenn du ein Export-Tool hast, kannst du von den Bildern, die eine Palette haben, diese in der XML speichern (oder in der Ausgabe-Bilddatei). Für alles andere kennen wir die Paletten, und die müssen nur einmal konvertiert werden, nach XML oder einem Paletten-Format (haben wir sogar schon) - dann kann man sie immer wieder verwenden.

[tommy]

Gerade das halte ich für rech aufwändig. Wieso ein Grafikprogramm neu erfinden, wenn es so viele gute gibt? Ohnehin hat jeder sein Lieblingsprogramm. Dann lieber ein Konsolentool, was aus einer XML-Datei und einem Haufen Bilder ein NVF macht (und umgekehrt)

ok da hast du natürlich recht, wird wohl die beste variante sein.

Was die Farbpalette angeht: Na ja, wenn du ein Export-Tool hast, kannst du von den Bildern, die eine Palette haben, diese in der XML speichern (oder in der Ausgabe-Bilddatei). Für alles andere kennen wir die Paletten, und die müssen nur einmal konvertiert werden, nach XML oder einem Paletten-Format (haben wir sogar schon) - dann kann man sie immer wieder verwenden.

ich habe ehrlich gesagt noch nie mit festen farbpaletten gearbeitet...können denn viele Programme feste paletten aus einer xml laden? Ansonsten würde es sich eher anbieten normale Bilder auf feste fabpaletten zu reduzieren, dass sollte sich algorithmisch recht leicht erledigen lassen und falls es doch mal eine Farbe gibt, die sich nicht so einfach umwandeln lässt, könnte man dan den nutzer entscheiden lassen wie diese Konvertiert wird.
Ist nur sone idee.

[Rabenaas]

ich habe ehrlich gesagt noch nie mit festen farbpaletten gearbeitet...können denn viele Programme feste paletten aus einer xml laden?

XML nicht unbedingt. Jedes Grafikprogramm hat sein eigenes Format für Paletten.

Ansonsten würde es sich eher anbieten normale Bilder auf feste fabpaletten zu reduzieren, dass sollte sich algorithmisch recht leicht erledigen lassen und falls es doch mal eine Farbe gibt, die sich nicht so einfach umwandeln lässt, könnte man dan den nutzer entscheiden lassen wie diese Konvertiert wird.

Ja, aber man muss dann gleich mit einer beschränkten Anzahl von ausgewählten Farben arbeiten, was wieder auf eine Palette hinausläuft. Sonst dominieren wie in alten Scans verwaschene Grau und Fleischfarben, was nicht zum Stil der NLT passen würde.

Ich empfehle für unsere Zwecke das Programm GrafX2, einen freien DeluxPaint-Klon.

EDIT: Vielleicht könnte man für GrafX2 auch einfach Import-/Exportfilter schreiben. http://code.google.com/p/grafx2/wiki/LoadSaveSystem

[tommy]

Ja, aber man muss dann gleich mit einer beschränkten Anzahl von ausgewählten Farben arbeiten, was wieder auf eine Palette hinausläuft. Sonst dominieren wie in alten Scans verwaschene Grau und Fleischfarben, was nicht zum Stil der NLT passen würde.

ich hatte es so gedacht, das man dei "creativen Leuten" ein Bild einer farbpalette mitausliefert an dem sie sich orientieren können. Asonsten hast du halt wieder das Problem, das die speziellen farbpaletten in ein bestimmtes Programm importiert werden müssen.

Ich empfehle für unsere Zwecke das Programm GrafX2, einen freien DeluxPaint-Klon.

dabei entsteht dann wieder das Problem, dass man an ein bestimmtes Grafiktool gebunden ist, und das könnte dem einen oder anderen nicht sehr gefallen.

ich denke auch egal wie man es lösst, es wird immer irgendwie vor und nachteile haben

[Rabenaas]

ich hatte es so gedacht, das man dei "creativen Leuten" ein Bild einer farbpalette mitausliefert an dem sie sich orientieren können.

gute Idee

dabei entsteht dann wieder das Problem, dass man an ein bestimmtes Grafiktool gebunden ist, und das könnte dem einen oder anderen nicht sehr gefallen.

Nicht unbedingt. Wer wirklich unbedingt mit einem anderen Programm arbeiten möchte, kann aus/in GrafX2 dann z.B. PNG ex-/importieren.

[Hendrik]

Nach ein wenig Recherchen zum GIF-Format habe ich festgestellt, dass GIF ziemlich viel von dem unterstützt, was wir benötigen: Animationen, Teilbilder mit eigener Startposition/Größe und Anzeigedauer. Was leider fehlt, sind Namen für die einzelnen Frames, die könnte man zur Not in einem Kommentar speichern.

Für die XML-Lösung hatte ich mir damals folgendes überlegt (ohne Anspruch auf Vollständigkeit):

Spoiler

Format der XML-Datei (DTD)
* Allgemeine Attribute
Die wollte ich ursprünglich alle als Attribute. Da sie aber mehrfach vorkommen, sind Elemente vielleicht angemessener.
** animspeed [uint]
** label/name [string]: Name einer Sequenz o.ä.
** playmode [???]
** xoffset, yoffset [int]: Kommt in Sequenzebene und Einzelbildebene in verschiedenen Formaten vor.
** width, height [uint]: Kommt von Dateiebene bis Einzelbildebene in allen Formaten vor.
** action [???]
** Compression [string(case-insensitive):{auto,raw, rle, powerpack}]: Kommt von Dateiebene bis Einzelbildebene in verschiedenen Formaten vor.
* Auto-Attribute: Diese Attribute sollen automatisch beim Lesen der XML-Datei ermittelt werden.
** Anzahl der Sequenzen in der Datei: Danach richtet sich teilweise das Header-Format.
** Anzahl der Bilder in einer Sequenz: Sollte man wissen, bevor man eine Sequenz speichert.
* nltgraphic: Dieser Tag ist die Wurzel eines NLT-Bildes.
Attribute:
** format [string(case-insensitive):{nvf,ace,bob,raw}]
Gibt das Bildformat an. Dieser Parameter /muss/ angegeben werden; es gibt keinen Default-Wert.
** compression [string(case-insensitive):{raw,rle,powerpack,auto}]: Gibt das Teilformat des Formats an. Betrifft hauptsächlich NVF, aber auch andere Formate (bob) haben Varianten. *todo*: Default wird je nach Format gewählt.
** compression [string(case-insensitive):{raw,rle,powerpack,auto}]: Kompressions-Algorithmus. Die einzelnen Formate haben Default-Werte; bei format=raw ist compression=raw Default, ansonsten compression=auto. Der "auto"-Wert probiert erst sowohl rle als auch powerpack und wählt dann den Algorithmus, die kleinste Datei erzeugt.
* sequence: Enthält eine Folge von Bildern. Vorkommen: Innerhalb von <sequence> und <nltgraphic>, sonst nicht. Dadurch kann man mehrere Sequenzen innerhalb eines Bildes definieren, wie z.B. für .bob benötigt.
Attribute:
** name: Name der Sequenz. Wird z.B. im .bob-Format benötigt. Es muss (durch den Konverter) sichergestellt werden, dass dieser Name die korrekte Länge hat. Ansonsten Fehlermeldung ausgeben.
** compression: Kompressionsmodus. Wird von oben weitervererbt.
** offsetx, offsety: Ganzzahliges Offset des Bildes. Default=0
** width, height: Natürlichzahlige Dimensionen des Bildes. Kein Defaultwert.
Sollten diese Werte nicht mit denen einer Bilddatei übereinstimmen, gib eine Warnung aus (was durch die Vererbung ohnehin geschehen sollte).
* image
Inhalt ist der Dateiname des Bildes. Format wird automatisch (anhand der Endung) erkannt.
Vorkommen: Innerhalb von <sequence> und <nltgraphic>, sonst nicht.
Attribute:
** in_format: Dient zum manuellen Setzen des Formates der Eingabedatei. Definitionsbereich: png, gif, bmp, ... -- je nachdem, was der Konverter unterstützt.
** compression: Kompressionsmodus. Wird von oben weitervererbt.
** offsetx, offsety: Ganzzahliges Offset des Bildes. Default=0. Sollten diese Werte width/height der enthaltenden Sequenz übersteigen, wird eine Warnung/Fehlermeldung ausgegeben.
** width, height: Natürlichzahlige Dimensionen des Bildes. Default=(Größe des eingelesenen Bildes aus der Bilddatei). Sollten diese Werte nicht mit denen der Bilddatei übereinstimmen, gib eine Warnung aus. Sollten diese Werte (plus Offset) width/height der enthaltenden Sequenz übersteigen, wird eine Warnung/Fehlermeldung ausgegeben. (*TODO*: Sollten diese Werte beim Auslesen von Bildern in die XML-Datei geschrieben werden oder nicht?)
* palette: Palette kann als Datei angegeben werden oder durch Paletteneinträge
Attribute:
** size [uint:0...256]: Wie viele Farben enthält die Palette? Default: 256.
** palettefile: Datei, aus der die Palette gelesen wird. Da könnte man noch so Sachen einbauen wie z.B. "lies nur die ersten 32 Farben aus dieser Datei".
Inhalt ist der Dateiname.
* paletteentry
Attribute:
** r,g,b: Palettendaten. Angabe als Integer-Wert von 0 bis 255. Default = 0.

[Rabenaas]

In welcher Sprache soll der Konverter geschrieben werden?

[Hendrik]

In welcher Sprache soll der Konverter geschrieben werden?

Eigentlich C++, ich schreibe Prototypen aber auch gern in Ruby.

[Rabenaas]

Wer für Ruby ist, der hebe nun die Hand.

[wiese.hano]

In welcher Sprache soll der Konverter geschrieben werden?

Mir ist es egal. Wichtig ist nur, dass der gesamte Quellcode wirklich gut dokumentiertiert, bzw. kommentiert wird. Damit auch andere, wie meine Wenigkeit, die Möglichkeit haben, nachzuvollziehen, was dort passiert. Mir wäre das zu Mindest wichtig.