Level-/Karteneditor für Historyline 1914-18

Ich habe ein neues Projekt angefangen, einen Karteneditor für Rundenstrategieklassiker Historyline 1914-18.

Historyline ist eines meiner lieblings DOS-Games. In den 90ern habe ich mir regelmäßig erbitterte Schlachten mit Freunden geliefert und entsprechend viele tolle Erinnerungen daran.

Leider ist der Computergegner ziemlich simpel gestrickt und die Karten kennt man mittlerweile natürlich in und auswendig. Hier fehlt doch eindeutig die Möglichkeit, eigene Karten zu erstellen!

Die Editoren, die es für Battle Isle gibt, funktionieren leider für History Line (einen Ableger der Reihe) nicht. Daher habe ich mich vor Jahren schon mal daran versucht, herauszufinden, wie die Karten im Spiel gespeichert sind und möglichst einen Editor zu schreiben. Damals bin ich aber daran gescheitert, dass alle Datendateien des Spiels gepackt sind - mit dem Turbo Packer von Wolfang Meyerle, einem Packer der nur für den Amiga und den Atari ST erschien. Mehr Infos habe ich damals nicht gefunden und die exe-Dateien zu disassemblieren, die Entpackroutine zu finden und mühsam aus dem Code zu erschließen... die Mühe war es mir dann auch nicht wert. Ich habe noch etwas herumprobiert und es dann sein gelassen.

Vor ein paar Tagen habe ich dann in der Mittagspause etwas bei Github herumgestöbert und dabei ein interessantes Projekt gefunden: "Ancient - Modern decompressor for old data compression formats" von Teemu Suutari. Und in der Liste der unterstützten Formate finde ich dann plötzlich "Turbo Packer by Wolfgang Mayerle"! Natürlich erinnerte ich mich sofort an meine vergeblichen Versuche, History Line seine Geheimnisse zu entlocken und war sofort wieder voll dabei

In TPWMDecompressor.cpp steht alles, was ich damals an Info gebraucht hätte. Zudem findet man mittlerweile m Netz sogar Infos vom Autor des Packers!

Der Dateiheader besteht aus der ID "TPWM" gefolgt von vier Byte, die die größe der ungepackten Daten enthalten, dann das erste "Steuerbyte" und damit das, was ich damals selber nich herausgefunden habe.

Hier geben die Bits an, wie die nachfolgenden 8 Byte zu interpretieren sind. 0 = Byte wird einfach übernommen. 1 = es folgt eine Sequenz, die in den bereits entpackten Daten schon vorliegt und an diese Stelle kopiert werden muss. In diesem Fall werden zwei Byte gelesen, die die Länge der Seqenz und den Offset (bzw. den relativen Abstand vom aktuellen Offset in den schon entpackten Daten) enthalten. Nach acht Byte folgt dann das nächste Steuerbyte. Das ist es im Grunde schon.

Muss man nur wissen

Und besonders gut ist, um entpackte und geänderte Daten für das Spiel wieder zu packen, muss man sich nicht den kompletten Pack-algorithmus des Turbo Packer nachbauen. Es reicht ja, den Header und alle acht Byte ein 0-Byte (Steuerbyte, dass die nächsten acht Byte einfach übernommen werden) einzufügen. Die Datei wird dann zwar größer anstatt kleiner, aber die Dekompressionsroutine hat wieder Daten, mit denen sie etwas anfangen kann.

Ich habe es ausprobiert und das Entpacken der Spieldateien funktioniert ganz problemlos!

Und auch zum Aufbau der Karten habe ich dann schon einiges herausgefunden:

Die Karten sind im Unterverzeichnis Maps zu finden. Für jede Karte gibt es eine .fin und eine .shp Datei und für die Kampagnen-Karten auch eine .com (ist aber nicht ausführbar) und dann gibt es noch .hi Dateien mit der Highscore-Liste.

Gestern Abend habe ich damit etwas herumprobiert und schon einiges herausgefunden:

Zuerst kommen die Karten auf deutscher, dann die auf französischer Seite und dann die zwei Spieler Karten. 00.fin/00.shp enthalten also die Daten für "PULSE", 71.fin/71.shp die für "GREEN".

