DOSBox-Patch für Schicksalsklinge

[Hendrik]

So, jetzt habe ich mal einen Extra-Thread aufgemacht für den DOSBox-Patch, damit der RevEng-Thread ein wenig entlastet wird. Könnte einer der Mods vielleicht die entsprechenden Beiträge aus dem Reverse-Engineering-Thread hierher verschieben?

Wenn die gepatchte DosBox sich zwar kompilieren lässt, beim Linken der .o-Dateien aber Fehler auftreten, sind wahrscheinlich alte Objektdateien daran schuld, denen die Symbole aus der schick.o fehlen. Ein einfaches

Code:

make clean ; make

sollte durch Löschen aller Objektdateien und anschließendes Neukompilieren und -Linken dafür sorgen, dass die gepatchte Dosbox sich kompilieren lässt.


Ergänzungen auf Wunsch des Autors:

- In der dosbox.conf muß unter der Gruppe [cpu] core=full eingestellt werden. (Siehe hier).
- Es gibt zum DOSBox-Patch einen Eintrag im FreeDSA-Wiki.
- Die aktuelle Version (Stand: 5.5.2009) des Patches als Windows-Binary findet sich als Attachement an Beitrag #26.

[Zurgrimm]

Könnte einer der Mods vielleicht die entsprechenden Beiträge aus dem Reverse-Engineering-Thread hierher verschieben?

Da die dortigen Beiträge einen früheren Zeitstempel haben, würden sie auch in diesem Thread vor Deinem hiesigen Ausgangsbeitrag landen. Das ist vielleicht nicht so schön. Behelfen wir uns einfach mit einem Link. Im Thread "Reverse Engineering der NLT", ab Beitrag #267 geht es um den Schick-Logger.

Alles weitere dazu dann nur noch hier. Okay?

Wenn die gepatchte DosBox sich zwar kompilieren lässt, beim Linken der .o-Dateien aber Fehler auftreten, sind wahrscheinlich alte Objektdateien daran schuld, denen die Symbole aus der schick.o fehlen. Ein einfaches

Code:

make clean ; make

sollte durch Löschen aller Objektdateien und anschließendes Neukompilieren und -Linken dafür sorgen, dass die gepatchte Dosbox sich kompilieren lässt.

Falls das die Lösung für mein Problem sein soll, verstehe ich nur Bahnhof. Was genau muß ich tun, damit Deine neueste Patch-Version wieder etwas mitloggt? Wie im Reverse-Engineering-Thread in Beitrag #298, 300 geschrieben, bekomme ich damit keinerlei Anzeige mehr.

[Borbaradwurm]

Falls das die Lösung für mein Problem sein soll, verstehe ich nur Bahnhof. Was genau muß ich tun, damit Deine neueste Patch-Version wieder etwas mitloggt? Wie im Reverse-Engineering-Thread in Beitrag #298, 300 geschrieben, bekomme ich damit keinerlei Anzeige mehr.

Nein, das hat nichts mit deinem Problem zu tun, du kompilierst die dosbox.exe ja nicht selbst, oder hab ich das falsch verstanden?

[Zurgrimm]

du kompilierst die dosbox.exe ja nicht selbst, oder hab ich das falsch verstanden?

Nein, das siehst Du ganz richtig. Ich benutze die Version, die Hendrik ins Internet gestellt hat.

Hat denn niemand eine Lösung für das Problem? Und funktioniert es bei den anderen mit der Version?

[Hendrik]

Falls das die Lösung für mein Problem sein soll, verstehe ich nur Bahnhof. Was genau muß ich tun, damit Deine neueste Patch-Version wieder etwas mitloggt? Wie im Reverse-Engineering-Thread in Beitrag #298, 300 geschrieben, bekomme ich damit keinerlei Anzeige mehr.

Nein, das ist (hoffentlich) die Lösung für wee0ouFus Problem und betrifft nur die Leute, die sich mit dem Patch die Dosbox selber kompilieren wollen.

