Schicksalsklinge: Umfassender Bugfix-Patch

[Lippens die Ente]

weiß man, welche faktoren da mit einfließen?

[gaor]

Ja, weiß man. Ich hab's grad erklärt. Ich selbst habe damals dieser Variable den Namen FIG_INITIATIVE verpasst. Es ist einfach nur eine Art 'Flag', die vor dem Beginn des Kampfmodus deterministisch und ohne Proben (auf 0, 1 oder 2) gesetzt wird, um zu sagen, ob der Gegner oder die Helden den ersten Zug machen oder ob ausgewürfelt wird. Das ist alles!

@NRS: Ja, das war so ein einzelner Punkt... Damals hat Henne sich wahrscheinlich gedacht, es wäre erstmal das Einfachste, es so zu lösen. Solche Fehlerkorrekturen waren ja bisher nur nebensächlich. Man hat sich ganz darauf konzentriert, die Code-Basis zu vervollständigen. Mit deinen Binär-Patches ist ja jetzt auch glücklicherweise ein Anfang gemacht, die SCHICK.DAT-Probleme nachhaltiger anzugehen. Wie wäre es denn, wenn du für deine Arbeit ein git-Repository einrichten würdest? Dann könnte man das gemeinschaftlich etwas übersichtlicher angehen. Wenn du es auf Github hostest, könnte man auch Bugs und Pull-requests zentral verwalten usw.

[NRS]

FIG_INITIATIVE legt einfach fest, ob erst die Helden, erst die Gegner, oder zufällig eine von beiden am Zuge sind.

Im Wildnislager sind immer die Gegner zuerst am Zuge. Ob ein Held zu Beginn wach ist oder nicht, hängt (nach meinem Verständnis) ausschließlich von der Kampfdefinition in FIGHTS.LST ab. Helden, die in einer späteren Kampfrunde "erscheinen", sind zu Beginn schlafend. Einige CAMPFIGHTs legen fest, dass Held Nr. 1 schon in der ersten Kampfrunde erscheint (also wach ist), andere wie der Harpyienangriff beginnen grundsätzlich mit allen Helden schlafend. Dem Spiel ist es in dieser Frage völlig wurscht, ob oder wer Wache hält. (Die Wachen verändern nur die Wahrscheinlichkeit, dass ein Kampf überhaupt kommt, sowie die LE-Regeneration: ein Held regeneriert nicht, wenn er zwei oder mehr Wachen übernehmen musste oder Magie angewendet hat, sonst eben schon.)

Um die gewünsche Wirkung zu erreichen, müsste man also:

1. Zunächst alle Lagerkämpfe in FIGHTS.LST dahingehend abändern, dass grundsätzlich auch der erste Held schläft, d.h. später erscheint
2. In Segment 39 die Prozedur FIG_init_heros so anpassen, dass ein laut Definition später "erscheinender" Held nicht schläft, wenn er gerade Wache hält. Natürlich ist die Kampfnummer auch abzufragen, denn das soll ja nur bei Lagerkämpfen passieren. Das geht aber nicht so einfach, weil der aktuell wachende Held nur über eine lokale Variable (l_si als Index in WILDCAMP_GUARDS) von do_wildcamp ermittelbar ist und FIG_init_heroes darauf gar keinen Zugriff hat.
3. Man müsste also auch Segment 51 so abändern, dass der aktuell wachende Held irgendwo als globale Variable abgelegt wird, damit FIG_init_heroes darauf auch Zugriff hat.

Wie gesagt: gehen tut das alles, auch auf Binärebene, aber es ist eben viel Gedöns um sehr wenig Ergebnis.

Wie wäre es denn, wenn du für deine Arbeit ein git-Repository einrichten würdest? Dann könnte man das gemeinschaftlich etwas übersichtlicher angehen. Wenn du es auf Github hostest, könnte man auch Bugs und Pull-requests zentral verwalten usw.

Ich kann mir nicht vorstellen, wie so was in der Praxis bei Binärpatches funktionieren soll, mal abgesehen davon, dass ich nur ungern die Kontrolle über meine Patches abgebe.

[Zurgrimm]

Die Chance, trotz Wache überfallen zu werden, liegt bei 40% (ggü. 90% ohne Wache).

