Reverse Engineering der NLT - Druckversion +- Crystals-DSA-Foren (https://www.crystals-dsa-foren.de) +-- Forum: Allgemeines zur Nordlandtrilogie DOS (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=20) +--- Forum: Technische Werkstatt (https://www.crystals-dsa-foren.de/forumdisplay.php?fid=34) +--- Thema: Reverse Engineering der NLT (/showthread.php?tid=700) |
RE: Reverse Engineering der NLT - Obi-Wahn - 02.01.2017 (01.01.2017, 20:35)Wetzer schrieb: Mh. Die Größe der Zip-Datei vom 24.12.16 scheint, was ihre Größe betrifft, etwas aus der Reihe zu fallen. Ist mir nur so aufgefallen. Leichte Schwankungen von 200KB würde ich jetzt noch nicht auffällig nennen. Normalerweise erstelle ich die ZIP-Dateien mit WinRar, am 24.12. mit der Standard-Kompression von Windows 10. Daher kommt der Unterschied, wie ich gerade ausprobiert habe. Ansonsten ist aber schön zu sehen, wie die ZIP-Dateien, bzw. die enthaltende dosbox.exe, immer größer werden. RE: Reverse Engineering der NLT - gaor - 04.01.2017 Es gibt ja das Tool nltpack, mit dem die Dateien in der SCHICK.DAT entpackt werden können. Gibt es auch ein Tool, mit dem man die Dialog- und Text-Dateien (TLK bzw. DTX/LTX) effizient auslesen kann? Die Text-Dateien scheinen ja lediglich NULL-separierte Strings zu enthalten. Trotzdem wäre es gut, schnell zwischen denen springen zu können, etwa: Zeige den 45ten String in der Datei TEXT.LTX! So wird nämlich auch im Code darauf zugegriffen. Die Dialog-Dateien enthalten nach einem kurzen Header auch wieder nur NULL-separierte Strings. Hier wäre es aber noch viel wichtiger, im Sinne der Dialog-Logik des Spiels zugreifen zu können. Ganz rudimentär habe ich mir beides momentan als Shell-Scripte erstellt. Wenn noch Bedarf an solchen Tools existiert, dann könnte ich die Scripte etwas einfacher bedienbar gestalten und der Allgemeinheit zur Verfügung stellen. RE: Reverse Engineering der NLT - Rabenaas - 08.01.2017 Ich habe mal das hier aus seg073.cpp extrahiert. Code: 0x3da2 CAMP_BREIDA_SERSKE_1 RE: Reverse Engineering der NLT - gaor - 08.01.2017 (08.01.2017, 17:10)Rabenaas schrieb: Ich habe mal das hier aus seg073.cpp extrahiert.Oh, daran habe ich die letzten Tage gearbeitet und werde dazu demnächst einen Pull Request machen. Wir müssen mal gucken, wie wir das dann machen. Wichtig: Die Einträge in symbols.h habe ich in den vergangenen Tagen fast komplett vervollständigt! Bitte nicht daran arbeiten, bevor ich nicht den Pull Request gemacht habe (für heute Abend geplant). RE: Reverse Engineering der NLT - Rabenaas - 08.01.2017 Schau doch bei Gelegenheit einfach, ob wir zu dem gleichen Ergebnis kommen. RE: Reverse Engineering der NLT - gaor - 08.01.2017 So, hier ist mein angekündigter Pull Request: https://github.com/Henne/Bright-Eyes/pull/32 Alle übrigen "magic numbers" (sind nur noch etwa 50) könnt ihr jetzt gerne studieren. Ich beschäftige mich in nächster Zeit erstmal nicht mehr direkt damit. @Rabenaas: Hier meine Version des entsprechenden Abschnitts: Code: #define TEVENT004_FLAG (0x3da2) /* unsigned char {0,1} */ Ich sehe, dass du in deinen Variablennamen die Reiseroute eingeflochten hast, auf der das jeweilige Reiseereignis auftritt. Die Zuordnung der Reiseereignisnummern zur Route, auf der das Ereignis eintritt, ist wirklich eine Interessante Information, die im Wiki bestimmt gut aufgehoben wäre. Im Spiel ist diese Information intern in TEVENTS_TAB, gespeichert. Das ist ein Array von Structs der Form (route_id, place, tevent_id). Eine Route kann man mit ihrer route_id in ROUTES_TAB nachschlagen. Dort steht dann, von wo nach wo die Route geht usw. RE: Reverse Engineering der NLT - gaor - 08.01.2017 Was jetzt echt cool wäre, wäre ein tiefgehenderes Verständnis des Grafik-Renderings und der Animationen im Kampf. Bis jetzt hat zum Beispiel noch niemand das Struct FIG_LIST_ELEM (bzw. die Einträge in der Liste, auf die FIGHT_LIST_HEAD zeigt) irgendwo verständlich dokumentiert. Hier sind meine bisherigen Erkenntnisse: Code: enum { Außerdem werden immer mal irgendwelche Paletten nachgeladen. Da wäre es natürlich gut, eine Übersicht zu haben, welche Palette da genau welchen Zweck erfüllt. Ein anderer Datentyp sind die Structs in 0xd8ce (habe den Namen FIGHTANI_SHEETS vorgeschlagen), die irgendwie mit den Animationen zusammenhängen. Und die Einträge des Arrays in 0xbd6e sind für mich weiterhin total rätselhaft (siehe auch seg075.cpp). Abgesehen davon bin ich immer noch voller Hochachtung für Henne, der hier echt eine wahnsinnige Arbeit geleistet hat. Ich bin schwer beeindruckt. Vielen Dank nochmal! RE: Reverse Engineering der NLT - Rabenaas - 09.01.2017 (08.01.2017, 20:14)gaor schrieb: Ich sehe, dass du in deinen Variablennamen die Reiseroute eingeflochten hast, auf der das jeweilige Reiseereignis auftritt. Die Zuordnung der Reiseereignisnummern zur Route, auf der das Ereignis eintritt, ist wirklich eine Interessante Information, die im Wiki bestimmt gut aufgehoben wäre.Noch interessanter ist, finde ich, die Art des Events. Es handelt sich um Rastplätze. Ob das in den Namen, als Kommentar in den Header oder das Wiki kommt, kann ja noch später geschaut werden. RE: Reverse Engineering der NLT - gaor - 09.01.2017 Ja, genau. Bei den Events gibt's oft auch kurze Dialoge. Im Wiki könnte man wunderbar eine Liste aller Reiseereignisse einrichten und zu jedem angeben, wo es stattfindet, was die interne Bezeichnung ist (Nummerierung) und was genau da passiert (spezieller Rastplatz usw.). Bin momentan mit anderen Dingen beschäftigt, deswegen lasse ich es jetzt erstmal bei diesem "könnte" ;-) RE: Reverse Engineering der NLT - Rabenaas - 09.01.2017 Ich habe kein Problem damit, das ins Wiki zu schreiben, wenn es jemand da haben möchte. Im Sourcecode wäre es allerdings bequemer erreichbar imo. RE: Reverse Engineering der NLT - gaor - 13.01.2017 Ja, da hast du Recht. Wie wäre es, wenn man die Information in einen Kommentarbereich vor den travel event handlers einbaut? Etwa so: Code: /* Handler for a travel event between Breida and Serske (hunting opportunity). */ Siehst du, ich will die Information über das Reiseereignis nicht in den Variablennamen hineinschreiben, weil ich möchte, dass der Variablenname die Variable selbst beschreibt und nicht das Reiseereignis, bei dem die Variable auftaucht. Ich behaupte nicht, dass ich schon die optimale Nomenklatur für die globalen Variablen gefunden habe. Ich glaube sogar, dass viele der aktuell gewählten Namen in symbols.h ungünstig gewählt sind. Aber die Route, die zu einem Reiseereignis gehört, sowie die Art des Reiseereignisses in den Namen der "visited flag" der Reisevariable zu schreiben, empfinde ich als irritierend. Die Rastplätze, die du aus seg073.cpp extrahiert hast, sind übrigens nicht allesamt Rastplätze im gleichen Sinne. An manchen Plätzen wird man nur gefragt, ob man die Gelegenheit für eine Jagd oder fürs Kräuter sammeln nutzen möchte. RE: Reverse Engineering der NLT - Wetzer - 13.01.2017 (13.01.2017, 11:30)gaor schrieb: Ja, da hast du Recht. Wie wäre es, wenn man die Information in einen Kommentarbereich vor den travel event handlers einbaut? Etwa so: Da das ganze Projekt ja der Dokumentation des Quellcodes dient, wäre es auch an der Zeit, über Einsatz von Doxygen nachzudenken. Was haltet ihr davon? RE: Reverse Engineering der NLT - Rabenaas - 13.01.2017 Ich bin klar dafür. RE: Reverse Engineering der NLT - gaor - 13.01.2017 Ja, also auf jeden Fall. Das ist längst angedacht. Bei einzelnen Funktionen hat Henne auch schon entsprechende docstrings eingefügt. Für den obigen Fall der Reiseereignisse würde das ja im Wesentlichen bedeuten, noch ein \brief vor die Beschreibung zu setzen. Nachtrag: Seite November 2014 gibt es eine Doxygen-Datei unter https://github.com/Henne/Bright-Eyes/blob/bright_eyes/src/custom/schick/rewrite_m302de/doc/Doxyfile RE: Reverse Engineering der NLT - gaor - 20.01.2017 Wenn man den Quellcode von Bright-Eyes verstehen will, hilft es ungemein, wenn man schnellen Zugriff auf Dateien in der SCHICK.DAT und auf die Startwerte der globalen Variablen in der SCHICKM.EXE hat. Deswegen habe ich mir in den letzten Tagen dieses Tool zusammengeschustert: https://github.com/tuxor1337/schick-data-gui Hier zwei Screenshots (noch unbekannt Variablen in der SCHICKM.EXE sind farbig markiert; die Farben der Dateien in der SCHICK.DAT sollen den Datentyp anzeigen): Mangels einer Windows-Installation konnte ich das Tool bisher nur unter Linux testen. Weil die grafische Oberfläche auf Tkinter basiert, sollte es aber eigentlich auch unter Windows lauffähig sein, solange Python 3.x (mit tkinter, numpy und pillow) installiert ist. Ich kann aber nichts versprechen. RE: Reverse Engineering der NLT - Shihan - 21.01.2017 Das sieht doch schick aus (pun intended) Habe es mal auf Windows getestet (Win10-64, Python 3.6.0). Dabei kommt folgendes raus: Code: D:\schick-data-gui-master>py schick-data-gui.py Leider habe ich gerade überhaupt keine Zeit, sonst würde ich mir Deinen Python-Code mal ansehen. Aber vielleicht kannst Du da schon was zu sagen. Nutze übrigens die aktuellste GOG-Version von Schick. Wahrscheinlich liegt es daran, oder? RE: Reverse Engineering der NLT - gaor - 21.01.2017 Vielen Dank fürs Testen! Tut mir Leid, ich bin vielleicht ein Kamel... folgendes Problem: Das vorgestellte Programm braucht die von mir aktualisierte Datei symbols.h, aber der Pull Request ist ja noch gar nicht im Bright-Eyes-Repository drin: https://github.com/Henne/Bright-Eyes/pull/34 Das hier ist die symbols.h, die gebraucht wird: https://raw.githubusercontent.com/tuxor1337/Bright-Eyes/bright_eyes/src/custom/schick/rewrite_m302de/symbols.h Sobald Henne den pull request akzeptiert hat, stimmt dann auch die Anleitung in der README Achso und zur GOG-Version: Ist die Englisch? Dann wird es sicher Probleme geben - aber das vorgestellte Tool sollte in jedem Fall funktionieren. Es zeigt dann eben nur falsche Daten an, weil die Offsets in der `symbols.h` nicht stimmen. RE: Reverse Engineering der NLT - Shihan - 21.01.2017 Danke, mit der neuen Symbols-Datei geht's wunderbar Sieht so aus: (Nicht über die Qualität wundern, habe es runterskaliert; meine Auflösung liegt bei 2736x1824, da wäre das Original zu groß gewesen; Qualität im Original ist top). Die GOG-Version gibt's auch auf Deutsch, daher klappt das Einlesen gut. Danke für das Tool! RE: Reverse Engineering der NLT - gaor - 21.01.2017 Top, du bist aber auch ein dankbarer Tester! Du hattest entweder schon numpy installiert oder du bist selbst auf die Idee gekommen, es zu installieren. Ich hatte nämlich ganz vergessen numpy als Abhängigkeit anzugeben. RE: Reverse Engineering der NLT - Obi-Wahn - 21.01.2017 Sieht toll aus! |