Was Zurgrimms Problem angeht, habe ich gerade eine Änderung gemacht. Wenn die besagte Nachricht "Starte Profiler (reloc ####)" nicht kommt, wird der Profiler gar nicht erst aktiviert. Die Nachricht kommt auch nur, wenn es sich bei der gerade ausgeführten Datei um die "SCHICKM.EXE" handelt. Leider scheint die DosBox je nach Konfiguration die Namen entweder mit Großbuchstaben oder mit Kleinbuchstaben anzugeben. Bisher habe ich das so gelöst, dass sowohl "SCHICKM.EXE" als auch "schickm.exe" als Dateinamen zugelassen waren. Möglicherweise verwendet deine DosBox eine Mischform, deshalb habe ich jetzt alle Varianten zugelassen.
Probleme gibt es noch bei den Near-CALLs, mit denen Talent-, Zauber- und ein Teil der Zufalls-Proben aufgerufen werden. Hier gibt es Aufrufe aus unterschiedlichen Segmenten, was bei Near-CALLs eigentlich unmöglich sein sollte. Effekt: Es kann unter Umständen zu falschen Positivmeldungen kommen, dass also ein Aufruf der Random-Funktion angezeigt wird, obwohl keiner stattgefunden hat. Ist mir aber beim Testen noch nicht passiert.

Die neue Version befindet sich als Patch im SVN-Repository und als vorcompilierte Windows-Binary hier.

Viel Spaß damit
Hendrik

[Zurgrimm]

Möglicherweise verwendet deine DosBox eine Mischform, deshalb habe ich jetzt alle Varianten zugelassen.

Daran wird es wohl gelegen haben. Meine DOSBox startet schick.EXE. Mit der neuen Version funktioniert es problemlos.

Allerdings werde ich aus den Random-Abfragen, die ich jetzt angezeigt bekomme, noch nicht ganz schlau. An der Stelle in der Zwingfeste, kurz hinter dem Eingang, wo es zu einem Kampf kommen kann, wird bei jedem Betreten eine Abfrage angezeigt, der Form "random(100) = ZAHL". Statt ZAHL steht dort natürlich ein Wert (ich nehme an von 1 bis 100). Ich bin nun mehrfach drübergelaufen. Bei Werten von 25 bis 92 fand der Kampf nicht statt. Bei Wert 7 kam es zum Kampf. Wenn da jetzt eine Random(100)-Abfrage kommt, woran sehe ich dann, wie hoch die Wahrscheinlichkeit ist, daß ein Ereignis stattfindet?

Im Kampf gab es dann mehrere "Random(7)"-Abfragen (wahrscheinlich, welcher Held als nächstes dran ist). In Thorwal hatte ich einmal eine "Random(10)"-Abfrage. Ich nehme also an, daß die Zahl in Klammern hinter dem "Random" einfach bedeutet, mit was für einem Würfel geworfen wird (hier W10, W7 oder W100).

Als der Kampf begann, kam eine Anzeige, die "randomInterval 0 - 1 : random(7) = 7" lautete. Was das heißt, ist mir nicht klar, ich vermute aber, daß RandomInterval irgendwie festlegt, ob der Gegner beginnt oder ob meine Leute beginnen.

[wee0ouFu]

Schon besser, der Patch wirkt so ungeheuer nützlich, daß der RE-Thread gehörig vom Thema abgekommen ist. Es scheint an der Zeit, einen Freedsa-Bugzilla aufzusetzen, für Probleme mit dem Code im Trunk sowie mit eigenen Abteilungen für die vielen Bugs in den NLT-Titeln selbst. Die gehören schließlich in einem anständigen Remake ebenfalls implementiert ... Soviel vorweg.

Wenn die gepatchte DosBox sich zwar kompilieren lässt, beim Linken der .o-Dateien aber Fehler auftreten, sind wahrscheinlich alte Objektdateien daran schuld, denen die Symbole aus der schick.o fehlen. Ein einfaches

Code:

make clean ; make

