![]() |
|
Reverse Engineering der NLT II - 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 II (/showthread.php?tid=5383) |
RE: Reverse Engineering der NLT II - Taktikus - 20.01.2026 @Pergor Da sind wir schon zwei, aber interessant ist es .
RE: Reverse Engineering der NLT II - cmfrydos - 20.01.2026 Ich versuche künftig darauf zu achten, dass man auch ohne große Informatik- oder Programmiererfahrung etwas von meinen Beiträgen hier hat. Ggf. sollte ich die folgenden Posts zum HDViewer auch besser in einen eigenen Thread packen, zumal es größtenteils eher „Re-Engineering Pi mal Daumen“ ist und nur vereinzelt wirklich nah am Original. Ein paar Details zu den Karten-Events konnte ich gestern noch in Erfahrung bringen: Es gibt pro Dungeon eine große Funktion, die direkt die Object-IDs der Eventzonen aus den 3D-Daten nutzt, um bestimmte Codestücke auszuführen. „Auf Gebiet X betrete Gebäude Y“ ist dabei ein Standardmuster, wodurch ich die Zuordnungen automatisiert auslesen konnte. Diese habe ich im Wiki-Artikel zu den Gebäude-IDs festgehalten: https://github.com/shihan42/BrightEyesWiki/wiki/Geb%C3%A4ude%E2%80%90-Objekt%E2%80%90IDs-(Riva) Außerdem ist das inzwischen in den Viewer eingebaut. Zusammen mit Informationen aus den unterschiedlichen LOC…DAT-Dateien in MODULELOCATIO, zum Beispiel verwendete Hintergrund-.BOB-Animation und zugehörige Dialogdatei, kann man im Viewer jetzt alle relevanten Gebäude betreten und den passenden Dialog durchblättern. Die LOC-Daten halte ich demnächst ebenfalls noch im Wiki fest. Es gibt allerdings noch ein paar Zuordnungen, mit denen ich wenig anfangen kann, zum Beispiel Preis- und Qualitätsniveaus der Händler sowie Spezialdaten je nach Tempel. Das wird sich aber vermutlich mit der Zeit noch klären. Kleinere Auffälligkeiten, die mir bei der Kontrolle aufgefallen sind: Yasmir wurde wohl irgendwann in Eran Dorgan umbenannt, ebenso wurde Grimor in Tobias Draht umbenannt. Darauf komme ich nur, weil die .BOB hier einen abweichenden Namen im Vergleich zum Dialognamen trägt. Apropos Namen: Interessant ist auch, dass es mal „Tarikk“ hieß, der Rattenfänger intern „Ratcatcherion“ genannt wurde und der Handelsherr „Datedelsherr“ bezeichnet wurde. Außerdem gab es offenbar einmal ein Gesprächsthema „Elajaerker“. War das vielleicht eine frühe Bezeichnung der „Holberker“? Das wäre allerdings merkwürdig, denn die haben hier ihre eigene Benennung. Ich meine, es gab dazu mal etwas in einem Interview oder so, aber ich kann mich nicht mehr richtig erinnern. Jedenfalls kommt mir der Begriff nicht gänzlich unbekannt vor. Das jedenfalls stammt aus der Riva-Debug-Demo-Rechts-Shift-Konsole zu den Topic-Flags. (siehe Anhang) Als Nächstes schaue ich mir die verschiedenen Kampfzuordnungen an, also erst einmal die „einfachen“ über direkte Kartenplatzierungen beziehungsweise über dortige Zufallskämpfe. Anschließend versuche ich, noch einmal einen Blick auf die Windsbraut zu werfen. Dort gibt es nämlich einen Kampf (K104 der Kampfliste), der zumindest ebenfalls noch in den Exposami-Daten auftaucht, aber bisher nicht ausgemacht werden konnte. Die Exposami-Daten sind mir generell noch ein Rätsel: Die allermeisten Kämpfe tragen Positionsdaten und werden daher beim Wirken des Zaubers auf der Karte eingetragen, aber relativ viele kommen auch ohne Positionsdaten daher. Welchen Zweck diese Einträge dann überhaupt noch haben, ist mir unklar. Zusätzlich werden nur die Kartenzugehörigkeit und die Anzahl der Gegner festgehalten, sowie ob es sich um einen Bosskampf handelt. RE: Reverse Engineering der NLT II - Obi-Wahn - 20.01.2026 Die Videos sehen richtig aus!
RE: HD Viewer – Android Demo & Kampfanimationen - Zurgrimm - 20.01.2026 (19.01.2026, 20:58)Pergor schrieb: Hach, da wird man richtig nostalgisch, wenn man die Riva-Musik mal wieder hört. Gott, ist das lange her.Genau so ging mir das auch. Man bekommt direkt Lust, mal wieder eine Partie zu spielen nach wohl über zwei Jahrzehnten. Aber im Moment ist zu viel anderes los ...Ich verstehe von dem Technischen auch so gut wie nichts. Aber ich freue mich immer, wenn ich lese, dass auf diesem Wege neue Erkenntnisse zutage gefördert werden. RE: Reverse Engineering der NLT II - cmfrydos - 21.01.2026 Hihi, das geht mir genauso. Die Riva-Musik macht einfach sofort was mit einem. Und wenn sie dann auch noch sauber über ein modernes Backend läuft (statt ggf. stotternd in der DOSBox), macht’s gleich doppelt Spaß. ![]() Kurzes Update zu meinen letzten Suchen nach den Kämpfen: Zwar konnte ich einige weitere Eventhandle-Funktionen identifizieren und hatte auch viel Erfolg dabei, anhand verlinkter Texte einige Events (bspw. auf der Windsbraut) zuzuordnen, leider jedoch mit negativem Ergebnis für K104. Dazu hier ein wenig mehr: https://www.crystals-dsa-foren.de/showthread.php?tid=6116&pid=175346#pid175346 Ggf. macht es aber Sinn, die Suche nach dem Muster „Welche Texte werden in welchen Funktionen ausgelöst?“ auszubauen (und zu härten), da man so eine große Menge an Handlungsskript-Funktionen semi-automatisch identifizieren könnte. RE: Reverse Engineering der NLT II - cmfrydos - 29.01.2026 Es gibt Fortschritte bei der Runtime-Kampfengine des HDViewer. Hier eine kurze Demo: Grundlegende Funktionen sind implementiert, es fehlt nur noch an Details: Wie werden die verschiedenen Sounds den Monsteranimationen zugeordnet? Wie genau ist welcher Zauber implementiert? Welches Item bewirkt was? Wie funktionieren die Autokampfregeln der Helden und Monster? Einiges kann man hier im Forum oder in BrightEyes nachlesen, dafür ein riesiges Dankeschön! Trotzdem bleibt noch einiges an Arbeit, um das für Riva zu verifizieren oder zu erweitern. RE: Reverse Engineering der NLT II - llm - 10.02.2026 wo ist denn @HenneNWH geblieben? er war schon eine Weile nicht mehr im Forum oder auf Github aktiv, an was werkelt er denn in seinem geheimen Labor?
RE: HD Viewer – Android Demo & Kampfanimationen - Henne - 11.02.2026 (19.01.2026, 17:40)cmfrydos schrieb: Das UI- und logikverworrene Kampfsystem ist aktuell noch der einzige größere Blocker, ![]() Hab gerade deine Videos angesehen: Spektakulär. Das Kampfsystem der NLT ist tatsächlich nicht ganz ohne und in vielen Punkten Überarbeitenswert. Bei Bright-Eyes sind mir da schon Unstimmigkeiten aufgefallen, die bei BrightEyes noch klarer zu Tage treten. Ist einfach so! Zum Dialogsystem: Das muss in BrightEyes noch angepasst werden. Die Lua-Skripte waren eher Free-Style. BrightEyes ist näher an der Realität, aber (noch) 16-bittig. Das ist eher ein kleineres Kapitel, aber eines von Vielen. Hab in der Zwischenzeit sehr mit RL zu kämpfen, darum ist BrightEyes erstmal pausiert. Den Januar habe ich genutzt um: * über den weiteren Weg nachzudenken, * etwas an ScummVM mitzuentwickeln, * ein paar Entscheidungen zu treffen und * das was ich mache klarer zu definieren (sehr technisch, aber nicht für jedermann zugänglich). Meine ScummVM-Erfahrungen zeigen, dass die Devs für meine Commits zu kritikempfindlich waren. Bin da rausgeflogen, weil zwei Devs aufgrund meiner Gründlichkeit beleidigt waren. Habsch ooch keen Bock druff! Trotzdem ist was Gutes dabei raus gekommen. Die Dinge bleiben in Bewegung, aber es ist an der Zeit ein paar leicht verständliche Videos zum bisherigen Stand zu machen. * Was genau ist Bright-Eyes, BrightEyes, wie und warum möglichst einfach erklärt? * Wie ist der aktuelle Stand? * Wie kann/wird/sollte es weiter gehen? Frage ans Forum: Deutsch, Englisch oder Beides? Der aktuelle Stand ist erstmal vorzeigbar, aber natürlich noch stark Verbesserungswürdig. RE: HD Viewer – Android Demo & Kampfanimationen - llm - 11.02.2026 Willkommen zurück! (11.02.2026, 00:26)HenneNWH schrieb: Meine ScummVM-Erfahrungen zeigen, dass die Devs für meine Commits zu kritikempfindlich waren. hatte gesehen das du ScummVM auf deinem github geforkt hast - und dann war es wieder weg... lass mich raten: dreammaster und sev? ja man muss sich da erstmal adaptieren - wenn man das nicht gewohnt ist und eine feste eigene Meinung hat trifft man dort auf Granit aber bei der Menge an Platformen, Kompilern, Constributors und Commits muss man da auch ein strenges Regiment führen - nur schon der gleichmäßigkeit wegen - egal ob das einzelnen nicht schmeckt aber ich würde behaupten das ihr euch da nicht unähnlich seit ![]() aber sonst sind die devs recht locker Zitat:Frage ans Forum: Deutsch, Englisch oder Beides? Mir würde Deutsch reichen - es gibt ja immer noch die KI Übersetzung bei Youtube
RE: HD Viewer – Android Demo & Kampfanimationen - Henne - 11.02.2026 (11.02.2026, 08:05)llm schrieb: Willkommen zurück! Genau deshalb hab ich es dort mal mit 25 Jahren Praxiserfahrung drauf ankommen lassen. ;-) Die Devs sind Sev-, bluegr und mcduggan. Ich habe bei der Nuvie-Engine (Ultima VI: The false Prophet, Ultima: Savage Empire, Ultima: Martian Dreams) mehrere auftretende Bugs gefunden und einen nicht ganz durchdachten Schnellschuss abgefeuert. Am Tag darauf hab ich kapiert, dass es 3 verschiedene Dinge gibt, welche einzeln behoben werden sollten: * eindeutige Erkennung der verschiedenen Versionen der Spiele anhand der Datenfiles (wurde akzeptiert), * Behebung von Segfaults, welche in meinem realistischen Szenario aufgetreten sind (abgelehnt, wegen Kritikempfindlichkeit), * Erkennung und Behandlung des tatsächlichen Fehlers bei nicht vorhandener Datei zur Laufzeit (hab ich dann nicht mehr eingereicht). Die eindeutige Erkennung war trickreich, da bei der Installation, je nach Auswahl des Grafikadapters und anderer Optionen, die Spieledaten verändert werden. Das hab ich der ScummVM beigebracht, da sie das nicht Leisten kann. EDIT: Bei Schweif ist das imho auch so, dass man zwischen 3 verschiedenen Installationen wählen kann. Die Behebung der Segfaults (Low-Level) war nach mehrmaligen Coding-Style Schikanen durch bluegr auch zu meiner Zufriedenheit. Das habe ich ihn wissen lassen. Ist ja nicht mein Projekt. ;-) Man drängte mich dazu nur den dritten Punkt zu verfolgen, was ich aufgrund meiner Gründlichkeit nicht akzeptieren konnte. Ich habe mit schlechtem Stil argumentiert, mir wurde Drama und Respektlosigkeit von bluegr und Sev- seitens mcduggan vorgeworfen: Unfassbar! Und ja, dass ich dort nicht weitermache haben die Devs verbockt. Und ja, in welcher Reihenfolge ich meine Lösungen anbiete entscheide ich. Immerhin habe ich es mal versucht und mit verschiedenen Pull-Requests gearbeitet, was sich bei diesen verschiedenen 3 Problematiken als gut erwiesen hat. ScummVM-Integration von Bright-Eyes halte ich für unrealistisch. Die Story hat etwas mit der von euch vorgeschlagenen Grammatik-Implementiertung in BrightEyes gemeinsam. ;-) Meinen Schnellschuss 1 PR habe ich wieder entfernt und erstmal zwei daraus gemacht. Ich kritisiere mich immerhin selbst und diese Eigenschaft kommt BrightEyes und letztendlich auch den Nutzern zugute. Die CMake-Debatte wird dort auch geführt [RFC] CMake build system #7087: Man ist der Auffassung, dass es gut ist wie es ist, da die verschiedenen Plattformen/Compiler und anschließende Build-Tests sich so etabliert haben. Das sehe ich genauso. Ein Wechsel auf CMake wäre bei ScummVM ein Schritt zur Seite. Die Komplexität des ScummVM Build-Systems ist enorm und existiert seit 2001. Nur um sagen zu können "Wir nehmen jetzt auch CMake!" wäre dort sehr viel Arbeit und Umstellungbereitschaft seitens der Entwickler notwendig. ;-) (11.02.2026, 08:05)llm schrieb:Zitat:Frage ans Forum: Deutsch, Englisch oder Beides?Mir würde Deutsch reichen - es gibt ja immer noch die KI Übersetzung bei Youtube
RE: HD Viewer – Android Demo & Kampfanimationen - llm - 11.02.2026 (11.02.2026, 11:09)HenneNWH schrieb: Ich habe mit schlechtem Stil argumentiert, mir wurde Drama und Respektlosigkeit von bluegr und Sev- seitens mcduggan vorgeworfen: Unfassbar! speziell die Kernleute von ScummVM haben schon über jahrzehnte viel Müll und übermäßig Drama erlebt und die Regel lautet erstmal: -Strenge Kontrolle -Mach was wir sagen -Adaptiere unseren Stil -Langsam warm werden -<=0 Drama egal woher das hält bei denen die 5 neuen Müll-Entwickler aus dem Projekt raus die da pro Woche antanzen die haben sehr grossen Rookie-Andrang die dann erst aufwändig betreut werden und dann nie mehr wieder kommen wäre bei dir nicht anders wenn jede Woche 5 neue Entwickler Pull-Request bei BrightEyes einstellen wollen - dir reichen ja schon meine Pulls und Fragen ![]() btw: https://github.com/Henne/BrightEyes/pull/56 https://github.com/Henne/BrightEyes/pull/58 sind schon ordentlich abgehangen, geradezu vertrocknet... RE: Reverse Engineering der NLT II - Crystal - 11.02.2026 --- Kurze Zwischeninfo --- Henne hat mich gebeten, seinen Account-Namen von "HenneNWH" auf "Henne" abzuändern. Bitte künftig drauf achten, neuer Acc ist ab sofort aktiv. Weiter im Text... RE: Reverse Engineering der NLT II - Henne - 11.02.2026 Das kann ich verstehen, aber ich programmier schon sehr lange und habe meine ersten Erfahrungen ca. 2005 am Linux-Kernel gemacht. Daher auch der Coding-Style von BrightEyes. Mir geht nur mittlerweile dieser ungesunde elitär-autoritäre Kommunikationsstil auf den S**K, mit dem (nicht nur) dort kommuniziert wurde. Du wirst verstehen, nachdem du gesehen hast was hier so abgeht, dass respektvoller klarer Kommunikationsstil auf Augenhöhe die Motivation fördert, auch wenn jeder anders tickt und anders arbeitet. cmfrydos hat jetzt auch wieder Bock bekommen! Find ich gut. Und was da wirklich dahintersteht, sehen die Wenigsten. ScummVM ist ja im Vergleich zu BrightEyes sehr populär. Vielleicht sollte ich mich im Nachgang noch einmal vorstellen und mehr auf die Gemeinsamkeiten dieser beiden Projekte eingehen. Das Drama kam imho eher von dort. Ich hab es allerdings offen angesprochen und mir damit deren Unmut zugezogen. Das konnten sie ja nicht wissen. P.S.: Immer nur genau eine Frage pro Woche. ;-) RE: Reverse Engineering der NLT II - Obi-Wahn - 11.02.2026 Willkommen zurück und alles Gute fürs RL! RE: Reverse Engineering der NLT II - Taktikus - 12.02.2026 Von mir auch alles Gute fürs RL und: Deutsch bitte (danke) |