Die .fin Datei enthält die Kartendaten

Hier konnte ich den Aufbau auch schnell mit einem Hex-Editor herausfinden:

Am Anfang steht die Kartengröße in vier Byte (zwei hätten es auch getan, oder wie groß haben die bei BlueByte Karten geplant?!?).

Dann folgen zwei Byte für jedes Hex-Feld. Das erste Byte gibt an, welche Terrain-/Bodengrafik für das Feld verwendet werden soll, das zweite, was für eine Einheit auf dem Feld steht.

Steht keine Einheit auf dem Feld, wird das zweite Byte auf FF gesetzt.

00 00 erzeugt zum Beispiel einen deutschen Spähpanzer auf Gras, 00 FF ein leeres Grasfeld und 01 FF den Eingang einens deutschen Hauptquartiers.

Interessant ist hier: Sobald ein Gebäudeeingang gestzt wird, erkennt das Spiel das Gebäude. Den Rest des Gebäudes braucht es also eigentlich nicht.

In der Datei ist die Karte jeweils eine Reihe größer gespeichert, als im Spiel sichtbar ist. Als Daten für nicht sichtbare Felder sind AE FF gesetzt.

Das ist alles in den .fin Dateien, aber damit ist die größte Hürde, um einen Karteneditor zu schreiben, ja eindeutig schon genommen.

Die .shp Dateien scheinen die zusätzlichen Infos zu enthalten. Zum Beispiel, welche Einheiten sich in neutralen Gebäuden befinden, ob die Karte im Sommer oder Winter spielt, welche Einheiten in Fabriken gebaut werden können,

wie viele Rohstoffe die Spieler bekommen usw. Das ändert sich nämlich auch, wenn man mal die .shp Dateien der Karten tauscht.

Hier muss ich den Aufbau noch herausfinden und auch, was es mit den .com Dateien auf sich hat.

So weit bin ich bisher. Es sieht also gut aus für einen Historyline 1914-18 Mapeditor.

Vielleicht hat ja jemand von euch Lust mitzumachen?

Alle Grafiken liegen übrigens als .lbm oder .iff Dateien vor und lassen sich nach dem Entpacken problemlos ansehen oder auch bearbeiten.

In den .dat und .lib Dateien sind mehrere Grafikdateien zusammengefasst, die lassen sich aber einfach auslesen, da alle einzeln gepackt worden sind und jede neue Datei daher mit "TPWM" beginnt.

Man könnte jetzt also auch eine Historyline-Grafik-Mod machen

Zitat von moravec

Dragonsphere ich weiß nicht ob meine "vor 30 Jahren mal Tirbopascal in der Schule Skills" helfen, würde das Projekt aber gerne unterstützen - denn auch ich brauche neue history line Karten

Erstmal steht ja noch nicht viel Programmierung an, denn wir müssen ja herausbekommen, wie die Spieldateien aufgebaut sind. Und dafür braucht es nur einen Hexeditor und etwas Zeit zum Testen.

Hier würde ich mich sehr über Unterstützung freuen. Ich schreibe gleich noch, was ich bisher herausgefunden habe und stelle hier mein kleines Programm zum Entpacken der Spieldateien rein. Und dann kann es los gehen

Zitat von Stefan307

Oh, da ist mir damals was entgangen...

Auf jeden Fall! Wenn du das Spiel noch nicht kennst und Rundenstrategie magst, solltest du es dringend mal ausprobieren.

Zitat von Fanhistorie

Guten Abend

Dragonsphere

Ein wohl sehr interessantes Spiel, auch wenn ich es selbst nur als Zuschauer erlebte...,

Was mich dabei aber mehr faszinierte als ich bei dem Bekannten war, das damalige sehr gute Handbuch, wo die Einheiten detailreich beschrieben waren, und auch den geschichtlichen Hintergrund,

Für die Mitleser, damit sich sich selbst eine Meinung bilden können, daraus ein pasr Screens,

Alles anzeigen

