Reverse Engineering der NLT

[HenneNWH]

Es gibt 164 Stellen im Spiel die die Zeit etwas nach vorn Spulen.

Ich möchte zu Zurgrimms Liste noch folgendes hinzufügen:

• ein Schritt in der Stadt oder auf der Reisekarte = 2 min
  
• ein Schritt im Dungeon = 1 min
  
• eine Kampfrunde = 9s
  
• Vorräte Auffüllen = 1h
  

[tommy]

Ich hoffe du schreibst dir die ganzen Informationen auch immer schön auf, dass du sie irgendwann mal in geballter Form präsentieren kannst

[HenneNWH]

Natürlich...

...als Sourcecode.

[tommy]

Natürlich...

...als Sourcecode.

Das sollte ja schon ausreichen

[HenneNWH]

Hey Obi,

bau bitte nochmal eine neue Version.

Ich hatte noch einen Fehler, der bewirkt, dass man nur noch eine Nacht in der Herberge schlafen kann.
Der ist jetzt behoben.
Außerdem habe ich das Vorspulen etwas gedrosselt.

[Obi-Wahn]

Et voilí .

Danke für die zusätzlichen Infos über die "Zeitsprünge". Läuft also irgendwo ein sekundengenauer Spielzeit- oder Aventurienzeit-Timer mit?

[HenneNWH]

Ja es gibt so einen Spielzeittimer.


Das Spiel hat eine Hauptschleife, welche i.d.R. verlassen wird wenn der Spieler das Spiel beendet.
Würde man bei jedem Schleifendurchlauf die Ingame-Zeit erhöhen wäre sie von der Dauer eines Schleifendurchlaufs abhängig.
Diese Dauer wird meistens durch die Taktfrequenz der CPU bestimmt, was bedeuten würde:

Je schneller die CPU desto schneller die Ingame-Zeit.

Das wäre katrastophal!

Schick wurde für den 80286 geschrieben welchen es u.A. mit 4MHz und 25MHz gab.
Hätte man für die 4MHz Variante entwickelt, wäre die Ingame-Zeit auf dem 25MHz Modell etwas mehr als sechs mal so schnell vergangen.
Mein Prozessor hat 2400MHz, das 600-fache vom 4MHz-Modell.


Die bessere Lösung wäre soetwas wie ein Metronom mit einer festen Frequenz, die auf jedem Rechner gleich ist.
Soetwas gibt es. Der Intel 8253 PIT mit einer Frequenz von 18.2Hz unterbricht ca. alle 55ms den Prozessor
und ein Unterprogramm für das aktualisieren der Menschen-Uhrzeit wird aufgerufen.

Die Programmier haben beim Spielstart dieses Unterprogramm auf ein Eigenes umgeleitet
und erhöhen bei Ausführung die Ingame-Zeit um einen Tick.
Außerdem führen sie auch das alte Unterprogramm aus, damit beim Beenden des Spiels die Menschen-Uhrzeit nocht stimmt.

Eine Ingame-Stunde besteht aus 5400 Ticks. Daraus folgt:

1 Ingame Stunde = 5400 Ticks / (18.2 Hz * 60s) = 5 min in Menschen-Zeit.

Frage: In wieviel Menschen-Zeit würde eine Ingame-Stunde auf meinem Prozessor vergehen,
wenn die Ingame-Zeit in der Hauptschleife aktualisiert werden würde?
Schick wäre für die 4MHz Variante entwickelt worden.

Spoiler

5400 / 600 = 9
9s Menschen-Zeit = 1 Ingame-Stunde

Die Ingame-Zeit läuft also auch wenn man nichts tut. Möchte der Spieler das verhindern,
so kann er mit STRG+P die Pause aktivieren. Die Ingame Zeit läuft dann nicht weiter.


Dadurch, dass das Spiel vom diesem Unterprogramm an jeder beleibigen Stelle unterbrochen werden kann
ergeben sich Nebenläufigkeiten. Das Unterprogramm ist nämlich nicht nur für die Zeit zuständig,
sondern aktualisiert auch die Animationsbilder, z.B. im Tempel.

