Zitat Zitat
ehm, ein durch Label oder Cycel erzeugtes PP-Event, welches in einer Schlaufe läuft, verhält sich genauso wie ein Autostart Event, mit allen seinen Eigenschaften, z.B.:
Hm was soll ich dazu sagen, das ist schlicht und ergreifend nicht wahr.
Ein Show Picture in einem Cycle/ einer Labelschleife lässt das Spiel gefrieren aber das wars auch schon mit der "Ähnlichkeit zum Autostart".
Unter welchen Bedingungen hast du das denn getestet?

Zitat Zitat
das man ein Call Event nicht mit einem Clear Timer vorzeitig beenden kann,
Was aber durchaus logisch ist, denn im Gegensatz zu einem normal gestarteten Event besitzt ein Call Event keine "physiche Gestalt", da es sich lediglich um eine Kopie des Codes des Events (auf der gecallten Eventseite) handelt, ohne die eventspezifischen (physischen) Eigenschaften wie Grafik, Start Condition etc.

Zitat Zitat
das man ein Call Event mit dem Befehl call event vorzeitig beenden kann, wenn man ein anderes event aufruft,
Da musst du vorsichtig sein.
Call Event bedeutet nicht, "rufe ein neues Event parallel auf und setze gleichzeitig den Code fort", sondern "rufe ein neues Event auf und warte. bis dieses Event zum Ende gekommen ist".
Es entsteht also der Eindruck, das jetzige Event wäre zuende, dabei wird nur gewartet bis das neue zuende ist. Befinden sich in dem neuen Event ebenfalls Calls, kann es durchaus seine Zeit dauern, bis das erste Event zuende geführt wird, da jedes einzelne Event auf seine "Kindevents" wartet.

Zitat Zitat
das man das Game zum absturz bringt, wenn man in einem Call Event den Befehl Call Event packt, und das Call Event aufruft,
Ganz so tragisch ist es glücklicherweise nicht. Der Maker erlaubt Aufrufketten (bzw. Rekursionen) bis zu einer Anzahl von 1000. Erst beim 1001sten neuen Aufruf in dieser Kette kommt es zum Absturz.
Früher wurde ein Event, welches sich selbst mit Call Event aufruft, als Parallel Process Ersatz missbraucht. Doch das ist es nicht. Bei Call Event wird eine Kopie des aufgerufenen Events im Speicher erzeugt. Das aufrufende Event wartet solange, bis das neue zuende ist. Doch dieses erzeugt selbst immer neue Events.
Bei 1000 Aufrufen stehen also 1000 Events im Speicher, jedes wartet bis sein Kindevent zu ende ist. Von daher hat diese Begrenzung durchaus seinen Sinn.

Zitat Zitat
wenn man aber ein 0,0 sek wait mit in das ganze reinpackt, undzwar vor dem Call Event, das das Event called, der maker das Call Event als Autostart verarbeitet, mit eben den AutoStart Funktionen
Wie gesagt, da Call Events nicht "physikalisch" existieren, sondern nur den virtuellen Code einer Eventseite repräsentieren, besitzen sie auch keine Start Condition. Vermutlich hast du das Event aus einem Push Key, Autostart oder ähnlichen Event heraus gestartet. Da dieses natürlich wartet, bis das gecallte Event zuende ist, gelten auch die ganze Zeit über dessen Conditions, sprich, man kann sich nicht bewegen.
Ohne den 0,0s Wait hast du es wahrscheinlich nur nicht bemerkt, da das Event zu schnell wieder zuende war.


Zu dem letzten Quote kann ich jetzt nichts vernünftiges sagen, ich verstehe nicht genau worauf du damit hinaus willst.
Klar braucht ein Event für einen Durchlauf länger, sobald es mehr Anweisungen verarbeiten muss.
Trotzdem verstehe ich nicht, inwiefern das zweite Event das erste beeinflussen soll, schaltet es doch nur den Switch nach 0,1s wieder aus, nachdem das erste Event bereits 4500 Durchläufe in derselben Zeit hatte.
Zudem verstehe ich nicht, ob das zweite Event nun in einem PP oder AS laufen soll. Ein AS kann es ja nicht sein, denn es können keine 2 gleichzeitig laufen, es wird immer der zuerst behandelte AS ausgeführt (Event mit der niedrigeren ID) und der zweite ignoriert.