Das Handbuch hat mich auch immer fasziniert. Toll gemacht und mit den ganzen Fotos und Beschriebungen der damaligen Einheiten war es wirklich besonders. Genau wie auch der Intro des Spiels. Als damals in der Schule mal Bismarks Bündnispolitik an der Reihe war, lief der History-Line Intro vor meinem geistigen Auge ab

Über Weihnachten/Neujahr bin ich kaum dazu gekommen, aber ein bisschen was neues habe ich in der letzten Zeit noch rausgefunden.

Erstmal eine sehr gute Nachricht: Das Spiel akzeptiert auch ungepackte Dateien. Geänderte Karten/Spieldateien müssen also nicht wieder gepackt werden.

Aufbau der .shp Dateien:

Am Anfang stehen 50 Byte die als Wert entweder 0 oder 1 haben. Durch ausprobieren habe ich herausgefunden, dass hier festgelegt wird, welche Einheiten vom Spieler gebaut werden können.

Jedes Byte steht für eine Einheit, erst 25 deutsche, dann 25 französische. 0 bedeutet, dass die entsprechende Einheit in Fabriken gebaut werden kann, 1, dass sie nicht verfügbar ist.

Dann, an Offset 50 (32h), steht in einem Byte die Anzahl der Gebäude auf der Karte.

Dann folgen Infos zu den einzelnen Gebäuden, angefangen mit den beiden Hauptquartieren (erst D, dann F). Die Infos zu den Gebäuden scheinen wie folgt aufgebaut zu sein:

Erst kommen 3 Byte, deren Bedeutung mir akuell noch nicht klar ist.

Dann folgt in einem Byte, wie viele Ressourcen das Gebäude generiert.

Dann wieder ein Byte, dessen Bedeutung ich noch nicht kenne.

Und dann folgen sieben Byte, die angeben, welche Einheiten sich in dem Gebäude befinden (FFh (255) steht hier für einen leeren Stellplatz im Gebäude).

Soweit bin ich bisher.

Für alle Interessierten, hier der Code für mein kleines Entpack-Programm (diesmal in C). Bisher kann es nur max. 64 KB große Dateien verarbeiten. Reicht für die Karten, aber für die Grafiken muss ich es noch optimieren. Eine ZIP-Datei TPWM Entpacker.zip mit dem Programm hänge ich mal an, dann könnt ihr selber loslegen

Verbesserungsideen für das kleine Programm könnt ihr mir natürlich auch gerne hier schreiben.

//Entpacker für Dateien, die mit dem Turbo Packer von Wolfgang Meyerle
//gepackt wurden. 
//Autor: DragonSphere / DOSReloaded 
//Version: 1.0 vom 22.12.22

#include <conio.h>
#include <stdio.h>
#include <stdlib.h>
#include <iostream.h>

FILE         *f;
long         psize;
long         upsize;
char*        inbuf;
char*        outbuf;


int ReadingError()    //Gibt Fehlermeldung aus, den Speicher frei und schließt die Datei
{
  printf("Fehler beim Lesen der Datei! \n");
  fclose(f);
  if (inbuf != NULL) free(inbuf);     
  if (outbuf != NULL) free(outbuf);
  exit(1);
  return 0;
}


int getbit(char n, int bitwanted)  //Abfrage des Status eines einzelnen Bits
{
 int thebit = (n & (1 << bitwanted)) >> bitwanted;
 return thebit;
}




int Decrunch()   //Die eigentliche Entpackroutine (gepackte Daten aus "inbuf" werden nach "outbuf" entpackt)
{
  unsigned char b1;
  unsigned char b2;
  unsigned char packbyte;
  char          bit;
  unsigned int  i;
  unsigned int  inofs;
  unsigned int  outofs;
  unsigned int  distance;
  unsigned int  length;


  outofs = 0;
  inofs = 0;


  while (outofs < upsize)
  {
   packbyte  = inbuf[inofs];

   inofs++;

   for (bit = 7; bit >= 0; bit--)
   {
     if (getbit(packbyte,bit) > 0)
     {
       b1 = inbuf[inofs];
       inofs++;
       b2 = inbuf[inofs];
       inofs++;

       distance =  (unsigned int) ((b1 & 0xF0) << 4) | b2;
       length =  (unsigned int) (b1 & 0x0F)+3;


       for (i = 0; i <= (length-1); i++)
       {
     outbuf[outofs] = outbuf[(outofs-distance)];
     outofs++;
     if (outofs >= upsize) break;
       }
     }
     else
     {
       outbuf[outofs] = inbuf[inofs];
       inofs++;
       outofs++;
     }
   }
  }
   printf(" Input Offset: %u\n",inofs);
   printf(" Output Offset: %u\n",outofs);


  if (outofs < upsize)
    return 1;
  else
    return 0;
}