sollte durch Löschen aller Objektdateien und anschließendes Neukompilieren und -Linken dafür sorgen, dass die gepatchte Dosbox sich kompilieren lässt.

An alten .o-Files ist der Linker offensichtlich nicht gescheitert, schließlich hatte ich den Vanilla-Tarball frisch entpackt und gepatcht. Aber ich habe es dennoch erneut versucht, auch mit dem unmittelbar vor diesem Post verkündeten Patch -- keine Besserung. Dosbox habe ich in der letzten Stunde mittlerweile sechs mal zu bauen versucht ... ohne Patch geht das auch. Google weiß auch keinen Rat. Allerdings hatte ich schon einmal ein Linkerproblem, das unter Debian häufiger auftritt, betraf damals aber Freetype. Kann es sein, daß man hier noch irgendein Flag nachliefern muß? Mal bitte die Hände hoch, bei wem sich Dosbox umstandslos patchen ließ!

[Zurgrimm]

Ich habe jetzt ein paar belanglose Tests in der Zwingfeste durchgeführt. Eine Art "False positive" scheint es dann zu geben, wenn ein Zufallskampf an einer Stelle bereits stattgefunden hat. Dann zeigt der Logger dennoch eine "Random(100)"-Abfrage an. Weder bei 1 noch bei 100 (das habe ich jeweils ausprobiert) oder irgendeinem Wert dazwischen (das ist meine Vermutung) geschieht aber etwas.

Zu wissen, wo Zufallsabfragen stattfinden, ist schonmal extrem nützlich. So habe ich in der Zwingfeste eine weitere Stelle mit einem Zufallskampf ausmachen können. Bei all meinen Tests hatte ich ihn dort nie, weil offenbar die Wahrscheinlichkeit sehr gering ist. Wenn man aber mutwillig extrem oft über dieses eine Feld läuft, passiert es eben doch irgendwann.

Jetzt weiß ich auch, wie das mit dem Schloßknacken der Türe zur 3. Ebene der Zwingfeste ist: Es handelt sich um eine Schlösser knacken Probe +90. Kein Wunder, daß die mein Schloßknacker nicht hinbekommt. Damit ist es auch nahezu ausgeschlossen, daß man es auf höheren Stufen leichter schafft, denn selbst mit einem Wert von +18, handelte es sich noch um eine effektive Erschwernis von 72. Das ist nur mit einem Doppel-1er-Wurf zu schaffen, würde ich sagen. Der Foramen ist an der Stelle nur um 8 erschwert, das kann schon eher gelingen.

An der Stelle auf der 4. Ebene, wo man unter den 2 Mauerstücken hinfurchtauchen muß, wird entgegen meiner Vermutung tatsächlich auf Schwimmen geprobt, mit einer Erschwernis um 8. - Unglaublich, wieviel man da innerhalb kurzer Zeit herausbekommen kann!

[Hendrik]

Mal ein wenig zur Anwender-Dokumentation des Patches:

1.) Wie bereits erwähnt, zeigt die Zeile "Starte Profiler (reloc ####)" an, dass der Profiler benutzt wird. Die angezeigte Reloc-Adresse ist eher technischer Natur, daher gehe ich hier nicht weiter darauf ein.
2.) Aufrufe des Zufallsgenerators werden mit

Code:

random(X) = Y

angezeigt, was einem Wurf mit einem X-seitigen Würfel (von 1 bis X beschriftet) mit dem Ergebnis Y entspricht. Die Anzeige random(100) = 92 besagt also, dass eine Zufallszahl von 1 bis 100 angefragt wurde und eine 92 zurückgegeben.
3.) Die Funktion RandomInterval(X,Y) gibt eine Zufallszahl zurück, die zwischen X und Y liegt (einschließlich der Grenzen selbst). Dazu wird die Random-Funktion mit X+Y+1 aufgerufen und dann X hinzuaddiert. Der Patch zeigt das so an, dass zunächst "RandomInterval X - Y: " ausgegeben wird und anschließend der Aufruf der Random-Funktion.

Code:

RandomInterval X - Y: random(X+Y+1)=Z

