Reverse Engineering der NLT

[HenneNWH]

Prinzipiell hast Du Recht,

Redundanz sollte vermieden werden. Ein richtiges Argument habe ich nicht, aber mein Bauchgefühl sagt:
Jeden Teil einzeln rausschnitzen, und danach erst die Sourcecodes der einzelnen Spiel zusammenführen.

Prinzipiell kann man das jetzt auch schon machen, aber HE! guck dir den Code mal an...
...wenn dort jetzt noch dynamische Variablen reinkommen, blick ich so schnell nicht mehr durch.

Im Moment schätze ich die geringe Clustergröße der Arbeiten, da ich ohne viel Vorlauf "mal schnell" eine Funktion hinzufügen kann.
So etwas wie so ein Dialog ist mit 15min schreiben + 15min testen schnell im Kasten (Repo).

Wenn wir irgendwann mit Riva fertig sein sollten, dann könnten wir theoretisch anfangen die Spiele zu mergen und zu optimieren.
Ein einheitliches Spielstandsformat, einheitliches Kampfsystem, mehr KI bei Computerkämpfen... (träum)

Hast du die Callback-Funktionen schon enteckt? Die sparen unglaublich viel nervige Arbeit.

Achso, arbeitest Du immer noch mit V1.00? Auf dem neuen Release wird die Doppel-CD Version von Schweif dabei sein.
Da die meisten dann legal im Besitz dieser Version sein werden wäre das die beste Version für "Bright-Eyes-Schweif".

[Obi-Wahn]

Warum sind das eigentlich nur insgesamt 6 NPC-Dialoge? Gibts es nicht mehr in Schick?

btw: Ich liebe Linux! Hier ist es dreimal einfacher etwas zu kompilieren als unter Windows!

[HenneNWH]

Ja, es sind nur 6 NPCs im Spiel:
"ARDORA.NPC CURIAN.NPC ERWO.NPC GARSVIK.NPC HARIKA.NPC NARIELL.NPC"

Im gleichen Segment sind noch 4 weitere Funktionen zum hinzufügen (add_npc()), zum löschen, zum treffen innerhalb der Tavernen
und das Verabschieden.
Als spezieller NPC ist Ardora zu erwähnen, da ihr Dialog aus dem Totenschiff heraus aufgerufen wird.
Alle Anderen sind, wie es sich für DSA gehört, in Tavernen bei Zechen-Proben anzutreffen.

[Hendrik]

Prinzipiell hast Du Recht,

Redundanz sollte vermieden werden. Ein richtiges Argument habe ich nicht, aber mein Bauchgefühl sagt:
Jeden Teil einzeln rausschnitzen, und danach erst die Sourcecodes der einzelnen Spiel zusammenführen.

Prinzipiell kann man das jetzt auch schon machen, aber HE! guck dir den Code mal an...
...wenn dort jetzt noch dynamische Variablen reinkommen, blick ich so schnell nicht mehr durch.

Im Moment schätze ich die geringe Clustergröße der Arbeiten, da ich ohne viel Vorlauf "mal schnell" eine Funktion hinzufügen kann.
So etwas wie so ein Dialog ist mit 15min schreiben + 15min testen schnell im Kasten (Repo).

Wenn wir irgendwann mit Riva fertig sein sollten, dann könnten wir theoretisch anfangen die Spiele zu mergen und zu optimieren.
Ein einheitliches Spielstandsformat, einheitliches Kampfsystem, mehr KI bei Computerkämpfen... (träum)

Sehe ich auch so. Ich werde beim Nachbauen von Schweif ein wenig darauf achten, Funktionen zu markieren, die in Schweif ähnlich/gleich gelöst sind wie in Schick. D.h. ich werde einen Kommentar wie "ähnlich Schicksalsklinge" über solche Funktionen schreiben. Bei fopen/lseek beispielsweise ist der Code gleich, bis auf die Adresse, an der das Filehandle abgelegt wird. Da müsste man also eine Variable einfügen, die in beiden Teilen unterschiedlich ist. Irgendwann sieht man da nicht mehr durch, und so etwas wie die DOS-Funktionen kann man hinterher recht einfach zusammenführen.

Hast du die Callback-Funktionen schon enteckt? Die sparen unglaublich viel nervige Arbeit.

Nein. Ich habe zwar einen Verdacht, welche Funktion es sein könnte, aber bin mir noch nicht ganz sicher.

Achso, arbeitest Du immer noch mit V1.00? Auf dem neuen Release wird die Doppel-CD Version von Schweif dabei sein.
Da die meisten dann legal im Besitz dieser Version sein werden wäre das die beste Version für "Bright-Eyes-Schweif".

