Schicksalsklinge: Umfassender Bugfix-Patch

[Marcian]

Nein, ich bin nicht böse, thEClaw. Als Erpressung würde ich es nicht sehen wollen und nochmal, ich finde, dass NRS hier großartiges geleistet hat. Und das wollte ich keinesfalls schmälern (und wenn es so rüber gekommen ist, tut es mir leid). Aber dennoch werde ich wohl, da man die meisten repartierten Bugs, wenn man sie denn kennt (und auch dafür ist obige Liste klasse), umgehen kann, es beim ungepatchten Spiel belassen. Prem ist mir zu wichtig...

[NRS]

Das bewusste Ausnutzen von Programmfehlern stellt einen nicht vom Spielentwickler beabsichtigten Spielverlauf und damit Schummeln ("cheat") dar. Dessen Ermöglichung hat in einem Korrekturpatch nichts zu suchen. Allenfalls kann ich noch eine separate, damit dritte, Datei anbieten, welche den 1-AP-Verlust beim Speichern außerhalb von Tempeln entfernt. Das ist zwar streng genommen auch eine Abweichung vom beabsichtigten Spielverlauf, aber in einem annehmbaren Rahmen, weil ganz bewusst eine höchst fragwürdige Spieldesignentscheidung verändert wird.

[Marcian]

Danke NRS, das wäre natürlich klasse, aber mach dir für mich keine Extra-Mühe. Ich scheine ja der einzige zu sein, der sich daran stört. Du hast im Kern natürlich Recht und wenn dein Ansatz ist, ein perfektes ungebugtes Schick zu erstellen, dann musstest du es so tun, wie du es getan hast, keine Frage.

Eine Anmerkung noch: Im Grunde müsste man wohl auch (ich denke, das ist noch nicht geschehen) die wiederholbaren Wildnisevents so abändern, dass sie nur einmal erfolgen. Ich denke an Dinge wie den umgestürzten Baum (ich glaube zwischen Skjal und Ottarje) oder die kaputte Brücke (die bringt ja sogar jedes mal AP). Dürfte kaum so gedacht sein, dass da jedes mal ein umgestürzter Baum liegt oder die Brücke kaputt ist. Und dann auch die Jagdevents. Auch dass jedes mal zwischen Ottarje und Daspota ein Kutter auftaucht, um einen mitzunehmen, ist nicht gerade Realismus pur...

[Lippens die Ente]

Dass Jagdevents öfter als einmal auftauchen können, ist schon realistisch, einige dieser Events sind aber sogar fix und kommen jedesmal, hier wäre wohl ein Zufallsereignis besser. AP kriegt man da auf vielerlei Art, selbst wenn das Schleichen misslingt gibt es Trost-AP. Das sind aber so wenige, dass man sie vernachlässigen kann. Bei der Brücke muss man sagen, dass man die AP ja bezahlen muss, indem man Gegenstände opfern muss.

Ach ja da fällt mir noch was ein:

Den hier wird man wohl nicht beseitigen können.

[Zurgrimm]

Allenfalls kann ich noch eine separate, damit dritte, Datei anbieten, welche den 1-AP-Verlust beim Speichern außerhalb von Tempeln entfernt.

Danke NRS, das wäre natürlich klasse, aber mach dir für mich keine Extra-Mühe. Ich scheine ja der einzige zu sein, der sich daran stört.

Nein, an der Bestrafung für das Speichern störe ich mich auch. Es ist nur eben kein Bug und würde die Speicheroption in Tempeln entwerten, so wie in Schweif und Riva. Aber dafür einen optionalen Extra-Patch zu haben, fände ich nicht schlecht. Würde ich nochmals spielen, würde ich ihn eventuell verwenden.

Das einzige, was mich ein wenig hemmt, ist dieses:

Bitte nur auf ein Originalspiel anwenden, also nicht über frühere Patchversionen drüberinstallieren.

Denn das bedeutet leider, daß man sich zwischen diesem tollen Patch und der Benutzung von Hendrik's Logger, der einem fast alle Proben anzeigt, entscheiden muß. Und die Aufdeckung der Proben ist mir als NLT-Forscher und -Entdecker beim Spielen eigentlich schon wichtig. - Aber das ist ein ganz persönliches Dilemma, das für die breite Masse sicher keine Relevanz hat. (Und für mich derzeit auch nicht, da ich an eine weitere Schick-Partie momentan nicht denke.)