Das hat den Nebeneffekt, dass Z nicht das Ergebnis von RandomInterval darstellt, sondern von Random. Das Ergebnis von RandomInterval ergibt sich aus X+Z.
4.) Es gibt noch die selten genutzte Funktion

Code:

wuerfel NwM+x

, die einen Wurf von N M-seitigen Würfeln und anschließendes Addieren von X darstellen soll. Hier wird momentan noch kein Endergebnis ausgegeben, sondern die einzelnen Würfelwürfe (mittels Random(M)-Aufrufen) dargestellt.
5.) Die Darstellung von Eigenschaftsproben sollte klar sein.
6.) Für Talentproben werden zunächst der Name des geprüften Helden, das geprüfte Talent und die Erschwernis angegeben. Anschließend folgen die drei Leiteigenschaften der Probe und die "effektive Erschwernis", die dem Talentwert minus der Erschwernis entspricht. Schließlich folgen die drei W20-Würfe der Probe. Insgesamt sieht das etwa so aus:

Code:

Talentprobe HELDENNAME: AbgefragtesTalent +Erschwernis ->(E1/E2/E3)+ETW W1 W2 W3

, wobei E1,E2 und E3 die drei Leiteigenschaften der Probe sind, W1-W3 die Würfelergebnisse für diese Eigenschaft und ETW der effektive Talentwert.
7.) Neben den beiden Funktionen für Talent- und Zauberproben gibt es noch eine dritte Funktion, die sich des Probenwürfel-Mechanismus bedient. Wann diese Funktion aufgerufen wird und was sie bewirkt, weiß ich nicht. In der Tat habe ich noch nicht ein einziges Mal einen Aufruf geloggt. Sollte diese Funktion auftauchen, wird das durch

Code:

?-Probe[0x####:0x####] ...

dargestellt. Wer so etwas findet, bitte hier die komplette Zeile posten, am besten mit ein paar Zeilen Kontext drumherum und einer Beschreibung, unter welchen Umständen der Aufruf erfolgte.

@Zurgrimm: Der von dir erwähnte "false positive" bei schon stattgefundenen Zufallskämpfen ist kein false positive in dem Sinne, wie ich es bei den Anmerkungen zum letzten Patch meinte. Da wird offenbar erst gewürfelt und dann gefragt, ob das Ergebnis überhaupt gebraucht wird . Kleiner Lapsus der Programmierer, wie mir scheint. False Positives im Sinne des Loggers zeichnen sich eher durch völlig unsinniges Auftreten aus, wenn z.B. ein Heldenportrait verschoben wird, der Char umbenannt wird o.ä. (Anmerkung: Diese Fälle sollen nur als Beispiele dienen. Ich habe nicht geprüft, ob in solchen Fällen tatsächlich ein false positive auftritt oder nicht). Außerdem haben False Positives oft "merkwürdige" Zahlen als Parameter und Rückgabewert. Ein Aufruf wie "random(17264) = -80" wäre so ein Kandidat.

[Zurgrimm]

Erstmal danke für die Dokumentation. Das ist zwar alles nicht ganz unkompliziert, aber sicher sehr nützlich.

2 Fragen bleiben mir noch:

1) Wozu wird RandomIntervall üblicherweise genutzt? Wenn ich RandomInterval: 1-2 habe, dann wird eine Zufallszahl zwischen 1 und 2 ausgegeben. Aber dasselbe würde doch ein eine Random(2) Abfrage bringen. Was ist der Unterschied für die Ergebnisermittlung?

2) Sehe ich das richtig, daß bei den Random-Abfragen im Gegensatz zu den Talent- und Zauberproben nicht ersichtlich ist, ab welchem Wert ein Ereingnis stattfindet, wann also die Probe "positiv" ausfällt?

Bei Talent- und Zauberproben ergibt sich das ja daraus, daß (W1 + W2 + W3 + ETW) - (E1 + E2 + E3) mindestens 0 sein muß. Eine solche Rechnung kann ich bei den Random-Abfragen nicht machen, weil ich den Zielwert nicht kenne.