Ja. Ich habe aber schon relativ viel Code identifiziert und scheue den Aufwand, jetzt alles nochmal neu zu eruieren, denn da stecken viele Stunden an Arbeit drin. Wenn ich die Binaries von O1.00, C1.00 und C1.02 vergleiche, dann ähnelt die O1.00 eher der C1.02 als der C1.00. Damit wäre die O1.00 die 1-CD-Variante von C1.02 und nicht von C1.00. Wenn das tatsächlich so ist, würde ich sogar mit der neuesten Version von Schweif arbeiten - nur eben auf 1 CD ausgelegt statt auf 2. Wenn ich schnell die Ergebnisse aus meiner O1.00-IDA-Datei in eine C1.02-IDA-Datei übertragen könnte, würde ich natürlich die nehmen - zumal ich Besitzer beider Versionen bin. Aber ich fürchte, da führt nichts an manueller Suche vorbei.

[HenneNWH]

Wenn die Beta-Testerei vorbei ist würde ich dir beim durchsuchen auch helfen.

Apropos: es gibt jetzt IDA 5.0 (statt 4.9) als kostenlosen Download.

Vielleicht sollten wir bald migrieren, wenn wir wissen ob die neue Version besser für unsere Zwecke ist.

EDIT: Mit Callbacks kannst Du dem Emulator eine RealMode Adresse übergeben und er führt den Code aus bis die emulierte Funktion zurückkehrt.
Es beißt sich zwar irgendwie mit dem Overlay-Manager, aber Funktionen, die immer einen festen Platz haben (und keinen Overlay Code aufrufen)
gehen perfekt. Z.B. kann man damit gut Funktionen erstellen die man nicht nachprogrammieren möchte, z.B. C-Lib Funktionen (seg000)oder das Soundsystem (seg022).

[Hendrik]

Wenn die Beta-Testerei vorbei ist würde ich dir beim durchsuchen auch helfen.

Apropos: es gibt jetzt IDA 5.0 (statt 4.9) als kostenlosen Download.

Vielleicht sollten wir bald migrieren, wenn wir wissen ob die neue Version besser für unsere Zwecke ist.

EDIT: Mit Callbacks kannst Du dem Emulator eine RealMode Adresse übergeben und er führt den Code aus bis die emulierte Funktion zurückkehrt.
Es beißt sich zwar irgendwie mit dem Overlay-Manager, aber Funktionen, die immer einen festen Platz haben (und keinen Overlay Code aufrufen)
gehen perfekt. Z.B. kann man damit gut Funktionen erstellen die man nicht nachprogrammieren möchte, z.B. C-Lib Funktionen (seg000)oder das Soundsystem (seg022).

IDA 5.0? *sabber* Muss ich mir mal anschauen!
Das mit den Callbacks natürlich auch ...

[Obi-Wahn]

Kann man deine Arbeit eigentlich auch irgendwo bewundern, Hendrik?

[Hendrik]

Sehr bald. Ich bin gerade dabei (und hoffe, dass ich das dieses WE schaffe), meinen Code so in BrightEyes integrieren, dass man sowohl Schicksalsklinge als auch Schweif damit spielen kann (wobei, wie gesagt, die Reimplementationen noch weitestgehend getrennt voneinander bleiben). Dann kommt es ins BrightEyes-Repository.

[Arbosh]

Hallo Henne!

Ich hab seit langem mal wieder in git pull gemacht und festgestellt das ich einen verbugten Spielstand habe/hatte:

Spoiler

Original-Bug: KORVO hat einen ungueltigen Gegenstandszaehler.
Korrigiere den Wert von 21 -> 22
Original-Bug: HJALDA hat einen ungueltigen Gegenstandszaehler.
Korrigiere den Wert von 12 -> 14
Original-Bug: GADAN hat einen ungueltigen Gegenstandszaehler.
Korrigiere den Wert von 6 -> 9

Die Suchfunktion gibt nicht viel her, daher die Frage an dich: Welcher Wert wird da korrigiert? Die Plätze im Inventory sinds schonmal nicht

Noch 'ne andere Frage: Ist für bestimmte Sachen schon feststellbar wo die ganzen random*-Aufrufe herstammen? Wäre z.B. interessant beim Kräutersammeln, da dort offensichtlich für jede Kräuterart ein Zufallswert besorgt wird und wenn dieser unter einer bestimmten Schwelle liegt eine entsprechende Pflanzenkundeprobe gemacht wird. Ich vermute aber fast, dass sich meine Frage mit dem Nachprogrammieren der entsprechenden Funktion sowie irgendwann erledigt hat, oder?

[Borbaradwurm]

Die Suchfunktion gibt nicht viel her, daher die Frage an dich: Welcher Wert wird da korrigiert? Die Plätze im Inventory sinds schonmal nicht

Offset 0x20 Anzahl belegter Gegenstandsslots

[HenneNWH]

Hallo Henne!

Ich hab seit langem mal wieder in git pull gemacht und festgestellt das ich einen verbugten Spielstand habe/hatte:
Die Suchfunktion gibt nicht viel her, daher die Frage an dich: Welcher Wert wird da korrigiert? Die Plätze im Inventory sinds schonmal nicht

Doch, genau die sind es: 7 Körperslots und 16 Inventarslots ergeben maximal 23 Plätze.
Durch einen Bug, welcher mit gestapelten Gegenständen zusammenhängt, entspricht dieser Wert nicht den tatsächlich belegten Plätzen.
Das ist für Schick nicht weiter tragisch, aber beim Import nach Schweif wird durch einen zu großen Wert eine Endlosschleife
ausgelöst.

