Genau.
Man kann beim erstellen von Events Startbedingungen einstellen (besagte zwei Switches + Variable, bei Berührung durch den Spieler/einen NPC, ...) die bestimmen, wodurch ein Event getriggert wird. Sind diese Bedingungen erfüllt, wird der Code darin ausgeführt. Abfragen, etc. sind Teil dieses Codes, dafür muss das Event also schon laufen.
Autostart-Events blockieren - egal was drinsteht - andere Events und vor allem die Steuerung, da sie für Cutscenes gedacht sind. Parallele Prozesse dagegen laufen halt parallel zu allem anderen - können aber halt auch zu Performance-Problemen führen, wenn zu viele laufen oder man beim Scripten nicht aufpasst. Da sollten normale Abfragen also nur verwendet werden um zu schauen, was der Prozess tun soll, nicht ob.
Ich frage mich gerade, ob denn jemals mehrere der Events gleichzeitig aktiv sind. Kann mir das grad noch nicht recht vorstellen, weil die Bilder nicht funzen. Wenn nicht: Was spricht dagegen ein PP-Event zu machen mit einer Seite pro Charakter und jede Seite mit einer Variablennummer anzusteuern?
Betrifft aber nur Parallele Common Events, Parallel Map events machen das nicht.Zitat
Man muss beachten, dass parallele Events untereinander im Prinzip kooperatives Multitasking machen (das Event signalisiert via Scriptende, "Wait" oder anderer Befehle die zu eienm "yield" führen, dass es für diesen Frame fertig ist). Wenn man das "yield" vergisst sind insbesondere Endlosschleifen teuer, da das PP 10000 Befehle pro Frame ausführen darf bevor es pausiert wird.
Okay und designbedingt sind alle Switch- und Variablenoperationen langsam, weil nach jeder Operation die komplette Map refreshed wird um parallele Events zu entfernen, die nicht mehr der Startbedingung entsprechen.