Vielleicht ist ist euch beim Start von Schick manchmal aufgefallen, dass die Augen des Priesters im Tempel
im Slot des NPC erscheinen. Das ist das Resultat von nicht ordentlich behandelten Nebenläufigkeiten
und tritt auch nicht immer auf. Diese Art von Fehlern zu debuggen ist nochmal eine Kunst für sich.

Mal sehen ob ich das auch noch lerne.

[Zurgrimm]

• ein Schritt in der Stadt oder auf der Reisekarte = 2 min
  
• ein Schritt im Dungeon = 1 min

Die Ingame-Zeit läuft also auch wenn man nichts tut.

Im Grunde ist das keine ganz neue Erkenntnis, auch wenn sie noch nicht so genau analysiert war. Die Beobachtung, daß die Zeit schneller vergeht, wenn man herumläuft und langsamer, wenn man untätig herumsteht, haben schon viele gemacht. Daß bei jedem Schritt die Zeit quasi einige Sekunden oder Minuten vorgespult wird, war so konkret aber noch nicht klar. Die Tatsache an sich wurde jedoch bereits zur Grundlage von TeraBlights Terminologie der Ingame-Inaktivitäts-Stunden. Im Rahmen der Erklärung der Einhorn-Mechanik hat er dabei auch einen Zusammenhang zwischen Verhältnis von Ingame- und Realzeit und Spiellaufgeschwindigkeit erkannt.

[Reg Schuh]

Vielleicht ist ist euch beim Start von Schick manchmal aufgefallen, dass die Augen des Priesters im Tempel
im Slot des NPC erscheinen. Das ist das Resultat von nicht ordentlich behandelten Nebenläufigkeiten
und tritt auch nicht immer auf. Diese Art von Fehlern zu debuggen ist nochmal eine Kunst für sich.

Ach, daher kommt das. Beim ersten Mal habe ich das in einem Phex-Tempel (!) gesehn und habe es für einen versteckten Hinweis gehalten, heimlich spähende Augen oder so - war natürlich nichts weiter zu rauszubekommen. Nachdem die Augen immer mal wieder zu sehen waren, habe ich an NPCs gedacht, die im Tempel warten. Ist natürlich auch kein NPC, der in Rybon im Tempel wartet. ;-)


Andere kurze Frage zu meiner "Speer-Hoffnung":

Da kann ich leider auch erstmal nicht helfen,
ich glaube aber, dass diese Werte in der SCHICKM.EXE (im Datensegment stehen).

Wo beginnt das Datensegment in der SCHICKM.EXE? Die Zahlen zu den Waffen ab #17A70 habe ich dank der früheren Einträge hier schon gefunden.
Und: Ist die SCHWEIF.EXE grundsätzlich ähnlich aufgebaut? Schon mal da reingeschaut gehabt?

[HenneNWH]

• ein Schritt in der Stadt oder auf der Reisekarte = 2 min
  
• ein Schritt im Dungeon = 1 min

Die Ingame-Zeit läuft also auch wenn man nichts tut.

Im Grunde ist das keine ganz neue Erkenntnis, auch wenn sie noch nicht so genau analysiert war. Die Beobachtung, daß die Zeit schneller vergeht, wenn man herumläuft und langsamer, wenn man untätig herumsteht, haben schon viele gemacht. Daß bei jedem Schritt die Zeit quasi einige Sekunden oder Minuten vorgespult wird, war so konkret aber noch nicht klar. Die Tatsache an sich wurde jedoch bereits zur Grundlage von TeraBlights Terminologie der Ingame-Inaktivitäts-Stunden. Im Rahmen der Erklärung der Einhorn-Mechanik hat er dabei auch einen Zusammenhang zwischen Verhältnis von Ingame- und Realzeit und Spiellaufgeschwindigkeit erkannt.

TeraBlight's Aussage kann ich soweit bestätigen, bis auf die Tatsache,
dass die Ingame-Zeit nicht von der CPU-Geschwindigkeit (oder den DOSBox-Cycles) abhängt.

Vielleicht ist ist euch beim Start von Schick manchmal aufgefallen, dass die Augen des Priesters im Tempel
im Slot des NPC erscheinen. Das ist das Resultat von nicht ordentlich behandelten Nebenläufigkeiten
und tritt auch nicht immer auf. Diese Art von Fehlern zu debuggen ist nochmal eine Kunst für sich.

