Detail-Wissen und Geheimnise des RPG-Makers -vorallem für Erfahrene/Profis lehrreich

[Gekiganger]

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?

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.

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.

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.

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.

[Lachsen]

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.

...

Ich denke nicht, dass man das so einfach stehen lassen kann.
Siehe Thread:

... dass sich ein Move-Event, das auf "this Event" steht und in einem Call-Event zu finden ist, sich auf das Event bezieht, das gecallt wird? (also macht NIE Move-Event "this Event" in einem Common-.Event ^^)

...

Das heisst: Alle Befehle, die sich auf "this Event" Beziehen, gehen (LEIDER >_< und gleichzeitig ZUM GLÜCK XD... wüsste nicht genau was besser wäre) nicht auf das Event, dass das Skript gecallt hat, sondern auf das Event, das gecallt wurde.
Da wären: Move Events, Coordinaten nehmen, Set Event Place... und ALL das zeug.
Das gleiche gilt (eigentlich o_ô) auch für Clear Timer.
Wenn man ein Event callt und in dem Skript dieses Events Clear Timer anwendet, verschwindet das gecallte Event. (ich denke das ganze Skript von diesem Event wir dann auch übersprungen und das Programm geht direkt zum Event zurück, dass gecallt hat)

Von daher kann man leider nicht so direkt davon sprechen, dass das Skript einfach in das Event, dass den Call-Event Befehl verwendet, rein kopiert wird...

Ich glaube was hier das Problem ist, ist der schwamminge Begriff "Call-Event". Ist vielleicht hier an einer oder anderer Stelle ehr "Common Event" gemeint? Denn da hat "Clear Timer" wirklich keine auswirkung (wie ich schon in einem vorherigen Post geschrieben habe)

"Call Event" ist für mich einfach Event, das gecallt wurde. Das kann auch eine Event-Seite sein von einem Map-Event.

Soviel von meiner Seite

C ya

Lachsen

[Dhan]

Das heisst: Alle Befehle, die sich auf "this Event" Beziehen, gehen (LEIDER >_< und gleichzeitig ZUM GLÜCK XD... wüsste nicht genau was besser wäre)

...

Irgendwas übersehe ich, warum "zum Glück"? Was spricht den dafür?

@Traveler: Net übel net übel, hat sicher viel Zeit gekostet

[Lachsen]

Irgendwas übersehe ich, warum "zum Glück"? Was spricht den dafür?

...

Och, da gibt es EINIGES.
Ehrlich gesagt finde ich es, wenn ich es mir recht überlege, doch um einiges besser, dass es so ist.

In folgenden Fällen ist es nützlich:
1. In einem AKS kann man, um die Coordinaten eines Events zu bekommen einfach eine Event-Seite von diesem Event callen, indem zwei Change Variable Befehle sind die den Variablen Coordinate-X und Coordiante-Y die jeweiligen Coordinaten von "this Event" übergeben.
Wann immer man nun die Coordinaten von diesem Event brauch: man muss es nur diese Seite callen. Das macht das Coordinaten-Nehmen in einiger Hinsicht flexibler.

Denn: Während Change-Variable Befehle, die die Coordinaten von einem Event nehmen, immer ein bestimmtes festes Event gewählt haben müssen, kann man bei Call-Event eine Variable angeben, die bestimmt, welches Event gecallt wird. ^^

2. Auf die Gleiche Methode kann man Event leichter von einem anderen "steuern". Angenommen die BEwegungs-KI von allen Gegnern würd über ein Common-Event geregelt (das hat ja viele Vorteile), spätestens wenn es darum geht, die Events der Gegner zu BEwegen, wird es kompliziert, denn die Gegner-Events können von Map zu Map andere Event-IDs haben.
Hier kann man auch diese Methode anwenden:
Man gibt jedem Gegner-Event eine Event-Seite, die nur zum callen bestimmt ist und die alle Move-Events enthält, die nötig sind, um dieses Event zu Bewegen (natürlich gehen hier alle auf "this Event").
Wenn man nun über das Common-Event ausgerechnet hat, welchen Weg das Event geht, kann man nun das Event callen um es zu bewegen und wie gesagt:
Im Gegensatz zu MoveEvents muss man bei CallEvent keine tausend Forks aufreihen (für alle möglichen Event-IDs), weil man eine Variable angeben kann, die die Event-ID des Gegeners enthält, wodurch dann automatisch das richtige Event gecallt wird. ^^

3. Noch ne Sache, die ich in Velsarbor verwende: Man kann in dem Spiel Büsche zerhacken, die sogar nach einem Map-wechsel (wenn ein Kampf kommt oder man das Menu aufruft) immernoch weg sind.
Und das ganze funktioniert ganz ohne Switches. Das Skript ist so erstellt, das ich nur ein festes Busch-Event kopieren muss, ohne es anzupassen.

Das ganze funktioniert so:
Wenn ein Busch zerstört wird, wird die Event-ID dieses Busches in einer Variablen-Liste eingetragen (ich glaube bis zu 50 Event-IDs können dort eingespeichert werden, also bis zu 50 Büsche können pro Map zerstört werden).
Wenn man nun in einem Kampf kommt oder das Menu aufruft und daraufhin wieder zurück zur Map gelangt, startet automatisch ein Skript, dass die Liste der Event-IDs der Büsche durchgeht. Für jede ID die in dieser Liste gefunden wird, wird folgendes gemacht:
Das Event, dass diese ID hat, wird gecallt, undzwar die erste Seite.
Es handelt sich dabei natürlich um ein Busch Event.
Während die 2. Seite eines Busch-Events das Skript enthält, bei dem der Held es kaputt haut, enthält die erste Seite nur einen einzigen Befehl:
"Clear Timer"
Sprich: Das Event wird gelöscht, wenn diese Seite gecallt wird.
Und somit ist das Event auch weiterhin verschwunden, obwohl die Map durch Kampf/Menu gewechselt wurde. ^^

(Achja: Wenn man die Map verlässt, also zum nächsten Map-Abschnitt wechselt, werden natürlich alle IDs aus der Busch-Zerstört-ID-Liste gelöscht.)

... naja es gibt noch viele andere Sachen, wo ich es verwende.
Beispielweise werden auch alle "Schaden-Einstecken"-Animationen im Vsb-KS per Move-Event geregelt undzwar auch hier, indem man ein Event callt das sich im Gegner-Event selber befindet.

Naja, also mir ist das doch schon ganz lieb so o_ô

Ne, was aber WIRKLICH ultimativ wäre:
Alle Move-Events in COMMON-EVENTs die als Ziel "this Event" haben, gehen auf das letzte Map-Event, das in der Call-Event kette eingebunden ist @_@
Das wäre genial @_@

Aber nya... Wäre alles nicht nötig, könnte man überall Variablen angeben, wo nach Event-IDs oder sonst was gefragt wird, was eine ID oder Zahl hat (Picture Nummer ;___________________

@Darktraveler
Trefferwahrscheinlichkeits-Rechnung mit ner Wurzelfunktion? XD Oh weia...
Wieso kann der Maker die Wurzelfunktion anwenden, stellt sie aber nicht in dem Change-Variablen-Operatoren bereit!? XO
Ansonsten nette Untersuchungen zum Standard KS ^^
Es ist leider nur wirklich sehr schwer im Bereich von Zufalls-Berechnungen mit empirischen Messungen was exaktes herauszufinden o_ô

Soviel von meiner Seite

C ya

Lachsen