Sehr geehrter Herr Lotter,
zwei Fragen:
(1) Gestern trat beim Beenden meines Spiels, ohne dass ich so wirklich etwas über längere Zeit an meinem Skript änderte (stattdessen beim Leveldesignen und Testspielen) folgende Fehlermeldung auf:



Handelt es sich dabei um fehlerhafte str_... Operationen oder kann der String-Speicher bspw. nicht korrekt freigegeben werden, weil der Speicherbereich anderswo überschrieben worden ist (bspw. durch Überschreiten eines Arrays)?
Ist es möglich, dass eine defekte Datei beim Laden eines Levels in besagten Speicher hineinspuckt und diese Fehlermeldung verursacht?

(2) Zudem tauchten in dieser acklog-Datei, welche in etwa 8 Levelladevorgänge aufweist, zum ersten Mal drei mir vorher unbekannte "Statusberichte" auf der folgenden Form:



Was hat das zu bedeuten und wie wird dieser Statusreport ausgelöst? Kann das u.U. sogar vorige STR Fehlermeldung auslösen (welche zuvor auch nie aufgetreten war)?

Zu (1): Die Fehlermeldung trat nun auch ohne Statusreport und nicht beim Beenden sondern nach einem Ladevorgang auf:

Ja, die Meldung weist tatsächlich darauf hin, dass der Speicherbereich eines STRING von irgendeinem Skript überschrieben wurde. String-Operationen wie str_cat können das nicht sein, denn die passen den Bereich an. - Die Statusberichte sind mir auch unbekannt - könnten das eine Testroutine von Ihnen sein?

Ok, danke. Kann das auch durch fehlerhafte Dateien beim Laden verursacht werden, da ich sonst nicht so recht weiß, wo ich nach der Fehlerquelle suchen soll? (Ich benutze übrigens gelegentlich das string1/2 Feature im WED für read-only Zwecke.)


Das dachte ich auch zuerst, und zur Sicherheit habe ich gerade noch einmal per SED Supersuchfunktion meine gesamten Skripte nach "Status", "Maximum" und sonstiges durchsucht, aber nichts dergleichen finden können.
Ich kann das komplette acklog mit den Statusberichten an den Support schicken, falls das behilflich sein kann.

Kann die Meldung vielleicht von irgendeinem Plugin oder einer externen Bibliothek kommen?

Diese Statusnachricht tauchte eben wieder mitten in einem acklog auf, sehr merkwürdig!
Komplettes Projektverzeichnis per SED danach durchsucht, in meinem Header benutze ich nur folgendes an externen Bibliotheken:




Davon unabhängig habe ich derzeit ein Problem mit meinem Code, und zwar dass eine bestimmte Entity Aktion mit regulärer while loop gelegentlich (!) nicht durch level_load() beendet wird, als sei PROC_GLOBAL gesetzt oder der me pointer verändert worden/ auf NULL gesetzt (zumindest glaube ich, dass das das entsprechende Verhalten ist).
Die Struktur ist so ziemlich die folgende:


Mir ist klar, dass diese Code Struktur nicht allzu gut ist mit der internen define Loop, aber bis zur Vollendung dieses jahrealten Projektes wollte ich sie beibehalten.
So oder so sollte es aber eigentlich keinen Absturz durch Zugriff auf den my pointer in der robot loop geben. Der Pointer wird zwar durch level_load korrekt auf 0 gesetzt wird, aber da die Aktion selbst nicht beendet wird, kommt es unweigerlich zum Crash.
Das vorherige Code Beispiel stürzt nicht ab, der entsprechende Code in meinem Projekt aber sehr wohl, wenn auch nur gelegentlich. acklog spuckt dann folgendes aus:


Was könnte dieses Verhalten in meinem Projekt verursachen (welches übrigens nur bei dynamisch erstellten Entitys aufzutreten scheint)? Ich rufe in der robot-Aktion keine Subroutine auf, welche direkt PROC_GLOBAL setzt. Stattdessen scheint es eine andere externe Ursache haben zu müssen, aber ich weiß nicht wirklich, wo ich suchen kann oder muss.

Ich habe die Fehlerursache ausfindig machen können:
In der Loop für die Todesanimation dieser besonderen Gegner, welche nach Abschuss in die Tiefe fallen, habe ich diese unachtsam weit außerhalb der Levelgrenzen fallen lassen. Offenbar verträgt das entweder der ABT, level_load() oder aber wahrscheinlicher eine Kombination aller 3 Dinge (inklusive meines schlechten Codes) nicht und die Entity/ alle außerhalb der Levelgrenzen werden nicht entfernt.

Alternativ hättest du auch noch probieren können, das EFWAIT ans Ende der Schleife zu schieben. Falls das nicht hilft (oder die Logik plättet), dann danach den my-Pointer nochmal explizit überprüfen und ggf. Exitus.
Und wenn das nicht hilft, vor dem Rücksetzen von enemy_freeze ein wait(1) rein. Dann muss die Entity Funktion auf jeden Fall nochmal durch ein wait() durch direkt nach dem Levelwechsel, und muss eigentlich beendet werden. Anders könnte rein theoretisch ja noch der Rest der Funktion ausgeführt werden, und dann knallts natürlich (auch wenn ich eigentlich erwarten würde, dass die Entity Funktionen vor Start des Levels abgebrochen werden).

Ja natürlich, ich hätte viele kleine Dinge implementieren oder ändern können, um den Crash zu verhindern.
Das wollte ich ja aber auf keinen Fall, stattdessen wollte ich, dass es auch weiterhin crasht und ich so die Fehlerursache ausfindig machen kann, nämlich warum die Aktion nicht beendet wird. Es liegt und lag ja nicht an der Code Struktur (gemäß des Beispiels) selbst, sondern daran, dass die Entity beim level_load sich nicht mehr in den Level Dimensionen befand.

Wenn dem wirklich so sein sollte, dann klingt das aber schon sehr nach Engine Bug. Gewollt kann das eigentlich nicht sein.

Ansonsten ist es ja oft so, dass man bei den fiesen Bugs irgendwo ne Zahl oder irgendwas am Code ändert, und plötzlich ist das Problem weg, bei der nächsten Änderung taucht es wieder auf.