Ach, daher kommt das. Beim ersten Mal habe ich das in einem Phex-Tempel (!) gesehn und habe es für einen versteckten Hinweis gehalten, heimlich spähende Augen oder so - war natürlich nichts weiter zu rauszubekommen. Nachdem die Augen immer mal wieder zu sehen waren, habe ich an NPCs gedacht, die im Tempel warten. Ist natürlich auch kein NPC, der in Rybon im Tempel wartet. ;-)

Ich finde es bemerkenswert, dass die Fehler in diesem Spiel von Vielen für geheimnisvolle Features gehalten werden
und es noch mehr aufwerten.

Vielleicht ist es doch keine so gute Idee das Spiel zu sehr demystifizieren.

Andere kurze Frage zu meiner "Speer-Hoffnung":
Wo beginnt das Datensegment in der SCHICKM.EXE? Die Zahlen zu den Waffen ab #17A70 habe ich dank der früheren Einträge hier schon gefunden.
Und: Ist die SCHWEIF.EXE grundsätzlich ähnlich aufgebaut? Schon mal da reingeschaut gehabt?

Bei der SCHICKM.EXE (v3.02de) beginnt das Datensegment an Offset 0x173c0.
Bei EXE-Dateien die mit dem Borland-C++ Compiler übersetzt wurden erkennt man das an 4 Nullen (0x00) und der Zeichenkette "Borland C++".
Die von dir genannte Adresse hat schon etwas mit den Waffen zu tun,
aber die Bedeutung habe ich leider noch nicht erschlossen.

-Auch nach einen Neustart mit neuer Gruppe arbeitet ein Speer wie eine Wurfwaffe.
(Hm, der Speer war bei der Genereirung schon vorhanden - Firnelf - vielleicht ist das mit einem neugekauften Speer anders?)
EDIT: Nein. Der neugekaufte Speer ist genauso Wurfwaffe.

Achja, in der Generierung haben die Helden noch keine Gegenstände. Die bekommen sie erst wenn sie in die Gruppe aufgenommen werden.

[Arbosh]

Hatte heute mal was ganz exotisches: Die Dosbox fror mit komplett ein und im Logfenster erschien viel zu viele Meldungen das dieser und jener Held etwas gegessen hätte:

Aktuelles Gruppenvermoegen = 1056D 3S 6H
Setze Gruppenvermoegen = 1060D 7S 6H
Dungeon "Eine Piratenhoehle" verlassen
Stadtindex: 0x080a
Typindex: 0x002f
random(100) = 29
random(100) = 59
random(100) = 94
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO trinkt etwas
HJALDA trinkt etwas
GADAN trinkt etwas
CUFUR trinkt etwas
KORVO trinkt etwas
HJALDA trinkt etwas
GADAN trinkt etwas
CUFUR trinkt etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
KORVO isst etwas
HJALDA isst etwas
GADAN isst etwas
CUFUR isst etwas
HJALDA isst etwas
HJALDA isst etwas
HJALDA isst etwas

Das Szenario war dabei, dass ich aus der Piratenhöhle auf Manrek rauskam und ich dabei (wie immer) automatisch nach Brendhil weiterwanderte (ich kam aus Manrin). Das Bild fror dann aber noch auf dem Kartenbildschirm ein. Geistesgegenwärtig habe ich noch den GDB mal einen Backtrace machen lassen, vielleicht hilfts:

