Themabewertung:
  • 5 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Reverse Engineering der NLT
Ja, ich hab's schon mal ausprobiert. Das Logging funktioniert tadellos, aber eigentlich hat mich ja mehr der Code interessiert. Leider hatte ich nicht so viel Zeit und hab nur mal 'ne knappe Stunde damit verbracht. Aber das, was ich gesehen habe, hat mir gut gefallen. Ich würde jedenfalls gerne zur Erweiterung von "Bright Eyes" beitragen.


Wie ist das eigentlich, wenn man zu zweit an den Disassembly-Dateien von IDA rumhackt? Gepackt sind die ja binär, kommt man sich mit ungepackten Dateien auch noch in die Quere? Ich würde dich ansonsten gern unterstützen beim Tüfteln, wir müssten uns halt nur absprechen, wer welche Teile der .exe analysiert. Wenn sich das von der Synchronisierung nicht so gut macht, würde ich meine Versuche mit Sternenschweif mal fortsetzen. Wie an anderer Stelle schon gesagt, könnte ich zwar schon einiges mitloggen, habe aber noch Probleme mit der Overlay-Funktion, die bei jedem Aufruf "zufällig" die Segmentadresse verschiebt.
Hallo, ich bin's - der Bart von Fidel Castro. Und mir ist total langweilich nie geschnitten wurde.
I'm a roleplayer. My dice are like my relationships: platonic and unlucky.
Sieht alles prima aus. Ich wollte über die Feiertage sowieso die NLT mal wieder angehen. Das mache ich dann mit BrightEyes. Soll ich auf irgendetwas spezielles achten (außer Abstürzen und Grafikfehlern)?

Hat die NLT eigentlich irgend etwas mit Watership Down zu tun? :think:
(13.12.2010, 20:40)Obi-Wahn schrieb: Ich unter Linux theoretisch schon, nur bin ich mir nicht sicher, ob nicht doch die installierte dosbox verwendet wurde. Obwohl ich ./dosbox (oder so ähnlich) verwendet habe. Die Kompilierung läuft jedenfalls durch.

Du kannst das Binary src/dosbox in brighteyes umbenennen und mit ./brighteyes starten.
So kannst du umgehen, das die installierte DOSBox gestartet wird. Oder dem Fehler eher auf die schliche kommen.:shy:

(14.12.2010, 10:22)Hendrik schrieb: Ja, ich hab's schon mal ausprobiert. Das Logging funktioniert tadellos, aber eigentlich hat mich ja mehr der Code interessiert. Leider hatte ich nicht so viel Zeit und hab nur mal 'ne knappe Stunde damit verbracht. Aber das, was ich gesehen habe, hat mir gut gefallen. Ich würde jedenfalls gerne zur Erweiterung von "Bright Eyes" beitragen.


Wie ist das eigentlich, wenn man zu zweit an den Disassembly-Dateien von IDA rumhackt? Gepackt sind die ja binär, kommt man sich mit ungepackten Dateien auch noch in die Quere?
Die Ungepackten sind auch nicht besser, weil sie auch binär sind. Das ist fast das Einzige, was mich an IDA stört.
Danke nochmal für die Programempfehlung, Hendrik.

(14.12.2010, 10:22)Hendrik schrieb: Ich würde dich ansonsten gern unterstützen beim Tüfteln, wir müssten uns halt nur absprechen, wer welche Teile der .exe analysiert. Wenn sich das von der Synchronisierung nicht so gut macht, würde ich meine Versuche mit Sternenschweif mal fortsetzen.

Es ist am einfachsten, wenn du mit IDA an Schweif rumtüftelst.
Wenn du aber an Schick mitbauen willst, dann brauche ich noch etwas Hilfe beim dokumentieren bzw. den Code lesbarer zu machen. Das können wir parallel tun.

(14.12.2010, 10:22)Hendrik schrieb: Wie an anderer Stelle schon gesagt, könnte ich zwar schon einiges mitloggen, habe aber noch Probleme mit der Overlay-Funktion, die bei jedem Aufruf "zufällig" die Segmentadresse verschiebt.