Die Wahrscheinlichkeiten können aber doch nicht fix sein, oder? Jedenfalls gefühlt gibt es Gegenden, in denen man allgemein - also auch, wenn man immer überall Wachen aufstellt - häufiger überfallen wird als in anderen. Oder ist das alles nur Einbildung?

[NRS]

Doch, sind fix. Das einzige, was außerdem noch abgefragt wird, ist dass Timer Nr. 5 nicht benutzt oder abgelaufen ist, welcher durch das entsprechende Travia-Wunder auf 7 Tage gesetzt wird.

[gaor]

Ich kann mir nicht vorstellen, wie so was in der Praxis bei Binärpatches funktionieren soll, mal abgesehen davon, dass ich nur ungern die Kontrolle über meine Patches abgebe.

Wenn du der Maintainer bist, hast du weiterhin volle Kontrolle. Die Binärpatches müsste man dann eben in einem menschlich lesbaren Format speichern (und nicht direkt bsdiff). So wäre auch besser nachvollziehbar, was genau geändert wurde, was sich mit zunehmender Komplexität sicherlich als nützlich herausstellen wird.

[NRS]

Dann müssten aber im Repository die geänderten Einzeldateien, die innerhalb der SCHICK.DAT verpackt sind, im Original vorhanden sein, und das gibt Urheberrechtsprobleme. Weil BSDIFF sich ja auf die ganze SCHICK.DAT und nicht auf die darin enthaltenen Einzeldateien bezieht. Grundsätzlich scheint mir GIT für diese Art von Projekt ungeeignet. Da schreib ich lieber eine simple Textdatei, welche die gemachten Unterschiede auflistet.

Nach meinem Verständnis des Codes sind die Wahrscheinlichkeiten übrigens 60% ohne Wache versus 10% mit Wache, nicht 90% versus 40%.

[Lippens die Ente]

ich denke, dass jede Nacht ein W100 gewürfelt wird, ob ein Kampf stattfindet oder nicht (meines Wissens gibt es genau 4 nightcamp-Kämpfe und 4 für die Dungeons) und da wird wohl abgefragt, ob Wache gehalten wurde oder nicht, und je nachdem kommt bei Würfen von 1-40 bzw 1-90 ein Kampf, der wohl wieder ausgewürfelt wird.

Ich habe nicht das Gefühl, dass das von der Gegend abhängt, das scheint nur bei den Überfällen bei Tage (Orks, Goblins) der Fall zu sein, die verstärkt im Osten auftauchen.

[gaor]

Nach meinem Verständnis des Codes sind die Wahrscheinlichkeiten übrigens 60% ohne Wache versus 10% mit Wache, nicht 90% versus 40%.

Jap, danke für die Richtigstellung!

eine simple Textdatei, welche die gemachten Unterschiede auflistet.

Ja, warum nicht? Wäre bestens geeignet für eine Versionsverwaltung. Sehe keinen Grund, warum man so eine Textdatei nicht mit git kombinieren sollte.

[NRS]

Weil ich keinen Bedarf an einer gemeinschaftlichen Versionsverwaltung habe? Vergiss es, ich nehme kein git.

[gaor]

Weil ich keinen Bedarf an einer gemeinschaftlichen Versionsverwaltung habe? Vergiss es, ich nehme kein git.

Schade. Ich verstehe nicht, wieso du das als Affront auffasst. Vielleicht ist es in Mod-Communities so üblich, dass jeder Modder sein eigenes Ding macht? Wieso wollen wir unsere Kräfte nicht bündeln, damit jeder, der etwas zu diesem Projekt beitragen möchte, das auch leicht tun kann? Wieso bestehst du darauf, dass das alleine dein Projekt ist, obwohl doch offensichtlich auch viele andere Menschen daran teilhaben möchten und auch dank deiner Uploads hier zumindest rezipierend tatsächlich daran teilhaben können? Lass sie doch auch tätig daran teilhaben!

[Zurgrimm]

Wieso bestehst du darauf, dass das alleine dein Projekt ist, obwohl doch offensichtlich auch viele andere Menschen daran teilhaben möchten und auch dank deiner Uploads hier zumindest rezipierend tatsächlich daran teilhaben können?