#0 0x08322988 in M302de::get_item_pos (hero=0xb55508b6 "HJALDA", item=23) at seg002.cpp:3132
#1 0x0831eb82 in M302de::herokeeping () at seg002.cpp:1559
#2 0x0831f7f5 in M302de::timewarp (time=180) at seg002.cpp:1829
#3 0x0830a5a8 in seg002 (offs=15526) at schick_m302de.cpp:1085
#4 0x08314aae in schick_farcall_v302de (segm=1310, offs=15526) at schick_m302de.cpp:5008
#5 0x082ffa3d in schick_callf (selector=1728, offs=15526) at schick.cpp:309
#6 0x08054c0b in custom_callf (cs=1728, ip=15526) at custom.cpp:75
#7 0x0805bde4 in CPU_CALL (use32=false, selector=1728, offset=15526, oldeip=1262) at cpu.cpp:1072
#8 0x0807f4aa in CPU_Core_Normal_Run () at core_normal/prefix_none.h:564
#9 0x0804dcae in Normal_Loop () at dosbox.cpp:133
#10 0x0804e13a in DOSBOX_RunMachine () at dosbox.cpp:245
#11 0x08055049 in CALLBACK_RunRealInt (intnum=33 '!') at callback.cpp:106
#12 0x082f88b3 in DOS_Shell::Execute (this=0xa561798, name=0xbffd34a4 "schickm", args=0xbffd452f "") at shell_misc.cpp:492
#13 0x082f153a in DOS_Shell:oCommand (this=0xa561798, line=0xbffd452f "") at shell_cmds.cpp:153
#14 0x082eea1c in DOS_Shell:arseLine (this=0xa561798, line=0xbffd4528 "schickm") at shell.cpp:251
#15 0x082eee90 in DOS_Shell::Run (this=0xa561798) at shell.cpp:329
#16 0x082efa4f in SHELL_Init () at shell.cpp:653
#17 0x082e8bba in Config::StartUp (this=0xbffd56e4) at setup.cpp:853
#18 0x0817a9cc in main (argc=1, argv=0xbffd57e4) at sdlmain.cpp:1868

Ich weiß nicht obs etwas damit zu tun hat, da ich schon öfter folgendes beobachtet habe (und ich nicht weiß ob es eventuell ein Originalbug ist): Im manuellen Kampf kommt es manchmal vor, das wenn man "Alte Optionen" wählt, dieser Eintrag verschwindet und das Menü immernoch dasteht.

[HenneNWH]

Puh,

da habe ich sicher in der herokeeping() - Funktion eine Bedingung falsch interpretiert. Das werde ich umgehend beheben.
Danke fürs reporten.

Mir wird langsam klar, dass ich eine Möglichkeit brauche, den von mir erstellten Code mit dem Original zu vergleichen
damit solche Bugs nicht mehr so oft auftreten.

Zu deiner Frage mit dem "Alte Option"-Menüeintrag:
Beim Auswählen dieses Eintrages wird die letzte Handlung nochmal ausgeführt (z.B. Angriff).
Kann die Handlung nicht mehr ausgeführt werden, weil der Gegner geflohen ist,
wird das Kampfmenü nochmal ohne diese Option angeboten.

Deckt sich das mit dem was Du meinst?
Ich halte das für Absicht, aber man hätte auch noch eine Meldung wie "Das geht leider nicht mehr." ausgeben können.

[Rabenaas]

Back-to-back-Tests wären theoretisch einer Möglichkeit, die sich gut in den Aufruf Deiner externen Funktionen einbauen ließe. Allerdings besteht das Problem der Seiteffekte, also Zugriffe auf Heap und globale Variablen. Die müsste man irgendwie loggen.

[HenneNWH]

Ich hätte eher an eine statischere Testmethode gedacht.

Grob:
Da ich den passenden Kompiler "Borland C++ 3.1" da habe, kann ich mir von meinem Code OBJ-Dateien
bauen lassen. Der Code in den OBJ-Dateien muss dann in der SCHICKM.EXE zu finden sein.

Details:
In den OBJ-Dateien sind viele Informationen noch nicht in den Code eingetragen, z.B. die Adresse von externen Funktionen
bei CALLS oder die Adressen im Datensegment.
Es müssten die OP-Codes einer Funktion verglichen werden, Adressen von Sprungbefehlen und globalen Variablen müssten ignoriert werden.

Wenn das auf diese Art gemacht werden würde, wäre es sogar möglich aus meinem Code wieder eine DOS-Version von Schick zu bauen,
die 1:1 den gleichen Code enthält. Das wäre imho der eindeutige Beweis, das ich alles richtig gemacht habe.

[Rabenaas]

Das wäre natürlich die fast perfekte Dekompilierung. (Abgesehen von Formatierung und Bezeichnern.) Allerdings veränderst Du ja die Quellen, behebst Fehler, verbesserst vllt auch Algos. Außerdem macht der Vergleich auch wieder Mühe. Ich würde eine weniger perfekte, aber dafür automatisierbare Möglichkeit vorziehen.