Wenn ich das richtig sehe: Besteht eine Chance, daß soetwas in einer späteren Version noch eingebaut werden könnte? Denn mit welcher Wahrscheinlichkeit ein Ereignis auftrittt, wäre natürlich auch schon interssant zu erfahren.

[Hendrik]

1) Wozu wird RandomIntervall üblicherweise genutzt? Wenn ich RandomInterval: 1-2 habe, dann wird eine Zufallszahl zwischen 1 und 2 ausgegeben. Aber dasselbe würde doch ein eine Random(2) Abfrage bringen. Was ist der Unterschied für die Ergebnisermittlung?

Der Unterschied ist, dass Random(X) immer von 1 bis X geht. Bei RandomInterval kann die untere Schranke ebenfalls angegeben werden, es sind also Anfragen wie "gib mir eine gleichverteilte Zufallszahl von 6 bis 18" möglich. RandomInterval bedient sich zum Ausrechnen dabei der Random-Funktion.

2) Sehe ich das richtig, daß bei den Random-Abfragen im Gegensatz zu den Talent- und Zauberproben nicht ersichtlich ist, ab welchem Wert ein Ereingnis stattfindet, wann also die Probe "positiv" ausfällt?
Wenn ich das richtig sehe: Besteht eine Chance, daß soetwas in einer späteren Version noch eingebaut werden könnte? Denn mit welcher Wahrscheinlichkeit ein Ereignis auftrittt, wäre natürlich auch schon interssant zu erfahren.

Richtig. Random gibt einfach nur ein Würfelergebnis zurück, was das Programm (SCHICKM.EXE) weiterhin damit macht, kann der Logger nicht sagen.
Dass ich so etwas später mal einbaue, ist durchaus möglich. Die Random-Abfrage wird von etwa 130 verschiedenen Stellen im Code aufgerufen, davon habe ich momentan etwa 5 abgedeckt. Es könnte durchaus sein, dass es eine Funktion "Gib mir eine Ja/Nein-Entscheidung zurück mit der Wahrscheinlichkeit X:Y", und dann geht so etwas auch. Garantieren kann ich aber nix, das hängt davon ab, wie Attic das damals programmiert hat.

[Hendrik]

Zukünftige Features

In Zukunft werde ich sicherlich weiter an dem Logger arbeiten. Folgende Ergänzungen sind dabei vorgesehen:

• Patches für Sternenschweif und Riva: Für Sternenschweif habe ich schon begonnen, die Adressen der Funktionen herauszusuchen. In Riva müsste dies noch geschehen. Dann steht ähnlichen Patches für Schweif und Riva nichts mehr im Wege. Fraglich ist allerdings, ob ich alle drei Logger in einen Patch kombiniere oder jeweils einen eigenen.
  Status: Zumindest der Sternenschweif-Patch könnte recht bald kommen, bei Riva kann es auch länger dauern.
  
• Weitere Funktionen aufdecken: Wie ich im vorigen Beitrag schon angemerkt habe, will ich versuchen, noch tiefer in die Spielmechanik einzudringen. Dazu werde ich, von den bisherigen Funktionsaufrufen ausgehen, mich rückwärts durch den Programmablauf arbeiten und weitere Funktionen identifizieren. Das könnte z.B. die "Zufallsereignis in der Stadt"-Funktion oder die "Zufallskampf im Dungeon"-Funktion sein.
  Status: Kommt peu-a-peu mit den nächsten Versionen.
  
