Kann ein Event zu "lang/groß" sein?

[Mr.Räbbit]

Halloooo Leute!

Ich habe mal wieder eine ganz einfache Frage, welche sicherlich wieder in kürzester Zeit von den Makergenies gelöst werden kann:

Kann ein Event zu lang werden, so dass der Maker nicht mehr damit klar kommt?
Das Problem sieht wie folgt aus: Ich habe ein gewaltiges Common-Event (Autostart, über Switch) erstellt, beim Öffnen der Database dauert es ca. 3 Minuten bis das Event sichtbar wird :P

Hat dies negative Auswirkungen auf die Performance, oder braucht der Maker einfach nur lange um eine große Eventcommando-Liste anzuzeigen?
Die Performance kann ich leider momentan nicht testen, da ich nur einen Uralt Laptop zur Verfügung habe, welcher ohnehin ein paar Problemchen hat.

Wäre es also ratsam, das Event zu zerstückeln oder macht das keinen Unterschied?
Ich freue mich auf Eure Antworten!

Räbbit!

[RPG Hacker]

Das kommt ganz drauf an, wie das Event aufgebaut ist. Da es ein Autostart-Event ist, werden ja ohnehin alle anderen Events pausiert. Von daher glaube ich kaum, dass es da zu einem Performance-Verlust kommt, außer du hast noch weitere parallele Events laufen oder aber das Event selbst wäre ein paralleles Event. In dem Fall würde es - wie gesagt - drauf ankommen, wie das Event aufgebaut ist. Speziell darauf, wie viele Befehle das Event gleichzeitig abarbeiten soll. Es gibt ja Befehle, die Zeit in Anspruch nehmen (Move Event, Wait, Message...) und deswegen nicht so viel Performance erfordern. Die meisten anderen Befehle laufen alle relativ sofort nacheinander ab und erfordern - in großen Mengen - sicherlich mehr Performance.

Um allerdings auf deine Frage zurückzukommen: Ich denke nicht dass alleine die Länge des Events an sich zu einem Performance-Verlust führen sollte, außer der Maker ist richtig schlecht programmiert.

[Mr.Räbbit]

Danke Hacker, gut zu wissen!
Zur Erläuterung, sei vielleicht noch gesagt, dass das Event aus ca. 140-160 Conditional-branches besteht, wovon im Endeffekt nur ca. 3 aktiviert werden. Es rattert also durch einen ganzen Haufen von Abfragen durch und führt dann nur Variablen-Veränderungen und/oder picture Anzeigen durch.
Ist das Event (zum Test) deaktiviert geht die Performance deutlich hoch, ist es aber aktiviert gibt es ein deutliches Stocken während des Testspiels. Da der Laptop aber, wie gesagt eine alte Krücke ist, will ich darauf aber nicht all zu viel geben und werde es dann wohl in ein paar Tagen an meinem PC noch einmal testen.

Wenn jemand noch weitere Einwände oder Antworten hat, wäre ich darüber äußerst dankbar!

Räbbit!

[Kyuraan]

beim Öffnen der Database dauert es ca. 3 Minuten bis das Event sichtbar wird

...

Ich hab schon mal ein viertel Stunde auf sowas gewartet.
Aber mit einem 0.0 Wait hat sich das plötzlich erledigt.

[MagicMaker]

Zur Erläuterung, sei vielleicht noch gesagt, dass das Event aus ca. 140-160 Conditional-branches besteht, wovon im Endeffekt nur ca. 3 aktiviert werden.

...

Wenn die teils etwas tief geschachtelt sind haben wir auch eine Hauptursache für die lange Ladezeit im Editor
hier direkt vor der Nase, denn die brauchen wirklich am längsten. Das wirst du auch merken, wenn du eine
davon ändern willst, ist die Neuladezeit länger, je mehr dieser Bedingung/IF/Gabel noch untergeordnet sind.

Hat dies negative Auswirkungen auf die Performance, oder braucht der Maker einfach nur lange um eine große Eventcommando-Liste anzuzeigen?

...

Sollte im Spiel eigentlich keine Auswirkungen haben.

Irgendwann ist allerdings glaube ich auch im Editor eine Schachteltiefe erreicht, bei der das Programm dann
keine Lust mehr hat, ich hatte beim Anlegen von IFs einmal eine Bombadierung an Fehlermeldungen erhalten,
die ich letztendlich mitsamt Makerchen mit dem TaskManager abgeschossen habe.

[Davy Jones]

Welchen Maker hast du? 2k oder 2k3?

Zumindest bei den Maps braucht der 2k ab einer bestimmten Anzahl und Größe wesentlich länger als der 2k3 (nur einer der vielen Fixes von ASCII).

[Mr.Räbbit]

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!

[makenshi]

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.

Code:

if(zahl >= 80){
   CALL EVENT "Zahl_100-80"
}else if(zahl >=60){
   CALL EVENT "Zahl_79-60"
}
[...]

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.

Gruß Makenshi

[Kyuu]

Ich habe die Erfahrung gemacht, dass ein Kommentar in der ersten Zeile den Ladevorgang deutlich beschleunigt.

[Mr.Räbbit]

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!