int main(int argc, char**argv)
{
 size_t     result;
 unsigned long  ID;


 clrscr();
 printf("TPWM-Entpacker v1.0 by DragonSphere / DosReloaded \n");
 printf("\n");

 if (argc != 2)
 {
  printf("Bitte Namen der zu entpackenden Datei angeben!\n");
  printf("Syntax: UNPACK.EXE <gepackte Datei> \n");
  return 0;
 }

 f = fopen(argv[1],"rb");

 if (!f)
 {
  printf("Fehler! Kann Datei %s",argv[1]);
  printf(" nicht ”ffnen! \n");
  exit(1);
 }

 fseek(f,0,SEEK_END);    
 psize = (ftell(f)-8);   //Größe des Header von der Dateigröße abziehen, um Größe der gepackten Daten zu erhalten
 rewind(f);              //Zurück zum Anfang


 result = fread(&ID,sizeof(ID),1,f);  //ID String lesen
 if (result != 1) ReadingError();

 if (ID != 0x4D575054) //Ist es 'TPWM'?
 {
  printf(" Datei wurde nicht mit Turbo Packer gepackt! \n");
  exit(1);
 }

 result = fread(&upsize,sizeof(upsize),1,f); //Größe der ungepackten Daten lesen
 if (result != 1) ReadingError();

 printf(" Größe gepackt: %u\n",psize);
 printf(" Größe entpackt: %u\n",upsize);
 printf("\n");

 if ((psize > 0xFFFF) || (upsize > 0xFFFF)) //Aktuell können nur max 65535 Byte verarbeitet werden
 {
  printf(" Datei zu groß zum enpacken! \n");
  exit(1);
 }


 inbuf = (char*) malloc(psize+1);
 outbuf = (char*) malloc(upsize+1);

 if ((inbuf == NULL) || (outbuf == NULL))
 {
  printf(" Nicht genug freier Arbeitsspeicher! \n");
  if (inbuf != NULL) free(inbuf);
  if (outbuf != NULL) free(outbuf);
  exit(1);
 }

 memset(inbuf,0,psize+1);
 memset(outbuf,0,upsize+1);

 result = fread(inbuf,1,psize,f);

 if (result != psize) ReadingError();

 fclose(f);
 int presult = Decrunch();

 if (presult == 0)
 {
   free(inbuf);  //Den brauchen wir nun nicht mehr
   printf(" Daten wurden erfolgreich entpackt. \n");
   f = fopen(argv[1],"w+");
   result = fwrite(outbuf,1,upsize,f);
   if (result != upsize)
      printf(" Kann entpackte Daten nicht in Datei schreiben! \n");
   fclose(f);
 }
 else
 {
   printf(" Fehler beim Entpacken! \n");
   free(inbuf);  //Den brauchen wir nun nicht mehr
 }

 free(outbuf);
 return 0;
}

Hilfe könnte ich gut gebrauchen, denn ich rätsel immer noch über die Bedeutung einiger Bytes in den .shp Dateien. Genauer gesagt darüber, wie das Spiel erkennt, welcher Eintrag in der Datei zu welchem Gebäude auf der Karte gehört.

Für alle die mit rätseln wollen, hier mal die (entpackte) 57.shp im Hexeditor. Das ist die Datei für die kleine Zweispielerkarte TROLL.

Wie weiter oben schon geschrieben, werden hier erstmal die in Fabriken produzierbaren Einheiten festgelegt. Und zwar 51 für beide Seiten. Es ist nicht so, wie ich erst angenommen hatte, dass hier Einheiten für die beiden Seiten getrennt definiert werden.