• Dokumentation des Kampfablaufes: Der Ablauf eines Kampfes ist recht kompliziert. Außerdem bestehen einige Unklarheiten bezüglich des genauen Ablaufes. (1.) gibt es bisher keine sicheren Erkenntnisse dazu, was die Einstellungen "agressiv/normal/vorsichtig" wirklich tun, (2.) ist die Bestimmung der Reihenfolge im Kampf noch unklar und (3.) war da ja auch noch die Diskussion, ob das Kriegskunst-Talent da irgendwo eine Rolle spielt (ohne notwendigerweise eine Probe auf selbiges zu würfeln, was der Logger ja jetzt schon mitbekommen würde).
  Leider ist der Kampfablauf auch recht kompliziert programmiert, so dass es sicher eine Weile dauert, bis ich die einzelnen Würfelwürfe in einem Kampf richtig zuordnen kann.
  Status: Steht erst einmal hinten an, weil es schwierig ist und nicht so lohnenswert. Wenn allerdings genug Leute mich dazu überreden, würde ich mich mal dran versuchen.
  
• Beeinflussen des Zufallsgenerators: Wäre ein nettes Feature, von dem ich noch nicht weiß, wie ich's machen soll. Man könnte so eine Art Debug-Modus einschalten, bei dem vor jedem Zufalls-Wurf gefragt wird, ob man das Ergebnis der Zufallsgenerators akzeptieren will oder lieber selbst eine Zahl eingeben.
  Status: Schwer zu sagen. Eventuell geht es ganz fix, wahrscheinlich ist aber, dass es länger dauert. Eigentlich halte ich es auch nicht für so wichtig, dass es großen Aufwand lohnt.
  
• Überwachen von Speicherzugriffen: Theoretisch müsste es möglich sein, den Zugriff auf bestimmte Speicheradressen durch Anzapfen der Funktionen in mem.h zu überwachen. Damit könnte man garantiert ausschließen, dass irgendein(e) Talent/Zauber/Eigenschaft/Gegenstand in einer bestimmten Situation vom Spiel abgefragt wird.
  Status: Steht erst mal weiter unten auf der Prioritätenliste, weil im Moment die Überwachung der Funktionen mehr Erkenntnisse bringt. Außerdem ist eine solche Überwachung nur schwer portierbar, so dass es vermutlich nur bei mir laufen würde.
  

Für weitere Vorschläge und Anregungen bin ich dankbar.
Hendrik

[Zurgrimm]

(1.) gibt es bisher keine sicheren Erkenntnisse dazu, was die Einstellungen "agressiv/normal/vorsichtig" wirklich tun,

Hm... gibt es ernstliche Gründe, an den Erkenntnissen aus dem Thread "Unterschied im Angriff "Aggressiv" "Normal" "Vorsichtig"" zu zweifeln?

(2.) ist die Bestimmung der Reihenfolge im Kampf noch unklar

Da bevor ein Held an die Reihe kommt immer eine Random(7)-Abfrage gestartet wird, würde ich hier auf eine reine Zufallsabfrage tippen. Die Frage ist dann natürlich, was bei einer 7 (die für den evtl. nicht vorhandenen NSC stehen dürfte) passiert. Mit RandomInterval: 1-2 wird vermutlich festgelegt, ob zuerst die eigenen oder die gegnerischen Figuren an der Reihe sind. Aber ganz sicher wissen wir das freilich noch nicht.

Ich persönlich fände momentan die Punkte "Weitere Funktionen aufdecken" und "Dokumentation des Kampfablaufes" (in der Reihenfolge) am Interessantesten. Aber mach das ruhig, wie Du am meisten Lust hast, denn bis die Möglichkeiten mit der jetzt schon existierenden Version ausgereizt sind, wird ohnehin noch viel, viel Zeit vergehen.

[Hendrik]

(1.) gibt es bisher keine sicheren Erkenntnisse dazu, was die Einstellungen "agressiv/normal/vorsichtig" wirklich tun,

Hm... gibt es ernstliche Gründe, an den Erkenntnissen aus dem Thread "Unterschied im Angriff "Aggressiv" "Normal" "Vorsichtig"" zu zweifeln?

Jein. Prinzipiell bin ich bereit, der Aussage von Fury Glauben zu schenken. Allerdings würde es mich interessieren, wie er die Werte von +5/-5 genau herausgefunden hat. Wenn er die Werte "durch einen Bug" erhalten hat, stellt sich die Frage, ob sie dann korrekt sind und nicht ebenfalls verbuggt.