[NRS]

*Seufz*

Hier also auch noch ein Mini-Patch zum Entfernen des 1-AP-Verlusts beim Speichern. Anwendung wie die beiden anderen Patches, nur dass "NOAPLOSS" statt "APPLYFIX" auszuführen ist.

Ich habe nur den Code übersprungen, welcher die AP außerhalb eines Tempels eben abzieht; den Text im Speicherfenster, der dies angekündigt, habe ich nicht entfernt, weil man sonst die SCHICK.DAT auch noch mal neu aufbauen müsste, wodurch es kein Mini-Patch mehr wäre, und das LTX-Format der Spieltexte es nicht zulässt, einfach nur das erste Zeichen durch ein Nullbyte zu ersetzen.

Den hier wird man wohl nicht beseitigen können.

Grundsätzlich wohl schon, nur wäre dann zu klären, ob beim Umkehren vom Umkehren generell bereits ausgelöste Reiseereignisse, die auf der jeweiligen Strecke fest vorgesehen sind, nochmals ausgelöst werden sollen, oder eben nur dieses eine. Ersteres könnte Nebenwirkungen haben, die einem auf den ersten Blick nicht bewusst sind.

[Alrik Alrikson]

Um nochmal auf meine Frage des Erstaufstehenden im Nachtlagerkampf zurückzukommen: Ist es technisch nicht problemlos einstellbar, dass der Wachhabende (sofern er tatsächlich wach ist) als erster der Helden zum Zug kommt?

[Zurgrimm]

*Seufz*

Tja, so ist das. Wenn man den Leuten den kleinen Finger reicht ...

Hier also auch noch ein Mini-Patch zum Entfernen des 1-AP-Verlusts beim Speichern.

Danke dafür. Ich finde es schon hervorragend, daß es solch einen Patch gibt. Bei Speichereinschränkungen ist für mich eigentlich immer die einzige Stelle, wo ich bei Spielen ohne schlechtes Gewissen (und damit ohne Spielspaßverlust) cheate, wenn es die Möglichkeit gibt. Vielleicht geht anderen das ja ebenso.

[NRS]

Um nochmal auf meine Frage des Erstaufstehenden im Nachtlagerkampf zurückzukommen: Ist es technisch nicht problemlos einstellbar, dass der Wachhabende (sofern er tatsächlich wach ist) als erster der Helden zum Zug kommt?

Wenn es problemlos einstellbar wäre, hätte ich es schon gemacht.

[Alrik Alrikson]

Um nochmal auf meine Frage des Erstaufstehenden im Nachtlagerkampf zurückzukommen: Ist es technisch nicht problemlos einstellbar, dass der Wachhabende (sofern er tatsächlich wach ist) als erster der Helden zum Zug kommt?

Wenn es problemlos einstellbar wäre, hätte ich es schon gemacht.

Nagut, dann betrachte es als Herausforderung.

[Lippens die Ente]

sowas wie Initiative gibt es in der NLT nicht, die Reihenfolge scheint jede Kampfrunde zufällig ausgewürfelt zu werden.

[NRS]

Nagut, dann betrachte es als Herausforderung.

Nein, ich betrachte es als Zeitverschwendung.

[Zurgrimm]

sowas wie Initiative gibt es in der NLT nicht, die Reihenfolge scheint jede Kampfrunde zufällig ausgewürfelt zu werden.

Ob es Initiative gar nicht gibt, weiß ich nicht. Hendrik's Logger bestätigt aber die Vermutung, daß da zu Beginn jeder Kampfrunde ein Zufallselement im Spiel ist. Denn da finden eine ganze Reihe von Abfragen statt.

Das von Alrik angesprochene Problem hat aber ja auch mit der Initiative wenig zu tun. Dabei geht es ja vielmehr darum, nach dem Ergebnis der Nachtwache richtig festzulegen, welcher Held wach ist und welche Helden schlafen. Ein wohl der Programierer-Intention entsprechend sinnvolles System wäre es insoweit, daß immer derjenige Held zu Kampfbeginn wach ist, der Wache gehalten hat, es sei denn er ist während der Wache eingeschlafen; dann wäre gar kein Held zu Kampfbeginn wach. Wer von den wachen Helden oder den Gegnern dann in welcher Reihenfolge dran ist, bleibt eine gänzlich andere Frage.