Durch Ausprobieren habe ich hier auch schon die Bedeutung heausbekommen:

Ist das entsprechende Byte auf 0 gesetzt, kann die Einheit gebaut werden, bei 1 steht sie nicht zur Verfügung. Interessant sind die Nummern 30,33,35. Die gibt es nämlich nicht.

Wahrscheinlich waren ursprünglich drei weitere Einheiten geplant (von der Position her wohl Schiffe), die dann aber doch wieder aus dem Spiel entfernt wurden. Tatsächlich stehen also nur 48 Einheiten zur Verfügung, was auch mit dem Handbuch übereinstimmt.

Auf der Karte, also in der .FIN-Datei ist es so, dass es jede Einheit einmal als deutsche und einmal als französische Version gibt. Also Zahlen bis 101 (66h) vergeben werden können. Da ist dann 0 ein deutscher Späpanzer, 1 ein französischer Spähpanzer usw.

Dann kommt Byte 10h in der zweiten Zeile auf dem Bild oben (Offset 33h), das uns sagt, dass im folgenden vier Gebäude für die Karte TROLL definiert sind. Zuerst kommen die beiden Hauptquartiere, wie ich durch Ausprobieren herausbekommen habe. Das deutsche ist mit 00 00 00 0C 2D FF FF FF FF FF FF FF definiert. Das französische mit 01 00 01 0C 2D FF FF FF FF FF FF FF.

Wenn man die Karte spielt und das HQ öffnet, sieht man, dass es 12 Rohstoffe pro Runde einbringt. 0C steht also schon mal für die Rohstoffeinnahmen. Auch können wir annehmen, dass eine 00 bzw. 01 für die Seite steht, der das Gebäude gehört. Also 00 für deutsch, 01 für französisch. Die FF stehen für die 7 Felder für Einheiten im Gebäude, ändert man hier ein FF z.B. auf 32, dann steht beim Start der Karte ein Mark IV Panzer im HQ rum. Aber wofür stehen nur die anderen Bytes? Wenn ich die zweite 01 im Eintrag für das französische HQ auf 00 setzte, bekommt plötzlich die deutsche Seite die Einnahmen aus dem französichen Gebäude und die franz. Einheiten stehen dann auch im deutschen HQ... Bei dem zweiten Byte 00 und dem fünften Byte 2D habe ich aber noch absolut keinen Schimmer, wofür die sind. Erst dachte ich 2D ist vielleicht eine ID für die HQs, aber bei anderen Karten stehen hier teilweise auch andere Zahlen.

Die deutsche Fabrik ist dann mit 00 01 00 34 00 (und natürlich sieben FF) definiert. 34h, also 52, entspricht wieder den Rohstoffeinnahmen für das Gebäude. Das erste Byte 00 für die deutsche Seite passt auch. Aber warum ist das zweite jetzt auf 01 gesetzt?

Bei der französichen Fabrik 01 01 01 34 00, also alles auf 01.... Hier rätsel ich noch sehr über die Bedeutung.

Und bei dieser Karte ist die Zurordnung aber noch simpel. Nur wie läuft die, wenn es z.B. fünf Fabriken und drei Depots auf der Karte gibt.....

Zitat von moravec

wie ist die Nummerierung der SHP Dateien zu verstehen? es gibt 71, bei 24 Karten je D / F / Multiplayer

Die Nummerierung fängt mit 0 an. Also gibt es 72 Karten. Wie du richtig schreibst 24 deutsche, 24 französiche und 24 Multiplayer.

00 .* sind die Dateien für PULSE, 23.* die für STERN und 57.*, wie in meinem Beispiel oben, die für TROLL.

Zitat von Nelson

Eine ganz tolle Sache! HL ist eines meiner Top10 auf dem Amiga. Ein Karteneditor wäre super. Und vielleicht könnte man damit auch gleich was mit fixen.

Ich bin wegen eines Projektes noch gut eingebunden. Danach könnte ich versuchen dir zu helfen.