Dafür hab ich schon ne Funktion geschrieben, is_ovrseg(unsigned short stub_segment).
Der Stub ist der kleine Programmteil, welcher immer in Speicher ist und über den auf den richtigen Code zugegriffen wird.
In diesem Stub befindet sich, sofern der Code im Speicher ist, eine Sprunganweisung zum entsprechenden Segment, welches mit dem momentanen CS (Codesegment) verglichen wird. Wenn beide gleich sind haben wir die richtige Funktion gefunden.

Siehe src/custom/schick/schick_m302de.cpp bei den Talent-/ und Zauberproben.

(14.12.2010, 11:46)Rabenaas schrieb: Sieht alles prima aus. Ich wollte über die Feiertage sowieso die NLT mal wieder angehen. Das mache ich dann mit BrightEyes. Soll ich auf irgendetwas spezielles achten (außer Abstürzen und Grafikfehlern)?

Hat die NLT eigentlich irgend etwas mit Watership Down zu tun? :think:

Abstürze wären gut. Grafikfehler sind mir bis jetzt nicht mehr untergekommen, aber schau ruhig.
Ich würde mich auch sehr freuen, wenn jemand die LOG-Meldungen auf allgemeine Verständlichkeit prüft,
da ich zu den Meldungen nicht mehr genug Abstand habe. :cool:
Funktioniert. :) Ich werd auch mal gucken, dass ich vielleicht etwas spiele.
--------
Warnung! Geschichte kann zu Einsichten führen und verursacht Bewusstsein!
Avatar by: Keven Law (CC BY-SA 2.0)
(13.12.2010, 20:21)HenneNWH schrieb: Na, wie siehts denn aus.

Hat schon jemand "Bright Eyes" ausprobiert?

Ja, hab ich heut. Was mir aufgefallen ist:
  • Meister Dramosch gibt mir jedes mal 20 Dukaten beim Verlassen der Zwingfeste, in der Forumssuche hab ich das bisher nicht als Bug gefunden
  • Die Hitpoints werden beim Kampf nicht dargestellt (habs aber nicht nochmal mit der normalen Dosbox verifiziert)
  • Nach Ende eines Kampfes hieß es laut Log alle Helden hätten 0 AP bekommen, laut Charakterbogen hatten sie aber die korrekte Menge an AP erhalten

Sind das bekannte Probleme in Zusammenhang mit BrightEyes, oder sollte ich hier mir einer ungepatchten Dosbox mal nachprüfen?

Ansonsten großen Respekt für der investierten Arbeit!

Edit: Ok, das mit der Zwingfeste ist also ein Cheat, den kannte ich noch gar nicht... Allerdings scheint die Anzeige der Hitpoints wirklich ein Problem von BrightEyes zu sein, habs mit einer originalen Dosbox verifiziert.
Edit 2: Ein weiteres Problem von BrightEyes scheinen Soundeffekte zu sein, ich höre nämlich keine mehr. Zur Info, ich hab zum Vergleichen die BrightEyes Codebasis verwendet, einmal mit "--enable-schick" und einmal mit "--disable-schick"
(17.12.2010, 23:18)Arbosh schrieb:
  • Meister Dramosch gibt mir jedes mal 20 Dukaten beim Verlassen der Zwingfeste, in der Forumssuche hab ich das bisher nicht als Bug gefunden
Das ist, wie Du nun weisst, im Original auch so. Ich halte es eher für einen Bug in der Zwingfesten-Quest.
Dazu später mehr, wenn ich mit noch ein paar andere Quests angesehen hab,
da die Zwingfesten-Quest die einzige ist, die ich mir bis jetzt angesehen habe.

(17.12.2010, 23:18)Arbosh schrieb:
  • Die Hitpoints werden beim Kampf nicht dargestellt (habs aber nicht nochmal mit der normalen Dosbox verifiziert)
Super, das war ein Bug von mir. :thx: Hab ihn hier gefixt.