Persönlich fand ich allerdings ohnehin schon immer, daß es den Zweck einer Nachtwache ein gutes Stück weit verfehlt, wenn trotzdem bei einem Angriff auf das Lager zunächst nur die Wache allein kämpfen kann. Wer ordentlich Wache hält, sollte eine Gefahr so rechtzeitig erkennen, daß er seine Kameraden noch wecken oder zumindest laut rufen kann, damit diese aufwachen, wenn es zum Kampf kommt. Daß die Helden noch schlafen wäre eigentlich eher etwas für den Fall, daß niemand Wache gehalten hat oder der Wachhabende dabei eingeschlafen ist. - Aber das war offenbar nicht so gewollt, ist also hinzunehmen. Das Wachehalten verringert ja in Schick offenbar die Wahrscheinlichkeit, nächtens überhaupt angegriffen zu werden (was durchaus sinnvoll ist) und hat damit schon eine Wirkung.

Wie dem auch sei, wenn für Kämpfe gar nicht gespeichert wird, wer gerade Wache hält und ob dies erfolgreich der Fall ist, dann kann man das wohl auch nicht abfragen.

[Marcian]

Zunächst mal danke für den "Extra-Patch". Beim nächsten Durchgang werde ich den dann gerne nutzen!

Zur Frage der Nachtwache: Zunächst ist es unsinnig, dass die Helden offenbar in voller Rüstung schlafen, immerhin sind sie sofort kampfbereit, wenn sie aufwachen. Bei einem Hemd als Rüstung ja, aber in einem Kettenhemd würde wohl kaum jemand ein Auge zutun.

Davon abgesehen würde ich mir folgendes System wünschen:

I. Wenn gar keine Wache aufgestellt wird und es kommt zu einem Nachtkampf sollte eine verschärfte Sinnensschärfe-Probe gewürfelt werden,

1. gelingt sie, wacht einer auf und der Kampf geht wie gewohnt weiter.

2. Misslingt sie aber, sollten die Helden schlicht tot sein. Denn dass vier Orks (mal als Beispiel) nicht in der Lage sein sollte, schlafenden Helden die Kehle durchzuschneiden, ist sinnfrei.


II. Ist eine Wache aufgestellt worden sollte eine Selbstbeherrschungsprobe gewürfelt werden (ggf. auch mehrfach und ggf. je nach Zeit/Zustand des wachehabenden Helden verschärft).

1. Misslingt sie, schläft der Wachhabende ein und es geht wie bei I. weiter, das heißt zweite Chance durch Sinnesschärfe (ggf. leichter, als wenn man von vorneherein schläft), bei misslingen sofortiger Exitus.

2. Gelingt die Selbstbeherrschungsprobe dagegen, sollte der wachhabende Held dann in der Lage sein, bei einem Überfall (ggf. nach einer Gefahrensinn oder Sinnesschärfe-Probe) einen Teil oder gar die gesamte Gruppe rechtzeitig zu wecken.


Da schwierig zu programmieren aber alles wohl nur Wunschkonzert meinerseits...

[Obi-Wahn]

Wow, ein beeindruckende Liste an behobenen Bugs! Danke, NRS!

Wärst du eigentlich bereit oder wäre es überhaupt möglich die Bugfixes Stück für Stück in BrightEyes zu übernehmen? Leider scheint HenneNWH im Moment nicht so aktiv zu sein.

[NRS]

Bereit? Ja, aber erst, wenn BrightEyes so vollständig ist, dass ich eine unabhängig lauffähige SCHICKM.EXE kompilieren kann. Möglich? Nur die Korrekturen, die nicht mit einer Änderung an SCHICK.DAT einhergehen. Die BrightEyes-Vorgehensweise, Änderungen an SCHICK.DAT im laufenden Betrieb ("on the fly") vorzunehmen, heiße ich nicht gut.

[Obi-Wahn]

Danke für die Info!

[gaor]

Henne hat seit dem Frühjahr im Zusammenhang mit Bright-Eyes nicht mehr von sich hören lassen. Ich bin sicher, er hat seine Gründe.

Zur Nachtwache und der Kampfinitiative kann ich sagen, dass beides schon komplett in Bright-Eyes "übersetzt" wurde.

1) Es gibt eine Logik, nach der entschieden wird, ob die Helden oder die Gegner den ersten Zug machen dürfen. In der Regel wird vor dem Kampf passend zum Ereignis (üblicherweise je nachdem, wer Angreifer ist) deterministisch entschieden, wer anfangen darf. Bei Angriffen während des Nachtlagers haben beispielsweise immer die Gegner die Initiative.

