Aaaaalsoooo:
@Kyuraan: Das mit dem wait 0.0 hat glaube ich nur Auswirkungen, wenn es ein PP ist, kann mich aber auch irren.
@MagicMaker: Das Ding ist, dass Sie bis auf eine, bereits in einem anderen Thread erläuterte Zeitabfrage (welche Performancetechnisch hervorragend funktioniert), gar nicht geschachtelt ist, sondern ohne "if-else" aufgebaut ist, es wird also nacheinander nach einem bestimmten variablen-Wert gefragt.
Wegen Schachteltiefe: Ab einem gewissen Punkt ist man immer auf Label angewiesen, da der Eventcode sonst im Rand verschwindet. (Bei geschachtelten Conditional branches)
Ich habe mich ehrlich gesagt, schon immer gefragt ab welcher Event-Größe der Maker schlicht und einfach sagt: "Nö!" (Ähnlich wie bei den Move-Befehlen, wo ja irgendwann auch schluss ist)
Hatte im Falle dieses Events sogar schon richtig Angst, dass nach 80% des Codes sich der Maker einfach weigert weiterzumachen. (Es ist wirklich verdammt lang , 1 Stunde copy&paste mit Editierungen ^^)
@DavyJones: RPG2k3 natürlisch! Hast doch schon genug Projekte von mir "Betatesten" müssen um das zu merken
@Topic: Da das Spiel nach ausgiebigen Tests, auf diesem Laptop so oder so ruckelt (Schon bei einem aktiviertem PP oO)
liegt es also mit Sicherheit nicht an dem "Monsterevent"!
Jetzt drückt mir mal bitte die Daumen, dass ich das Event nicht noch mal editieren muss, sonst darf ich wieder 10 (ja 10 nicht 3) Minuten warten bis es sich überhaupt öffnet!
Danke für Eure fixen Antworten,
Räbbit!
--
"Gib einem Mann Feuer, und er hat es einen Tag lang warm. Steck ihn in Brand, und er hat es warm für den Rest seines Lebens"
Hallo,
das Wait 0.0 hat etwas damit zutun wie schnell das Event erneut verarbeitet wird, jedoch nicht mit der Anzeigegeschwindigkeit im Editor.
Hast du so viele geschachtelte Abfragen weil du Reichweiten von Zahlen abfragst?
Wenn ja, dann teile das Event in mehrere Unterevents auf und rufe diese per Call Event auf.
In die Events kannst du dann dementsprechend 20 - maximal 40 Forks hineinsetzen. Je nachdem wie stark der PC ist mit dem du arbeitest.
Wenn du mehr als 20 Abfragen in einem Event nutzen willst, musst du natürlich die Forks richtig anpassen.
Du kannst die Abfragen mit dieser Methode auch etwas beschleunigen, indem du prüfst wie groß die Zahl ist.
Vom dem Beispiel oben ausgehend, ist die höchste Zahl 100 und die kleinste 0. Wenn man vor dem Fork der prüft ob zahl >= 40 ist ein Label plaziert, kann man mit einem GOTO direkt zu diesem Label springen und damit praktisch die Hälfte der vorherigen unnötigen Abfragen überspringen.
Ich habe die Erfahrung gemacht, dass ein Kommentar in der ersten Zeile den Ladevorgang deutlich beschleunigt.
...
Könnte das jemand bestätigen? Ich habe jetzt beim Ausprobieren keinen Unterschied bemerkt.
@makenshi:
Wäre eine gute Lösung, allerdings würde sich das in diesem Fall nicht lohnen, da pro abgefragter Variablen-Summe nur eine Variablenänderung vorgenommen wird. Das würde den Event-Text nur sehr geringfügig kürzen und sich somit leider nicht lohnen, für andere Summenabfragen werde ich mir das aber schon einmal merken, Schankedön!
--
"Gib einem Mann Feuer, und er hat es einen Tag lang warm. Steck ihn in Brand, und er hat es warm für den Rest seines Lebens"