(17.12.2010, 23:18)Arbosh schrieb:
  • Nach Ende eines Kampfes hieß es laut Log alle Helden hätten 0 AP bekommen, laut Charakterbogen hatten sie aber die korrekte Menge an AP erhalten

Hm, stimmt, die Ausgabe ist etwas verwirrend.
Ein paar Zeilen vorher steht einen Meldung, dass die Gruppe eine gewisse Anzahl von AP erhält.
Das sind die AP die du bekommen hast.

Gruppe erhaelt 60 AP
Gegner (0x41) zum ersten mal besiegt
Gegner (0x42) zum ersten mal besiegt
Jeder Held erhaelt +0 AP
ARBOSH erhaelt 0 AP
HJALDIS erhaelt 0 AP
RHENAYA erhaelt 0 AP
TALIMEE erhaelt 0 AP
TAMION erhaelt 0 AP
YARANO erhaelt 0 AP

Zur Erklärung: Es gibt im Spiel 3 AP Verteilungsfunktionen:
  • Ein Held bekommt AP. z.B. Tür öffen.
  • Jeder Held der Gruppe bekommt AP.
  • Die Gruppe bekommt AP und teilt sie unter sich auf.

Bei der letzten Funktion ist die Anzahl der AP manchmal von der Anzahl der Mitglieder der aktuellen Gruppe abhängig.
Das Spiel ruft am Ende eines Kampfes die letzten beiden Funktionen auf.
Von der dritten bekommst du wirklich die AP, von der zweiten bekommt jeder Held 0 AP, weil es ja schon APs gab. :silly:
Warum die Funktionen allerdings überhaput aufgerufen werden, wenn die AP 0 sind weiss ich auch nicht.

(17.12.2010, 23:18)Arbosh schrieb: Ansonsten großen Respekt für der investierten Arbeit!
:thx: ich kann nicht anders.

(17.12.2010, 23:18)Arbosh schrieb: Edit 2: Ein weiteres Problem von BrightEyes scheinen Soundeffekte zu sein, ich höre nämlich keine mehr. Zur Info, ich hab zum Vergleichen die BrightEyes Codebasis verwendet, einmal mit "--enable-schick" und einmal mit "--disable-schick"

Das ist interessant.
Du meinst wirklich die Soundeffekte und nicht die Musik? Bei mir funktioniert beides (mit nem bin/cue Image).
Ein paar Vorschläge:
  • Setzt mal mit STRG+F11 die Cycles runter (1000 ist ein guter Wert), da eine schnelle DOSBox-CPU manchmal die Soundeffekte wegdrückt.
  • Starte im DSA-Verzeichnis (in der DOSBox) die sound.bat und stelle als Soundkarte den Soundblaster PRO ein.
  • Zeig mal deine config-datei.

Wenn du BrightEyes mit --disable-schick compilierst, dann hast du eine normale DOSBox-0.74, wie sie bei den meisten
aktuelle Distris dabei ist. Da brauchst du das nicht selber kompilieren. :)
(19.12.2010, 14:33)HenneNWH schrieb:
(17.12.2010, 23:18)Arbosh schrieb: Edit 2: Ein weiteres Problem von BrightEyes scheinen Soundeffekte zu sein, ich höre nämlich keine mehr. Zur Info, ich hab zum Vergleichen die BrightEyes Codebasis verwendet, einmal mit "--enable-schick" und einmal mit "--disable-schick"

Das ist interessant.
Du meinst wirklich die Soundeffekte und nicht die Musik? Bei mir funktioniert beides (mit nem bin/cue Image).
Ein paar Vorschläge:
  • Setzt mal mit STRG+F11 die Cycles runter (1000 ist ein guter Wert), da eine schnelle DOSBox-CPU manchmal die Soundeffekte wegdrückt.
  • Starte im DSA-Verzeichnis (in der DOSBox) die sound.bat und stelle als Soundkarte den Soundblaster PRO ein.
  • Zeig mal deine config-datei.