2) Wenn entschieden sein sollte, dass zu irgendeinem Zeitpunkt im Kampf (also auch beim ersten Zug) die Helden an der Reihe sind, wird immer und ohne Ausnahme ausgewürfelt, welcher Held dran ist (siehe `FIG_choose_next_hero` in seg032). Ausgewürfelt wird natürlich nur zwischen Helden, die anwesend sind und in der aktuellen Runde nicht bereits dran waren.

3) Nachdem entschieden ist, welcher Held am Zug ist, wird geprüft, ob er wach ist. Sollte er schlafen (und nicht tot sein), wird er mit 75%iger Wahrscheinlichkeit geweckt.

Euer Wunsch, dass immer der wachhabende Held der erste unter den Held sein sollte, der am Zug ist, könnte natürlich eingebaut werden, weil ja volle Verfügung über den Code existiert. Aber ein einfacher Patch, wo eine handvoll Bytes geändert werden, wird das nicht sein. Und mehr als das wurde ja bisher im Rahmen des Bright-Eyes-Projekts noch nicht in Betracht gezogen, weil man erstmal die Code-Basis vollenden will.

Übrigens: Die Chance, trotz Wache überfallen zu werden, liegt bei 10% (ggü. 60% ohne Wache) [Prozentangaben dank Hinweis von NRS nachträglich korrigiert]. Und wenn erstmal entschieden ist, dass trotzdem ein Überfall stattfindet, läuft nach aktueller Implementierung alles genauso ab, als hätte es keine Wache gegeben (wenn ich nicht irgendwas übersehen habe).

NACHTRAG: Achso, nochmal zu der Anmerkung von NRS, dass die SCHICK.DAT nicht "on-the-fly" verändern möchte: Da liegt wohl ein Missverständnis vor. Henne hat sich dazu noch nie so eindeutig geäußert, glaube ich. Nur ich hatte mal gesagt, dass es aufgrund des Urheberrechts problematisch wäre, eine komplette SCHICK.DAT zugänglich zu machen. Einen Patch zu veröffentlichen, der nur die geänderten Bytes ausliefert, (so wie du das machst) halte ich dagegen für unproblematisch. Bedenke: Wenn Bright-Eyes fertig ist, kann jeder, der eine SCHICK.DAT besitzt, dieses Spiel spielen! Das heißt, der ganze Urheberrechtsschutz hängt quasi an dieser Datei. (Streng genommen ist der urheberrechtliche Status des Bright-Eyes-Projekts aber auch nicht so klar.)

Überlegung zum Urheberrecht: Wenn ich ein gut geschultes Gehör habe und deswegen die Partitur eines Musikstücks beim Zuhören rekonstruieren kann, habe ich dennoch nicht das Recht, die daraus entstandene Partitur weiterzuverbreiten, wenn noch ein Urheberrechtsanspruch besteht. Etwas Ähnliches wird hier gerade mit Bright-Eyes gemacht (also im Grunde auch schon fragwürdig). Die SCHICK.DAT dagegen enthält Artwork, das garantiert nicht weiterverbreitet werden darf.

[Lippens die Ente]

Das ist dann auch der Beweis, dass es keine Initiative nach DSA gibt, denn da müssten auch die Behinderung und der Mut mit einfließen.

Dass die Helden wenn alle schlafen sofort tot sein sollen, meinst du nicht ernst, oder? Das ist zu hart, Marcian und würde wohl den Unmut gewisser Spieler hervorrufen.

Solche Dinge sind dann aber keine Bugs, sondern Feature Requests.

[NRS]

@gaor: Natürlich geht das auch mit einem Binärpatch; die Teilgruppengeschichte auf dem Totenschiff war noch viel aufwändiger als das. Ich finde das Problem nur so trivial, dass mir der Nutzen nicht einleuchtet.

Mit "on-the-fly"-Veränderung meine ich zum Beispiel in Segment 99 in Zeile 184 die Änderung von %S in %s. Korrekt wäre, die SCHICK.DAT auf der Festplatte zu ändern, und nicht am geladenen String im Arbeitsspeicher rumzupfuschen. Dass man keine komplette SCHICK.DAT verbreitet, ist mir schon klar.

@Lippens: Also in BrightEyes gibt es sogar eine Variable, die FIG_INITIATIVE heißt.