17.04.2021, 15:43
(Dieser Beitrag wurde zuletzt bearbeitet: 17.04.2021, 16:03 von siebenstreich.)
Sehr schnelle Rückmeldung, wow!
Ja, in dieser Richtung. Mir schwebt folgendes vor:
Die originale SCHICK.DAT muss sich jeder selber an einer vordefinierten Position im BrightEyes-Verzeichnisbaum ablegen (klar, wegen Copyright) und dann einmalig ein Skript starten, das daraus die Einzelteile (wie z.B. TEXT.LTX) generiert und wieder an einer gewissen Position ablegt. Also von der Logik her recht ähnlich zum einmaligen Erstellen der Binär-Segmente, wofür die schick.exe abgelegt wird und dann per Skript der disassembler drübergeht.
Daneben gibt es dann noch Bearbeitungskopien aller in SCHICK.DAT enthaltenen Dateien, z.B. von TEXT.LTX, die natürlich nur lokal existieren (Copyright). In git werden nur Diff-Dateien verwaltet. Bei einem 'git pull' werden diese Bearbeitungskopien automatisch aus der lokalen Originaldatei + diff-Datei aus git erstellt. Bei 'git commit' werden die Diff-Dateien automatisch aus Bearbeitungskopie vs. Originaldatei erstellt und dann diese commitet.
Bei jedem Aufruf von 'make' sollte dann neben dem binary auch die dazu passende SCHICK.DAT erzeugt werden, d.h. die Bearbeitungskopien der Teile werden zu einer SCHICK.DAT zusammengebaut.
Jetzt ist noch die Frage, wo die Abhängigkeit von Präprozessor-Flags eingebracht werden kann. Das hatte ich mir zuvor zu einfach vorgestellt, glaube ich.
Hierzu fällt mir noch folgendes ein, was aber durchaus mit einigem Aufwand verbunden wäre: Man bräuchte -- zumindest für bestimmte Dateiformate wie LTX -- noch eine weitere Ebene, nämlich ein besser vom Menschen les- und bearbeitbares Dateiformat, z.B. was XML-artiges. Eine Grundform dieser Datei (auf die dann die diff-Dateien aufsetzen) -- nennen wir sie TEXT.LTX.xml -- muss sich per Skript aus TEXT.TLX erzeugen lassen und auch umgekehrt muss TEXT.LTX sich wieder per Skript aus TEXT.LTX.xml produzieren lassen. TEXT.LTX.xml bildet jetzt die lokale Bearbeitungskopie; die von git verwalteten Diff's setzen auf dieser Datei auf. Darin kann man jetzt bequem alles mögliche mit unterbringen, z.B. Kommentare, Abhängigkeiten von gewissen (Präprozessor-)Flags, oder zu jeder Textstelle auch einen zugehörigen Konstanten-Bezeichner, auf den der Quellcode dann Bezug nimmt (im Stil von get_tx(TX_ITEM_NAME_SWORD) anstelle von get_tx(23)). Die zugehörigen Definitionen "enum { ... TX_ITEM_NAME_SWORD = 23 ...};" müssten dann vor dem Compilieren automatisch aus der Datei TEXT.LTX.xml erzeugt werden.
Aber das ist nur das, was ich mir so zurechtgelegt habe. Vielleicht ist es aber auch unnötig kompliziert. Denkst du, dass das Vorgehen vernünftig ist, hast du andere Vorschläge?
Mir geht es erstmal um die Text-Inhalte (Rechtschreibfehler, etc.), und darum, dass manche ID's von Gasthäusern im Original durcheinandergeraten sind (es gibt Gasthäuser in unterschiedlichen Orten mit derselben ID). Oder z.B. darum, dass es möglich ist den fahrenden Händler Kolberg in einem Haus in Clanegh anzusiedeln, so wie es im Patch von NRS auch passiert. Oder um den entgleisten Pixel bei den Hunden.
Vielleicht wäre es ein Anfang, sich erstmal auf ein sehr gut verstandenes Dateiformat wie .LTX zu konzentrieren.
Bei der technischen Umsetzung fühle ich mich unsicher. Für das Zerlegen und Zusammenbauen der Einzelteile gibt es wohl von euch schon passenden Code (nltpack). Dann die Frage, womit führt man das Patchen am besten durch, ist das standard diff-patch Paar dafür geeignet? Das ganze muss dann in das Makefile eingearbeitet werden und die ganzen für die Automatisierung nötigen Skripte erstellt werden usw.
(17.04.2021, 12:07)gaor schrieb: Ich verstehe noch nicht, wann du genau die SCHICK.DAT patchen bzw. was genau du tun willst. Willst du ein Tool programmieren, das die SCHICK.DAT modifiziert (und ein Backup des Originals anlegt)?
Ja, in dieser Richtung. Mir schwebt folgendes vor:
Die originale SCHICK.DAT muss sich jeder selber an einer vordefinierten Position im BrightEyes-Verzeichnisbaum ablegen (klar, wegen Copyright) und dann einmalig ein Skript starten, das daraus die Einzelteile (wie z.B. TEXT.LTX) generiert und wieder an einer gewissen Position ablegt. Also von der Logik her recht ähnlich zum einmaligen Erstellen der Binär-Segmente, wofür die schick.exe abgelegt wird und dann per Skript der disassembler drübergeht.
Daneben gibt es dann noch Bearbeitungskopien aller in SCHICK.DAT enthaltenen Dateien, z.B. von TEXT.LTX, die natürlich nur lokal existieren (Copyright). In git werden nur Diff-Dateien verwaltet. Bei einem 'git pull' werden diese Bearbeitungskopien automatisch aus der lokalen Originaldatei + diff-Datei aus git erstellt. Bei 'git commit' werden die Diff-Dateien automatisch aus Bearbeitungskopie vs. Originaldatei erstellt und dann diese commitet.
Bei jedem Aufruf von 'make' sollte dann neben dem binary auch die dazu passende SCHICK.DAT erzeugt werden, d.h. die Bearbeitungskopien der Teile werden zu einer SCHICK.DAT zusammengebaut.
Jetzt ist noch die Frage, wo die Abhängigkeit von Präprozessor-Flags eingebracht werden kann. Das hatte ich mir zuvor zu einfach vorgestellt, glaube ich.
Hierzu fällt mir noch folgendes ein, was aber durchaus mit einigem Aufwand verbunden wäre: Man bräuchte -- zumindest für bestimmte Dateiformate wie LTX -- noch eine weitere Ebene, nämlich ein besser vom Menschen les- und bearbeitbares Dateiformat, z.B. was XML-artiges. Eine Grundform dieser Datei (auf die dann die diff-Dateien aufsetzen) -- nennen wir sie TEXT.LTX.xml -- muss sich per Skript aus TEXT.TLX erzeugen lassen und auch umgekehrt muss TEXT.LTX sich wieder per Skript aus TEXT.LTX.xml produzieren lassen. TEXT.LTX.xml bildet jetzt die lokale Bearbeitungskopie; die von git verwalteten Diff's setzen auf dieser Datei auf. Darin kann man jetzt bequem alles mögliche mit unterbringen, z.B. Kommentare, Abhängigkeiten von gewissen (Präprozessor-)Flags, oder zu jeder Textstelle auch einen zugehörigen Konstanten-Bezeichner, auf den der Quellcode dann Bezug nimmt (im Stil von get_tx(TX_ITEM_NAME_SWORD) anstelle von get_tx(23)). Die zugehörigen Definitionen "enum { ... TX_ITEM_NAME_SWORD = 23 ...};" müssten dann vor dem Compilieren automatisch aus der Datei TEXT.LTX.xml erzeugt werden.
Aber das ist nur das, was ich mir so zurechtgelegt habe. Vielleicht ist es aber auch unnötig kompliziert. Denkst du, dass das Vorgehen vernünftig ist, hast du andere Vorschläge?
(17.04.2021, 12:07)gaor schrieb: Vielleicht könntest du erstmal damit anfangen, in irgendeiner Art von Dokument alle Bestandteile der SCHICK.DAT zu sammeln, von denen dir bereits bekannt ist, dass sie Bugs verursachen und für einen Bug-Fix verändert werden müssten. Darauf aufbauend kann man besser beurteilen, welche Herangehensweise am effizientesten ist.
Mir geht es erstmal um die Text-Inhalte (Rechtschreibfehler, etc.), und darum, dass manche ID's von Gasthäusern im Original durcheinandergeraten sind (es gibt Gasthäuser in unterschiedlichen Orten mit derselben ID). Oder z.B. darum, dass es möglich ist den fahrenden Händler Kolberg in einem Haus in Clanegh anzusiedeln, so wie es im Patch von NRS auch passiert. Oder um den entgleisten Pixel bei den Hunden.
Vielleicht wäre es ein Anfang, sich erstmal auf ein sehr gut verstandenes Dateiformat wie .LTX zu konzentrieren.
Bei der technischen Umsetzung fühle ich mich unsicher. Für das Zerlegen und Zusammenbauen der Einzelteile gibt es wohl von euch schon passenden Code (nltpack). Dann die Frage, womit führt man das Patchen am besten durch, ist das standard diff-patch Paar dafür geeignet? Das ganze muss dann in das Makefile eingearbeitet werden und die ganzen für die Automatisierung nötigen Skripte erstellt werden usw.