NRS hat die Patches geschrieben und dafür den Programmcode analysiert, also sind sie zunächst einmal allein sein Projekt. Wenn er möchte, daß das so bleibt, dann sollte man das respektieren. Gemeinschaftsarbeit mag für andere wünschenswert sein. Aber wenn sich jemand nicht daran beteiligen möchte, dann ist das seine Sache.

Wer hier etwas Tolles beiträgt, wie NRS, sollte m.E. nicht von anderen bedrängt werden, dies in einen Rahmen zu stellen, der ihm nicht gefällt.

[NRS]

Außerdem ist das Projekt ja gerade fertig geworden, insofern gibt es da nix mehr zu bündeln.

[qbert]

Danke an NRS für den tollen Patch!

Im allerersten Post steht was, dass die Anzeige der Versionsnummer von V auf P geändert wird. Ist das beim momentan aktuellen Patch auch noch so? Ich habe ihn nämlich installiert und da steht weiter V 3.02 (bin mir daher unsicher, ob das patchen funktioniert hat)

[NRS]

Nein, das habe ich im neuen Patch nicht mehr gemacht. Eigentlich hätte ich von P auf Q wechseln müssen, aber das war mir dann doch zu lächerlich.

[qbert]

Vielen Dank für die schnelle Antwort!

[Alrik Alrikson]

[...]
[*]Das existierende CD-Image mit einer beliebigen Brennsoftware um die mitgelieferte Spur 16 ergänzen, und fortan das ergänzte Image verwenden.
[...]

Könntest Du erklären, wie genau das gemeint ist? Soll ein Image von der Original-CD erstellt werden und dann die neue Musikdatei mit einem Brennprogramm hinzugefügt werden?

[NRS]

Sozusagen. Wichtig ist nur, dass die TRACK16.WAV eben nicht als Datei ins ISO-Dateisystem kommt, sondern als 16. Audiospur dazukommt. Da jede Brennsoftware anders ist, kann ich da keine Schritt-für-Schritt-Anleitung liefern.

[Zurgrimm]

Wichtig ist nur, dass die TRACK16.WAV eben nicht als Datei ins ISO-Dateisystem kommt, sondern als 16. Audiospur dazukommt.

Wieso ISO-Image? Um überhaupt Musik hören zu können, muß man doch BIN/CUE-Images erstellen, soweit mir bekannt, weil nur dort die Audiospuren überhaupt erfaßt werden. Aber wie kann man da mit einem landläufigen Brennprogramm (ich habe ImgBurn benutzt) in das Image eine Datei einfügen? Für gewöhnlich wird doch die ganze Spiel-CD ausgelesen und 1:1 als CD-Image auf der festplatte abgelegt.

[NRS]

Wieso ISO-Image?

ISO-Dateisystem, nicht ISO-Image. Eine BIN/CUE-Abbilddatei enthält das ISO-9660-Dateisystem, Fehlerkorrekturinformationen, plus Audiodaten. Eine ISO-Abbilddatei enthält nur das ISO-9660-Dateisystem.

Aber wie kann man da mit einem landläufigen Brennprogramm (ich habe ImgBurn benutzt) in das Image eine Datei einfügen?

1. Mit IsoBuster die Original-CD oder das Original-BIN/CUE als .ISO + .WAV extrahieren.
2. In den Ordner mit den extrahierten Dateien meine TRACK16.WAV sowie diese .CUE-Datei kopieren. Ich habe in dieser .CUE-Datei die Standarddateinamen benutzt, welche IsoBuster ohne weiteres Zutun verwendet. Lauten die Namen anders, müssen sie in der .CUE-Datei mittels Texteditor angepasst werden.
3. Diese CUE-Datei kann direkt in DOSBox mittels IMGMOUNT statt der Original-CUE eingebunden werden, sofern man die aktuelle DOSBox-Version nutzt. Sie kann auch von jedem besseren Brennpogramm gebrannt, oder mittels DaemonTools als virtuelles Laufwerk verwendet werden.

Die Erstellung einer Binärdifferenzdatei für .BIN/.CUE-Abbilder verbietet sich aufgrund der Vielzahl von Veröffentlichungen (Attic/Gold Games/Bestseller Games/Heldenedition/weitere).