Da bevor ein Held an die Reihe kommt immer eine Random(7)-Abfrage gestartet wird, würde ich hier auf eine reine Zufallsabfrage tippen. Die Frage ist dann natürlich, was bei einer 7 (die für den evtl. nicht vorhandenen NSC stehen dürfte) passiert. Mit RandomInterval: 1-2 wird vermutlich festgelegt, ob zuerst die eigenen oder die gegnerischen Figuren an der Reihe sind. Aber ganz sicher wissen wir das freilich noch nicht.

Das ist auch meine Vermutung. Dennoch hätte ich darüber lieber Gewissheit, zumal es ganz anders als das Verfahren im P&P (alle kommen in der Reihenfolge ihrer MU-Werte dran) ist. Da hilft vermutlich nur eine sorgfältige Durchsicht des Assembler-Codes.

[Borbaradwurm]

Für weitere Vorschläge und Anregungen bin ich dankbar.

Nicht die Savegame-Flags (sowas wie z.B. Fluch der Hyggelik Ruine/Verfolger aktiv/Windsbraut Timer/usw.) der drei Spiele vergessen.

[Zurgrimm]

Allerdings würde es mich interessieren, wie er die Werte von +5/-5 genau herausgefunden hat.

Ich habe die Stelle jetzt nicht mehr wiedergefunden (), aber ich meine zu erinnern, daß der Bug darin bestand, daß wenn man mit dergestalt modifizierten Werten speichert und den Spielstand nach Schweif importiert, die AT-/PA-Verschiebung als dauerhaft erhalten bleibt.

zumal es ganz anders als das Verfahren im P&P (alle kommen in der Reihenfolge ihrer MU-Werte dran) ist.

MU-Wert? Da gibt's doch die INI. Oder war das in DSA 2 bzw. 3 noch anders?

[paule]

MU-Wert? Da gibt's doch die INI. Oder war das in DSA 2 bzw. 3 noch anders?

INI gab es in DSA3 noch nicht. Der Charakter mit dem höchstem MU-Wert hat das Recht, den Kampf zu eröffnen oder einem anderem den Vortritt lassen.

Gruß,
Paul

[Kunar]

Den Zwölfen zum Gruße!

Ich habe die Stelle jetzt nicht mehr wiedergefunden (), aber ich meine zu erinnern, daß der Bug darin bestand, daß wenn man mit dergestalt modifizierten Werten speichert und den Spielstand nach Schweif importiert, die AT-/PA-Verschiebung als dauerhaft erhalten bleibt.

Ja, das ist mir so passiert. Weil meine Helden bis zuletzt aggressiv gekämpft haben, musste ich in Sternenschweif erst einmal mit dem Hexeditor ran.

MU-Wert? Da gibt's doch die INI. Oder war das in DSA 2 bzw. 3 noch anders?

In den früheren Ausgaben wurde die Initiative tatsächlich durch den Mut bestimmt (neben anderen Faktoren wie Überraschung, Anzahl der Gegner usw.). Mut wird sogar explizit im Handbuch (auf der Bestseller-Games-CD) genau diese Eigenschaft zugesprochen.

[Henrik_V]

Entschuldigt die wahrscheinlich dumme Frage. Zumindest die Schicksalsklinge (CD, v3.02) scheint unter DOSBox hier bisher gut zu laufen.

Wozu ist das RE von DOSBox für die NLT nötig?

Hatte geplant, mir die alten Schätze nochmal vorzunehmen. Geht das nicht, wie bei vielen anderen DOS Klassikern mit DOSBox?

[Boneman]

Doch, das geht schon. Der Patch ist nur für die Freaks hier, die alles (und damit meine ich alles) auseinandernehmen und ganz genau wissen wollen. Mit dem Patch kann man Proben und Zufallswürfe im Spiel sichtbar machen, die dann auf der DOSBox-Konsole ausgegeben werden (wenn ich das richtig verstanden habe, denn probiert hab ich's noch nicht).