Themabewertung:
  • 1 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Schicksalsklinge: Umfassender Bugfix-Patch
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.

gaor schrieb: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.
Zitieren


Nachrichten in diesem Thema
RE: Schicksalsklinge: Umfassender Bugfix-Patch - von NRS - 08.09.2016, 20:38



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