Darum zählt überprüft Bright-Eyes in regelmäßigen Abständen diesen Wert und zählt die Gegenstände durch, korrigiert den Wert bei Unstimmigkeiten und gibt eine Warnung aus.

Noch 'ne andere Frage: Ist für bestimmte Sachen schon feststellbar wo die ganzen random*-Aufrufe herstammen? Wäre z.B. interessant beim Kräutersammeln, da dort offensichtlich für jede Kräuterart ein Zufallswert besorgt wird und wenn dieser unter einer bestimmten Schwelle liegt eine entsprechende Pflanzenkundeprobe gemacht wird. Ich vermute aber fast, dass sich meine Frage mit dem Nachprogrammieren der entsprechenden Funktion sowie irgendwann erledigt hat, oder?

Es ist im Moment so, dass die random_*()-Aufrufe, welche noch nicht nachprogrammiert wurden im dir bekannten "random(Wert) = Ergebnis" Format ausgegeben werden. Sie werden aber mit der Zeit entfernt.

Wenn ich eine Funktion nachprogrammiere die random() nutzt überlege ich, ob das Ergebnis einen Informationsgehalt für den Spieler hat. Wenn nicht verschwindet diese Ausgabe. Ist das Ergebnis für den Spieler von Interesse, dann bekommt dieser Aufruf eine sinngebundene Meldung mit eventuellen Extrainfos, z.B. ob Talentproben glücklich oder unglücklich ausgegangen sind.

[Arbosh]

Ich bin eigentlich wegen dieser Meldung stutzig geworden:

Spoiler

Original-Bug: KORVO hat einen ungueltigen Gegenstandszaehler.
Korrigiere den Wert von 22 -> 5
Gruppe 0 ausgewaehlt
Original-Bug: KORVO hat einen ungueltigen Gegenstandszaehler.
Korrigiere den Wert von 5 -> 22
Gruppe 1 ausgewaehlt

Hier scheint irgendwas beim Gruppenteilen bzw. Gruppenwechsel nicht hinzuhauen, ist das bekannt oder brauchts da mehr Informationen?

[Obi-Wahn]

Gerade habe ich mal wieder die neuste Version aus dem git-repo gebastelt und bekomme leider einen Darstellungsfehler bei den Kämpfen:     Ich bin beim Reisen im Schlaf überrascht worden und die Helden stehen einfach nicht auf und bewegen sich auch nicht bei den Angriffen. Auch bei einem Kampf gegen die Otta in Thorwal bewegen sich die Helden nicht. Im nebenher laufendem Log konnte ich keine Fehler entdecken...

[HenneNWH]

Oha,

vielen dank. Es war ein kleiner Tippfehler.
-11 != -1 Sorry.

Ich hab den Fix gerade hochgeladen.

Danke fürs testen und reporten.

P.S.: Die NPC Funktionen sind jetzt fertig.

[Obi-Wahn]

Funktioniert wieder. Anbei wieder eine aktuelle Windows Version, hat das jemand von den Windows-Usern eigentlich schon mal ausprobiert?

[HenneNWH]

Hm, noch kein Download. Schade.

Dieses Wochenende hab ich mal alle (>130) Warnungen von MS-VisualC 2008 unter die Lupe genommen und die Ursachen dafür behoben.
Du kannst ja den Compiler nochmal anwerfen.

[Obi-Wahn]

Ja, hätte auch gedacht, dass sich mehr Leute mal daran versuchen. Leider ist meine Evaluationsversion von Visualstudio nur noch acht Tage lang "haltbar" mal gucken, ob ich von der Uni da was bekommen kann.

Fehlermeldung gibt es in der Tat kaum noch. Ich habe mal den Log und eine aktuelle Version angehängt.

Edit: Ne.. leider bekomme ich nur "Intel ® C++ Composer XE" und ähnliche Programme nix von Kleinweich...

[Rabenaas]

Ich schätze mal, hier schauen einfach nicht genug Leute vorbei. Vielleicht sollte man einen zentralen Thread für BrightEyes-Downloads geben, oder Crystal setzt gleich irgendwo einen Hinweis.

[Malefitzfetz]

Ich habe schon mitgelesen, allerdings bin ich gerade mit meinem ersten Komplettdurchlauf der NLT beschäftigt und habe keine Zeit zum testen. Außerdem kamen die Windows Binarys in letzter Zeit immer sehr spärlich und ich bin zu faul, bzw. habe keine Zeit mein Linux System zu aktivieren
Wenn ich das Windows Binary ziehe( falls ich zwischendurch mal Zeit auftreiben kann), muss ich da noch Spieldaten hinzukopieren oder muß ich das in den Schick Ordner installieren? Kann ich dann BrightEyes ganz normal in der DosBox starten?

[Rabenaas]

BightEyes ist DosBox plus X. Du startes BE so, wie sonst die DosBox.