EDIT: Und ist eigentlich bei Schick die Compileroptimierung ausgeschaltet? Sonst müsste man die auch noch reproduzieren.

[Arbosh]

Zu deiner Frage mit dem "Alte Option"-Menüeintrag:
Beim Auswählen dieses Eintrages wird die letzte Handlung nochmal ausgeführt (z.B. Angriff).
Kann die Handlung nicht mehr ausgeführt werden, weil der Gegner geflohen ist,
wird das Kampfmenü nochmal ohne diese Option angeboten.

Deckt sich das mit dem was Du meinst?
Ich halte das für Absicht, aber man hätte auch noch eine Meldung wie "Das geht leider nicht mehr." ausgeben können.

Deckt sich leider nicht, der Gegner war in diesen Fällen immer noch da. Bei toten Gegnern kommt ja korrekterweise auch die Meldung "Hier brauchst du keine Kraft mehr zu verschwenden".

[HenneNWH]

Das Verändern und Fehlerbeheben habe ich _fast_ immer in PreProzessor-Bedingungen gepackt, damit man meine Änderungen auch abschalten
und ich sie schneller wiederfinden kann.

Mit etwas Brainpower ist diese Variante auch automatisierbar.

Eines Vorweg: Was ich jetzt schreibe ist nicht wirklich fundiert, da ich Compilerbau noch nicht hatte.

Die Optimierung von "BC++3.1" hat 13 Schalter mit 2 Zuständen und 2 Schalter mit 3 Zuständen,
also ca 72.000 verschiedene Möglichkeiten, die für jede C-Datei gesetzt werden können.
Wenn ich BC-Code mit dem von Schick, per Auge vergleiche kann ich aber schon gut abschätzen
an welchem der Knöpfe ich drehen muss. Das ist noch etwas Handarbeit, aber machbar.
Mittlerweile weis ich ja ganz gut was der BC so ausspuckt.

[HenneNWH]

Soo,

es ist sehr wahrscheinlich, dass der Bug jetzt gefixt ist.

Anbei ein paar neue Funktionen:

• Prüfen ob ein Gegenstand in die Hand genommen werden kann (2-Hand Waffen)
  
• Ermitteln der am längsten noch brennenden Lichtquelle (Laterne/Fackel)
  
• Mehrere Tavernenfunktionen, die mit den Informanten zusammenhängen
  
• Essen und trinken während Gesprächen (Taverne)
  
• Wenn man in einer Stadt in eine Schlägerei gerät und die Wachen/Mob dazwischengehen
  
• Die Abfrage, ob man eine Berghütte betreten möchte
  

[Obi-Wahn]

Und eine neue Version für die Windows-Nutzer.

Ich versuche jetzt auch mal wieder ein bisschen öfters mit BrightEyes zu spielen und ich bin bisher noch auf keine Bugs gestoßen. (Bin aber noch nicht sonderlich weit)

[Arbosh]

Zu deiner Frage mit dem "Alte Option"-Menüeintrag:
Beim Auswählen dieses Eintrages wird die letzte Handlung nochmal ausgeführt (z.B. Angriff).
Kann die Handlung nicht mehr ausgeführt werden, weil der Gegner geflohen ist,
wird das Kampfmenü nochmal ohne diese Option angeboten.

Deckt sich das mit dem was Du meinst?
Ich halte das für Absicht, aber man hätte auch noch eine Meldung wie "Das geht leider nicht mehr." ausgeben können.

Deckt sich leider nicht, der Gegner war in diesen Fällen immer noch da. Bei toten Gegnern kommt ja korrekterweise auch die Meldung "Hier brauchst du keine Kraft mehr zu verschwenden".

Habe es gerade mit dem Original-DSA auch gehabt: In der letzten Runde hat jeder Held den Gegner angegriffen und dieser lebte anschließend noch. Beim x-ten Auswählen von "Alte Optionen" verschwand der Eintrag einfach und ich blieb im Menü und ging über "Angriff" weiter. Das passierte der Reihe nach bei allen Helden. Anschließend wiederholte sich das Spielchen, d.h. nachdem es einmal auftritt das "Alte Optionen" einfach verschwindet kann man es nicht mehr sinnvoll verwenden. Werde das mal noch in den Bug-Thread verlinken.