Das wäre super Das Spiel wurde auch definitiv auf dem Amiga entwickelt und dann auf den PC portiert. Merkt man, nebe den IFF-Grafiken zum Beispiel gut daran, dass die als Word hinterlegten Koordinaten in den FIN-Dateien, in big-endian gespeichert sind. Auf dem PC geänderte Karten sollten sich also auch auf den Amiga übertragen und dort spielen lassen.

Zitat von root_42

Tolle Arbeit! Ich denke an diesen Stellen wird man kaum darum herumkommen das Spiel mal zu disassemblieren und zu kommentieren. Ich glaube wir brauchen da ein "echtes" reverse Engineering.

Hier hoffe ich bisher noch durch Ausprobieren weiter zu kommen.

Heute Abend werde ich mir mal ein kleines Programm schreiben, dass eine leere kleine Karte mit verschiedenen Gebäuden und eine, nach bisherigem Kenntnisstand passende, .shp erstellt.

Und dann kann ich ja mal lustig Bytewerte setzen und gucken, was wo zugeordnet wird und was sich wann verändert.

Ein anderes Problem sind noch die Grafiken. Es wäre ja schön, für den Leveleditor die Geländegrafiken direkt aus den Spieldateien laden zu können.

Das ist nur leider nicht so einfach, wie ich zunächst dachte. Im LIB Unterverzeichnis des Spiels gibt es die Dateien PARTS.DAT und PARTW.DAT sowie PARTS.LIB und PARTW.LIB.

Von den Dateinamen her beinhalten die also wahrscheinlich die Geländegrafiken, in einer Version für Sommer und einer für Winter. Das bestätigt auch der Inhalt der .DAT-Datei nach dem Entpacken.

Hier stehen passende Dateinamen für jedes Geländefeld drin. Die PARTS.DAT beginnt z.B. mit SPLAI152SBUIL000... Feld 00 steht in den FIN Dateien für ein leeres Gras-Feld, dazu passt ja englisch plain und damit auch PLAI im Dateinamen, die Zahlen danach (01 bis 18h) stehen in der FIN für Gebäudegrafiken, hier passt dann auch BUIL und das S für Sommer bzw. Summer. Nur wozu braucht das Spiel die Dateinamen?

In der LIB sind dann also wohl die Grafiken gespeichert. Nach dem Entpacken sieht es auch erst nach vielen IFF-Grafiken hintereinander aus. Nur fehlen leider typischen Chunks. Es gibt nur INFOILBM und ILBM Chunks, kein FORM, kein CMAP o.ä. und auch keinen typischen Header.

Haben wir hier zufällig jemanden im Forum, der oder die sich gut mit Amiga Grafikformaten auskennt und hier weiterhelfen kann?

Sonst brauchen wir hier wirklich noch den Disassembler oder ich löse das über Screenshots und eine eigene Grafikdatei für den Editor. Eine Karte die alle Grafiken hintereinader darstellt, kann ich mir ja schnell basteln....

Zitat von root_42

EDIT: Da HL1914-18 auf Battle Isle basiert, lohnt vielleicht ein Blick in den Quellcode von Crimson Fields. Dort wurde ein Konvertierungstool geschrieben um Battle Isle Maps ins Crimson Fields Format zu bringen:

https://gitlab.com/osgames/cri…blob/master/tools/bi2cf.c

Super Danke! Ich dachte bisher funktionierende Editoren gäbe es nur auf dem Amiga!

Dort habe ich gerade direkt für Gebäude in der shp das hier gefunden:

typedef struct {    
   unsigned char owner;    // owner of buildung/unit [0|1|2]    
   unsigned char type;     // type [0=HQ|1=Factory|2=Depot|3=Unit]    
   unsigned char index;    // xth unit/building of type    
   unsigned char crystals; // number of crystals inside    
   unsigned char unknown;  // probably max capacity of crystals?    
   unsigned char units[7]; // units inside building/unit
} tshpdata;

Bleibt also nur noch ein unbekanntes Byte

Und die Frage nach der Zuordnung... Dafür werde ich dort nochmal etwas stöbern.