Dieser permanente FAQ-Thread dient zur Sammlung von Ideen, die sich als wesentlich schlechter herausgestellt haben als erst einmal ersichtlich - zur Vermeidung von Wiederholungsfehlern und als Register von möglichen Fehlerquellen.
Blöde Idee: Mit Find_Func irgendetwas suchen, was tatsächlich irgendetwas tut. Das steht auch in der Doku, aber ich hebe es hier lieber noch einmal hervor. Find_Func ruft die jeweilige Funktion tatsächlich in allen Objekten auf, sodass Hit alle Flints explodieren lässt, usw. Und ich weiß nicht, was mit dem Objektregister schreckliches geschieht, wenn während der Suche neue Objekte erstellt werden.
(Wem es Spaß macht, der kann natürlich die Find_Func-Aufrufe zählen oder so etwas, aber es gibt generell keinen Grund. Wenn jemand es aber mag, Spielregeln anzuzünden und dergleichen: Nur zu :whatever:)
Andererseits eignet es sich dadurch als hackige, evtl. geringfügig performantere (?) Kurzschreibweise zum Massenaufrufen von Befehlen nach Suchkategorie.
Vorsicht mit StringTable-Inhalten in syncrelevanten Dingen. Dazu zählt auch Random: Wird zufällig aus Strings/Arrays aus der String Table was ausgewählt, sollten diese in allen erdenklichen Sprachen vollständig sein und die Variablen sollten die gleiche Länge haben. Sonst entgleist der Zufallsseed und das Netzwerkspiel wird abgebrochen.
StringTbl-Strings per eval auszuführen, kann ebenfalls zu nichts Gutem führen.
Blöde Idee: Unbegrenzte rekursive Aufrufe. Wenn eine Funktion sich irgendwie implizit selbst aufruft (ein Objekt, das mehr Instanzen von sich selbst erstellt o. ä.), gibt es einen Stack Overflow und das ist gar nicht schön.
Wenn die Aufrufer an sich mengenmäßig begrenzt sind (explosive Objekte, die einander gegenseitig sprengen o. ä.), reicht es, den Aufruf per Schedule zu verzögern (am Beispiel vom Ölfass und Eke-Reloaded-Sprengstoffen ersichtlich).
Ansonsten sollte die Funktion einen Zusatzparameter kriegen, der die Rekursionsstufen zählt und bei zu tiefer Rekursion abbricht.
Blöde Idee: Fling überladen. Irgendein Feature davon ist hartgecodet, und wenn man es irgendwie überlädt (und sei es nur mit einem neuen Callback und inherited), werden Clonks ins Nirwana geschossen und ähnlich interessante Dinge.
Vorsicht mit ChangeDef - Aufrufen: Bei sämtlichen daraufhin folgenden Verwendungen des Objektes in Funktionen sollte es immer übergeben werden, z.B. CreateContents(CLNK,this) statt CreateContents(CLNK). Ansonsten kann es unter Linux zum Desync kommen.
(Steht zwar auch in der Wiki, aber ich hebe es lieber noch einmal hervor.)
Folgende Situation: Damagein einem Objekt ruft eine Funktion auf, die in einem Inventarobjekt eine Funktion aufruft, die das Inventarobjekt mit Explode vernichtet, und das Objekt dann mit Explode zerstört. Klingt funktionsfähig, kann aber zum Crash führen. Da RemoveObject das Objekt nicht löscht, sondern zum Löschen markiert, kann die Engine failen: Das Inventarobjekt fügt mit Explode dem Container Schaden zu, der Container zerstört sich selbst und das Inventarobjekt wegen zu großem Schaden, das Inventarobjekt fügt dem Container Schaden zu usw.
An dieser Stelle die Warnung: Vorsicht mit Explode-Aufrufen!
(An die Entwickler: Warum kann es so einen Fail überhaupt geben?Danke an DerTod für seine Hilfe.
Gibt es tatsächlich einen Crash? Ist das CR oder OC?
Sollte mal jemand ausprobieren, ob das mit OC auch noch geht. Crashes sollten nie passieren.
Der Witz ist, es passiert nur in einem SGGP-Szenario. Sonst nie.
Du kannst in deinem explodierenden Objekt einen lokale Variable setzen, die entscheidet, dass es nicht mehr explodieren soll, wenn es schonmal explodiert ist.
Habe ich schon. Ich frage mich nur, warum ein entferntes Objekt Schaden bekommen kann.
Klingt dann aber weniger nach einem Engineproblem. Wer weiß was da alles überladen wird.
Crash oder Freeze? Für mich klingt das eher nach einer Endless-Loop.
Alter Post: Crash. Und nein, es ist keine Endlosschleife.
EDIT: Natürlich ein Freeze >.<
Najo. Operationen auf gelöschten Objekten sind undefiniertes Verhalten™
Das schon.
Naja. Das Inventar wird vor dem Explode() - Aufruf bearbeitet, nicht im Destruction-Callback.
Explode() von Hazard. Sonst nix.