Wenn du BrightEyes mit --disable-schick compilierst, dann hast du eine normale DOSBox-0.74, wie sie bei den meisten
aktuelle Distris dabei ist. Da brauchst du das nicht selber kompilieren. :)

Das Problem erledigt sich wenn ich der Dosbox in der dosbox.conf sage, dass die CPU mit 1000 Cycles fix zu laufen hat (vorher 3000), danke für den Tip! Mir ist aber noch ein kleiner Bug im configure-Script aufgefallen: Ich kann zwar BrightEyes mit --disable-schick explizit deaktivieren, aber nicht mit --enable-schick explizit aktivieren. Es wird nur eingebunden wenn configure ohne Parameter aufgerufen wird.
So,

fast pünktlich zur Bescherung gibts noch ein neues "Bright Eyes". :xmas:
Neu sind:
  • der NVF-Loader
  • Farbpaletten bei Dämmerung und Fade-Outs
  • ein Meldung mit welcher Wahrscheinlichkeit man sich eine Krankheit einfangen kann
  • uvm.

(24.12.2010, 10:30)Arbosh schrieb: Das Problem erledigt sich wenn ich der Dosbox in der dosbox.conf sage, dass die CPU mit 1000 Cycles fix zu laufen hat (vorher 3000), danke für den Tip!

Gern geschehen.

(24.12.2010, 10:30)Arbosh schrieb: Mir ist aber noch ein kleiner Bug im configure-Script aufgefallen: Ich kann zwar BrightEyes mit --disable-schick explizit deaktivieren, aber nicht mit --enable-schick explizit aktivieren. Es wird nur eingebunden wenn configure ohne Parameter aufgerufen wird.

Oh, danke für den Tip.:ok: Ich habe mir mit Automake & Co. noch gar nicht richtig auseinandergesetzt,
werds die Feiertage aber tun.


Angehängte Dateien
.zip   bright_eyes-pre0_02.zip (Größe: 793,81 KB / Downloads: 12)
Ist der Archivinhalt das Gleiche wie im git? Nach einem git pull, ./configure && make kommt jetzt diese Meldung:
Code:
g++ -DHAVE_CONFIG_H -I. -I../../..  -I../../../include -I../schick_rewrite -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT  -g -O2  -MT schick_m302de.o -MD -MP -MF .deps/schick_m302de.Tpo -c -o schick_m302de.o schick_m302de.cpp
schick_m302de.cpp: In function ‘int seg000(short unsigned int)’:
schick_m302de.cpp:231: error: ‘toupper’ was not declared in this scope
make[4]: *** [schick_m302de.o] Fehler 1

Welches System nimmst du zum Übersetzen? (insbesondere welchen Compiler?)

Ansonsten frohe Weihnachtsfeiertage ;)

Edit:
Ich hab grad mal nachgeguckt, in der Datei schick_m302de.cpp fehlt am Anfang folgendes Include:
Code:
#include <ctype.h>
Damit gehts dann. Zur Info, ich hab den Fehler auf 'nem Debian Lenny als auch auf 'nem Ubuntu 10.04 gehabt.
Hm,

den Fehler habe ich am 23.12 schon behoben.
Wenn ich allerdings vergesse mein Repo zu aktualisieren, dann merkt das bloß keiner. :silly:

Bei mir hat es unter Ubuntu 10.10 x86_64 mit gcc-4.4.5 keinen Fehler gegeben.
Den Fehler habe auf meinem Nokia N900 (lenny) entdeckt, sowie unter MS Visual C++ 2008.

Der GCC ist imho da etwas seltsam. DOSBox-0.72 lies sich bei mir, nach einem Versionswechsel wegen ähnlicher include-Fehler, nicht mehr kompilieren.

Trotzdem danke fürs posten.:thx:

Edit: Die Antwort auf deine Frage lautet in dem Fall: Nein.
(25.12.2010, 22:13)HenneNWH schrieb: Hm,

Bei mir hat es unter Ubuntu 10.10 x86_64 mit gcc-4.4.5 keinen Fehler gegeben.
Den Fehler habe auf meinem Nokia N900 (lenny) entdeckt, sowie unter MS Visual C++ 2008.

