09.01.2021, 01:12
(08.01.2021, 14:19)NRS schrieb: Da die SCHICK.DAT aus vielen kleinen Einzeldateien besteht, muss die Datei vor Erstellung der binären Differenzdatei komplett neu aufgebaut werden. Da käme man nur dann drum herum, wenn der Ersatztext exakt die gleiche Länge wie der Originaltext hätte, und darauf will ich mich nicht festlegen.
ok, wenn sich die Länge der SCHICK.DAT ändert, dann verstehe ich das Problem. Ich hätte vermutet, dass man sich mit Füllzeichen behelfen kann, wenn der Text kürzer wird.
Zitat:Schauen wir lieber erstmal, ob wir bezüglich einfrierendem Kampfbildschirm noch wohin kommen. Du hast ja vom bloßen Ansehen schon mehr von der Logik verstanden als ich.
Ein wenig hab ich jetzt noch weiter geschaut. Mir ist folgendes aufgefallen:
(1)
Das Argument bp_needed (also die zuvor berechnete Distanz zum Zielfeld) der Funktion FIG_backtrack kann potentiell bis zu 50 groß sein, wegen der Bedingung "l_var2 < 50" in Zeile 487 bei der Distanzberechnung. Die vier in FIG_backtrack berechneten Wege werden unter TEXT_OUTPUT_BUF aber nur im 20er-Abstand abgelegt. Bei Entfernungen > 20 (die bei einem Charakter in der Ecke und vielen herumstehenden zweifeldrigen Gegnern durchaus auftreten können) wird also aus dem vorgesehenen Bereich rausgeschrieben.
Soweit ich es überblicke, passt aber trotzdem alles, ein klarer Fall von mehr Glück als Verstand.
Letztlich sind nur die vordersten Einträge in diesen Wegen wichtig, nämlich so viele, wie der Charakter BP übrig hat. Den Rest müsste man (nach einer Endmarke -1) gar nicht mehr schreiben, aber das Programm schreibt etwas grobschlächtig trotzdem alles mit -1 voll. Weil man meines Wissens max. 12 BP haben kann (mit einem Axxeleratus), ist der wesentliche Teil also im 20er Speicherfenster drin. Weil die vier Wegeinträge der Reihe nach erzeugt werden, überschreiben sie sich auch nicht gegenseitig den relevanten Bereich. Und weil TEXT_OUTPUT_BUF insgesamt die Länge 300 hat, wird auch nichts hinten raus in fremde Speicherbereiche reingeschrieben.
Auf Nummer sicher gehen könnte man hier, indem man in den Zeilen 155-159 anstelle von Vielfachen von 20 Vielfache von 50 benutzt (oder noch besser von 60, um mit der Endmarke auf der sicheren Seite zu sein.)
(2)
Dann habe ich noch gefunden, dass in diesem Forum tatsächlich schonmal über ein Aufhängen des Kampfs in der Funktion FIG_backtrack diskutiert wurde, nämlich in diesem Beitrag. Dort war das ursächliche Problem wo anders, was aber dazu geführt hat, dass FIG_backtrack mit dem Charakterfeld als Zielfeld (also Distanz 0) aufgerufen wird. In Folge liefert FIG_count_smth in Zeile 249 immer das Ergebnis 99, womit es dann beim memcpy in Zeile 263 kracht, weil found_dir nicht initialisiert ist. Keine Ahnung, ob das bei uns auch ein Bauteil des Problems sein kann. Man müsste mal mitprotokollieren, ob FIG_backtrack irgendwann mit Distanz 0 aufgerufen wird.