Mir ist heute eine Idee gekommen, wie man die Grafik des Spiels aufhübschen könnte:
Man programmiert einen besseren Renderer (mit einem 3-Daten-Wrapper) und legt diesen über das alte Renderfenster (nur den 3D-View) und dupliziert die Bewegungen der Cursortasten.
Drückt man die "nach vorn"-Taste, macht das originale Spiel in der alten Engine einen Schritt nach vorn und gleichzeitig wird in der neuen Engine ein Schritt nach vorn gemacht. Dieses neue Bild liegt über dem alten.
Vielleicht kann man auch von irgenwo Positionsdaten aus dem Spiel bekommen, dann ist die Synchronisation zwischen neuer und alter Engine wohl stabiler.
Verückte Idee, oder? Ist mir heute im Stau eingefallen...
kurzer Einschub: tatsächlich ist die Kampfbeute einzig und allein in der FIGHT.LST gespeichert, und das scheint bei allen drei Teilen so zu sein. Doch die Struktur der Beute ist anders als in der Wiki angegeben: Es ist nämlich nicht Gegenstands-ID, Anzahl, sondern nur der Gegenstand-Hexcode und dahinter jeweils 00, vielleicht handelt es sich hier um das zweite Byte des jeweiligen Gegenstandes, der ja immer 00 oder 01 ist. Darauf hätte ich wohl auch so kommen können, da in der Kampfbeute immer jeder Gegenstand einzeln angezeigt wird. Jedenfalls habe ich mir einen Kampf gesucht, der bestimmt implementiert ist und klar zuzuordnen ist, hierzu boten sich die Daspota-Kämpfe an, änderte die Beute, integrierte die Daten ins Spiel und löste den Kampf aus (hier ist es mal ganz gut, dass die Giftwirkung so groß ist, weil ich den Kampf mit Stufe 1 schnell gewinnen wollte). Und ich bekam tatsächlich die von mir eingegebene Beute angeboten, dieser Teil in Sachen Modifikation dürfte also auch erfolgreich abgeschlossen sein.
Ist es in Ordnung, wenn ich die Wiki dahingehend ändere?
Natürlich, was sollte dagegen sprechen?
Die Daten in der Tabelle sind auch nicht überprüft. Also wenn du möchtest kannst du den Rest auch verifizieren.
Ich bekomme auch schon wieder richtig lust mitzumachen
Vielleicht werd ich nachher mal die ganzen Dats von Riva dokumentieren. Vieles scheint sehr ähnlich zu sein wie bei Schweif.
Gut, dann werde ich das bald ändern. Jetzt habe ich bei dem Ottaskin-Kampf ein bisschen rumgespielt. Ihr wisst ja, dass dort angeblich ein Runenknochen zu erbeuten sein soll. Dieser Code wird vom Programm aber ignoriert und deshalb einfach ausgelassen. Außerdem muss das Byte, das zwischen den einzelnen Gegenständen steht, immer 00 sein. Außerdem beginnt die Auflistung der Beutestücke nicht bei 150, sondern erst bei 152, denn der erste angegebene Beutegegenstand erschien nicht. Ansonsten erschienen immer die Gegenstände, die ich eingegeben habe. Gegenstände, die als zweites byte eine 01 haben, werden nicht erkannt und können nicht eingestellt werden. (z. B. Das Orkdokument)
(29.05.2014, 15:06)Lippens die Ente schrieb: [ -> ]Jetzt habe ich bei dem Ottaskin-Kampf ein bisschen rumgespielt. Ihr wisst ja, dass dort angeblich ein Runenknochen zu erbeuten sein soll. Dieser Code wird vom Programm aber ignoriert und deshalb einfach ausgelassen.
Der Runenknochen ist in der Diskettenversion da, in der CD-Version nicht.
Aber irgendwie muss er den Runenknochen in der Truhe von Gorah doch auch erkennen. Ich frage mich, wie das funktioniert. Vielleicht ist der Hex-Code ja auch falsch, mal sehen.
Schon wieder was entdeckt, um die Kämpfe schwerer zu machen: da ich gerade bei der Kampfbeute war, habe ich mir gedacht, prüfst du das andere auch gleich, und tatsächlich: ich kann mir jetzt jeden Gegner, den ich haben will, in jeden beliebigen Kampf holen, den ich will. Sogar die nicht implementierten Gegner können so auftauchen. Und auch wer wann nachrückt, kann eingestellt werden. Ich habe in Schick soeben Waldschrat, Säbelzahntiger und Co nach Thorwal in die Ottaskin geholt, zum Testen, und es funktioniert. Lindwurm und Höhlendrache sind nicht mit Bild implementiert, da erscheint das Bild eines Frauengeiers. Es ist nur schwer, die Startkoordinaten richtig zu treffen. Wenn zwei Gegner auf dem selben Feld starten, stehen sie quasi übereinander. Aber das Programm hängt sich nicht auf, sobald der erste sich bewegt, wird der zweite sichtbar. Also ein Traum für Modding! Na dann, auf zur Neugestaltung der NLT-Kämpfe
(28.05.2014, 21:02)Wetzer schrieb: [ -> ]Mir ist heute eine Idee gekommen, wie man die Grafik des Spiels aufhübschen könnte:
Das ist irgendwie das Gegenteil des Bright-Eyes-Ansatzes. Das Programm wird nicht Stück für Stück ersetzt, sondern ein anderes wird Stück für Stück drübergestülpt.
(29.05.2014, 18:57)Rabenaas schrieb: [ -> ] Das ist irgendwie das Gegenteil des Bright-Eyes-Ansatzes. Das Programm wird nicht Stück für Stück ersetzt, sondern ein anderes wird Stück für Stück drübergestülpt.
Ist der "Thumbs Up" ironisch gemeint?
Hennes Arbeit ist ultra wichtig für uns alle, egal welchen Ansatz wir für die weitere "Verwendung" der Ergebnisse wählen.
Ich denke, das ist der einzige Weg schon mit ein paar Verbesserungen für das Spiel einzubringen, die über ein paar Bit-Schubsereien hinausgehen, bevor der Source-Code vollständig bekannt ist und dieser dann in eine aktuelle Sprache portiert wurde.
Im Prinzip sind das dann schon Proof of Concepts, die dann in den zukünftigen, portierten Source-Code übernommen werden können (zum Beispiel als Fork oder Mod).
@HenneHW, Rabenaas, Wetzer:
Danke für die Hinweise bezgl. DPMI und passender Dokumentation. Ich denke, dass ich erstmal mit Hex Editor und meinem selbstgeschriebenen Analyseprogramm (die Idee dazu hatte ich vor einiger Zeit, als ich das Savegame-Format von Ascendancy, wer's kennt, rev-engineered habe
) weitermache. Sobald die Formate entziffert sind, kann man sich immer noch Gedanken machen, wie man damit weitermacht.
@Wetzer:
Ich denke, Rabenaas war überhaupt nicht ironisch! Ich finde den Ansatz auch interessant, allerdings ist die Synchronisation wahrscheinlich die Hölle. Muss dann auch in einer speziellen Riva-DOSBOX gemacht werden, damit man auf die Render-Surface Zugriff bekommt. Erst die Dosbox draufzeichnen lassen, dann den OpenGL-Renderer drüber legen (OGL geht mit SDL ja problemfrei). Aber dafür müsste man zumindest Teile der RIVA.EXE disassemblieren, was wohl der härteste Teil werden wird.
@Helios:
Super, die DAT-Files zu entschlüsseln ist auch ein sehr wichtiger Schritt.
Insgesamt frage ich mich, ob das Disassemblieren und in eine BrightEyes-Dosbox verlegen des DPMI-Codes von Riva noch einfacher ist als die Formate zu reverse engineeren und dann ein losgelöstes Remake zu implementieren. Eventuell ist es einfacher, grundlegende Mechanismen wie Kampf, Talentproben, Helden-Management aus BrightEyes zu entnehmen und den Rest drumherum aufzubauen.
Aber ich denke in der Richtung erst weiter, wenn ich mehr Infos zu den Dateiformaten gewonnen habe
Bin übrigens gerade dabei, das Vertexformat zu identifizieren. Scheint kein IEEE754 zu sein. Also doch Integer. Pfui. Immerhin ist mir nun klar geworden, wo in einem Objekt-Block bestimmt wird, welche Textur verwendet wird.
(29.05.2014, 21:52)Wetzer schrieb: [ -> ]Ist der "Thumbs Up" ironisch gemeint?
Daumen hoch, weil ich die Idee originell finde, nicht unbedingt leicht praktisch umsetzbar.
Übrigens liefen Festkommaformate bis 486 potentiell schneller als Fließkomma. Das änderte sich erst mit den Pentiums.
Übrigens ist die Engine von Riva, wie Borbaradwurm herausgefunden hat, ein Ableger der Engine aus Thalions Airbus A320. Vielleicht hilft das weiter.
Bezüglich der Idee von Wetzer, ich denke es ist etwas zu kompliziert gedacht. Man kann die vorhandenen Renderfunktionen auch einfach etwas weiter aufbohren um z.B. Texturen mit einer höheren Auflösung zu unterstützen. Falls das nicht reichen sollte kann man die Funktionen auch immer noch durch neue ersetzen.
Ansonsten wollte ich kurz vermelden, dass ich eine Seite für die Riva.alf angelegt habe. Dort die Module etwas beschrieben habe und aktuell bei den Dats bin. Einige sind wirklich identisch mit den Files von Schweif. Andere wurden enorm erweitert. Die Kisten funktionieren anders als bisher. Es gibt quasi keine Platzbeschränkung mehr und außerdem werden viele zusätzliche Werte gespeichert.
Selbst die Texturen und Positionen von Menüs können verändert werden. Also es sieht momentan so aus, als würde sich meine Vermutung bestätigen. Riva scheint der NLT Teil zu sein der am einfachsten zu modden ist.
beim Stöbern in der fight.lst in Schweif ist mir gleich aufgefallen, dass sie deutlich kürzer als in Schick ist. Ich habe mir die Kämpfe genauer angesehen und bemerkt, dass nicht alle Kämpfe dort gespeichert sind. Die Kämpfe in der Binge fehlen ebenso wie die Kämpfe im Phextempel.
Die Frage ist nun: wenn sie nicht in der fight.lst stehen, wo stehen sie dann?
(01.06.2014, 19:37)Lippens die Ente schrieb: [ -> ]Die Frage ist nun: wenn sie nicht in der fight.lst stehen, wo stehen sie dann?
AkteX-Musik spielt im Hintergrund...
Ihr habt echt meinen Respekt. Ich zermartere mein Hirn immer noch an der 3dm-Datei...
Die Vermutung liegt nahe, dass es ebenfalls in der Schweif.exe ist. Es gibt dort einige größere Datenblöcke, sogar einen der mit ARKANDOR anfängt. Aber die Werte darin passen nicht überein, nur die 20 Byte für den Namen stimmen überein.
Falls es dich interessiert Lippens, ich häng mal ne Liste (gepackt) aller Szenarios und Kämpfe an. Die ASCII Darstellung ist nicht so toll, war aber vorallem dazu gedacht den Aufbau besser zu verstehen.
Ja, diese Kämpfe sind mir alle bekannt: es sind sämtliche Kämpfe, die auf Reisen und in bestimmten Gebäuden stattfinden, sowie ein paar einzelne Dungeon-Kämpfe, aber bei weitem nicht alle. Wenn diese Kämpfe wirklich in der Schweif.exe gespeichert sind (denn wo sonst könnte es logischerweise noch sein), kann die Stelle sehr schwer zu finden sein, fraglich ob man überhaupt herankommt, denn die Struktur ist ja auch vielleicht eine andere als in der fight.lst in Schick hingegen dürften alle Kämpfe drin sein. Immerhin hat ja auch keiner der Kämpfe in der fight.lst in Schweif den Namen Dungeonkampf..., was deine Theorie weiter stützt. Na denn gute Nacht.
Die gesamte Struktur der Schweif.exe ist auch noch nicht erforscht, wie mir scheint.
Aber was anderes: wie packt man denn die umgewandelten Dateien der RIVA.alf wieder vernünftig zusammen? ich habe es nicht geschafft.
Wie wäre es, wenn ihr auch mal Tutorials schreibt (oder von mir aus Video-Tutorials macht und auf Youtube hochladet), wenn ihr wisst, wie man etwas macht? Dann hätten andere auch etwas davon. Z.B. wie man was packt!
Entschuldigt bitte die Zitateschlacht, aber ich finde es so besser als eine Reihe von Posts. Wenn ihr das anders seht, sagt es mir bitte!
(30.05.2014, 08:20)Rabenaas schrieb: [ -> ]Übrigens liefen Festkommaformate bis 486 potentiell schneller als Fließkomma. Das änderte sich erst mit den Pentiums.
Übrigens ist die Engine von Riva, wie Borbaradwurm herausgefunden hat, ein Ableger der Engine aus Thalions Airbus A320. Vielleicht hilft das weiter.
Ich schaue mir z.Z. die Festkommaformate an. Das wird schon
Über Thalions A320 habe ich fast nichts gefunden, was in Richtung Modding geht. Ist nett, das zu wissen, aber bisher noch nicht so ergiebig.
(01.06.2014, 14:21)Helios schrieb: [ -> ]Bezüglich der Idee von Wetzer, ich denke es ist etwas zu kompliziert gedacht. Man kann die vorhandenen Renderfunktionen auch einfach etwas weiter aufbohren um z.B. Texturen mit einer höheren Auflösung zu unterstützen. Falls das nicht reichen sollte kann man die Funktionen auch immer noch durch neue ersetzen.
Dafür müssten die Funktionen alle alá BrightEyes dekodiert sein. Das ist natürlich noch eine Menge Aufwand!
(01.06.2014, 14:21)Helios schrieb: [ -> ]Ansonsten wollte ich kurz vermelden, dass ich eine Seite für die Riva.alf angelegt habe. Dort die Module etwas beschrieben habe und aktuell bei den Dats bin. Einige sind wirklich identisch mit den Files von Schweif. Andere wurden enorm erweitert. Die Kisten funktionieren anders als bisher. Es gibt quasi keine Platzbeschränkung mehr und außerdem werden viele zusätzliche Werte gespeichert.
Selbst die Texturen und Positionen von Menüs können verändert werden. Also es sieht momentan so aus, als würde sich meine Vermutung bestätigen. Riva scheint der NLT Teil zu sein der am einfachsten zu modden ist.
Habe mir den Artikel angesehen und bin begeistert! Sehr gut, je mehr identifiziert ist, desto besser!
(02.06.2014, 14:34)wiese.hano schrieb: [ -> ]Wie wäre es, wenn ihr auch mal Tutorials schreibt (oder von mir aus Video-Tutorials macht und auf Youtube hochladet), wenn ihr wisst, wie man etwas macht? Dann hätten andere auch etwas davon. Z.B. wie man was packt!
Die Idee ist nett, aber es tut mir leid, dafür fehlt mir schlicht die Zeit. Vor allem wüsste ich auch nicht, wie ich meine jahrelange Erfahrung im Umgang mit Hexeditoren sinnvoll in Worte fassen kann, ohne ein hunderte Seiten langes Buch zu schreiben. Reverse Engineering hat sehr viel intuitives Ausprobieren, das kann man nicht einfach in ein Schema F packen.
Das einfachste wäre wohl, sich ein Spiel herauszusuchen, dessen Formate komplett dekodiert sind, und daran zu üben.
Auf
http://wiki.xentax.com/index.php?title=G...at_Central findet man eine Reihe von dekodierten Formaten. Da findet man auch Informationen zu üblichen Kompressions/Verschlüsselungsformaten und diverse Artikel über Herangehensweisen.
Da könnte man sich z.B.
http://wiki.xentax.com/index.php?title=Baldurs_Gate_BIF ansehen, das Format der Archive von Baldurs Gate. Dort steht, wie der Header aufgebaut ist. Mit ein wenig Programmierkenntnis kann man damit einen Entpacker für die BIFs machen. Dann schaut man sich ein anderes Format an und macht das ganze nochmal. Mit der Zeit bekommt man ein Gefühl dafür, wie so eine Archivdatei aufgebaut sein kann. Und dann kommt irgendwann der Punkt, wo man auch mit Hexeditor in einer unbekannten Datei herumsuchen kann. Z.B. mal ein Offset anzeigen, dann sieht man, dass der Wert darin die Dateigröße ist. Das nächste Offset zeigt auf den Anfang der Nutzdaten usw...
Das ist keine einfache Materie, leider
Ich kann Shihan nur zustimmen was Reverse Engineering angeht. Es gibt keine pauschale Herangehensweise, ich würde sogar behaupten jeder der sowas tut hat sein eigenes System. Manche benutzen eigene kleine Tools, anderen reicht ein Hexeditor wieder andere benutzen nur einen Disassembler.
(02.06.2014, 15:07)Shihan schrieb: [ -> ]Dafür müssten die Funktionen alle alá BrightEyes dekodiert sein. Das ist natürlich noch eine Menge Aufwand!
Wenn es schlecht läuft kann es natürlich passieren. Wir könnten aber auch "Glück" haben und stolpern vorher darüber. Am schönsten wäre es meiner Ansicht nach wenn wir DLL-Injection betreiben könnten. Aber es wird wohl eher auf patchen der Executable hinauslaufen oder halt einem Riva BrightEyes.
Letztendlich muss man aber egal welches Verfahren man benutzt, die Funktionen die man verändern möchte vorher dekodiert haben.
(01.06.2014, 23:03)Lippens die Ente schrieb: [ -> ]Die gesamte Struktur der Schweif.exe ist auch noch nicht erforscht, wie mir scheint.
Ja, ich hab mir mal den Datenblock rauskopiert und bin dran. Scheinen aber wirklich andere Formate zu sein.
(01.06.2014, 23:03)Lippens die Ente schrieb: [ -> ]Aber was anderes: wie packt man denn die umgewandelten Dateien der RIVA.alf wieder vernünftig zusammen? ich habe es nicht geschafft.
Ich auch noch nicht, kann dir also leider nicht helfen. Bisher habe ich immer die Dateien in CTEMP bzw. TEMP verändert oder die jeweilige ALF Datei.
(20.05.2014, 14:02)Shihan schrieb: [ -> ]Ich bin gerade dabei, eine C++-Library zu schreiben (bzw. aus nltpack abzuleiten), die sämtliche Formate, die bekannt sind, entpacken und konvertieren kann. Beim BoPa gibt es noch einen kleinen Bug, aber das kommt noch.
@Lippens: Da bin ich anscheinend nicht der einzige der sich auf diese Library freut.