Der GCC ist imho da etwas seltsam. DOSBox-0.72 lies sich bei mir, nach einem Versionswechsel wegen ähnlicher include-Fehler, nicht mehr kompilieren.

Das liegt daran, dass die Standard-Includes inzwischen ausgedünnt wurden (weshalb eben ctype.h auch nicht mehr dazugehört) um näher am C++-Standard zu sein.
Super! :up:

Nach drei Kartenstücken habe ich noch nichts ungewöhnliches bemerkt, außer dass Schick abgeht wie ein Z -ähm- wie ein geölter Blitz.
Wie kann ich einer "nackten" Dosbox die Anweisung geben, eine spezielle Config zu benutzen?

Edit: Probieren geht über studieren: Einfach eine dosbox.conf in den src-Ordner packen! :)
--------
Warnung! Geschichte kann zu Einsichten führen und verursacht Bewusstsein!
Avatar by: Keven Law (CC BY-SA 2.0)
(28.12.2010, 13:48)Obi-Wahn schrieb: Wie kann ich einer "nackten" Dosbox die Anweisung geben, eine spezielle Config zu benutzen?

Edit: Probieren geht über studieren: Einfach eine dosbox.conf in den src-Ordner packen! :)

:yes:
Oder indem Du DOSBox mit dem Parameter "-conf <eigene Config>" startest.
Jetzt habe ich doch noch ein Problem.
Code:
Aendere Gruppenvermoegen = 50D 0S 0H
Location verlassen: Dialog
Quest: Zwingfeste Thorwal Quest abgeschlossen
Fehler

Mal sehen, ob's wieder passiert...
(28.12.2010, 23:31)Rabenaas schrieb: Jetzt habe ich doch noch ein Problem.

Mal sehen, ob's wieder passiert...

Nur wenn du nicht neu aus dem Repo kompilierst. Ich hab bei einer switch-Anweisung ein "break" vergessen. :wall:

Es ist seit 10 min repariert.
mir ist auch grad was aufgefallen: Du hast die Passwortabfrage deaktiviert, schade um das schöne Memory-Spiel :cry: :wave:
Hab im gleichen Zuge heute noch einen Bug gefunden: Wird einer meiner Helden bewußtlos, wird dieser Zustand nicht mehr zurückgesetzt. D.h. jegliche Heilung durch Schlaf beim Übernachten (egal ob Lager oder Herberge) erhöht zwar die LE, aber im Charakterbogen steht immernoch "bewußtlos" und Kampf liegt der Held unnütz in der Gegend rum ;)
(16.01.2011, 12:41)Arbosh schrieb: mir ist auch grad was aufgefallen: Du hast die Passwortabfrage deaktiviert, schade um das schöne Memory-Spiel :cry: :wave:
Stimmt. :yes: Ich werd sie aber wieder aktivieren, wenn ich das Spiel nicht mehr so oft starten muss.
Versprochen.

(16.01.2011, 16:55)Arbosh schrieb: Hab im gleichen Zuge heute noch einen Bug gefunden: Wird einer meiner Helden bewußtlos, wird dieser Zustand nicht mehr zurückgesetzt. D.h. jegliche Heilung durch Schlaf beim Übernachten (egal ob Lager oder Herberge) erhöht zwar die LE, aber im Charakterbogen steht immernoch "bewußtlos" und Kampf liegt der Held unnütz in der Gegend rum ;)

Da ist mir wohl ein Fehler unterlaufen. Der Fix ist gerade im Repo gelandet.
Du kannst mit diesem Spielstand noch weiterspielen. Beim nächsten Heilen werden die bewusstlosen Helden wieder erwachen.

Vielen Dank fürs testen und reporten. :thx:
Das schreit nach einem Kommandozeilenargument.

Ich habe übrigens Schick mit BrightEyes durchgespielt.




Benutzer, die gerade dieses Thema anschauen: 14 Gast/Gäste