It's Quiz Time!!

[MagicMaker]

Ok, ich.

Mal eine einfache Eventfrage


Welche Prozessart muss ein Event haben, damit seine Befehle auch noch auf
der nächsten Map, wenn nötig, weiter ausgeführt werden?

(in dem Fall benutzt ihr einfach mittendrin einen Teleport)

[elvissteinjr]

Autostart....?

[R.D.]

PP^^

mfg R.D.

[Orange4]

Parallel Process.
Definitiv, das hab ich bei Menüs bemerkt.

@ R.D.

Ups, du hast ja schon die Lösung gebracht XD

[MagicMaker]

Total correct^^ ~ Du bist dran R.D.

[Lachsen]

Welche Prozessart muss ein Event haben, damit seine Befehle auch noch auf
der nächsten Map, wenn nötig, weiter ausgeführt werden?

...

Sofern wir hier von Map-Events reden: Es ist Autostart.
Ganz definitiv.
Parallel Process hat meines Wissens die Eigenart abzubrechen, sobald man die Map wechselt (werden höchstens nur noch einige Befehle, die keine Zeit in Anspruch nehmen, ausgeführt), während Autostart bestehen bleibt, bis das Event durchgelaufen ist (wiederholt sich dann allerdings nichtmehr)

Wenn man solche Fragen stellt, sollte man wenigstens die richtige Antwort kennen >_<

C ya

Lachsen

PS: Ich habe das ganze eben noch mal getestet um sicher zu sein.
Wie kommt es bitte, das hier gleich 3 Personen gleichzeitig falsch liegen?!

[Orange4]

PS: Ich habe das ganze eben noch mal getestet um sicher zu sein.
Wie kommt es bitte, das hier gleich 3 Personen gleichzeitig falsch liegen?!

...

Nun, in meinen Menüs z.B. habe ich als sie noch mit der Tastatur gesteuert wurden den Hero via PP und Passwortabfrage auf die gespeicherte Map zurückteleportiert - und nach dem Teleportbefehl kamen noch einige Zeilen wie ihn wieder sichtbar werden lassen und die Grafik ändern.

Vlt unterscheidet sich das von Makerversion zu Makerversion? ^^"

[Cherry]

Es ist aber afaik wirklich Autostart. Welche Version hast du denn?
EDIT: Argh, es ist PP, stimmt.

[R.D.]

also meine Antwort bezog sich auf Commonevents und da MagicMaker richtig sagt, denk ich mal er meinte das selbe^^
Bei Mapevents, ist es ber Autostartm ganz klar, denn ich benutze diese Eigenart, das die Befehle noch ausgeführt werden sehr oft druch Autostart o.o

@topic
hab grad keine "echte" Frage, also Freirunde!

mfg R.D.

[Orange4]

Es ist aber afaik wirklich Autostart. Welche Version hast du denn?

...

Unter Info kommt 1.85
Die .exe müsste auf meinem Uralt-Rechner noch die mit Gnafs Picturebetrug sein, du weißt besser als ich von welcher Edition die war (ich weiß es nämlich nicht XD)

[MagicMaker]

Die .exe müsste auf meinem Uralt-Rechner noch die mit Gnafs Picturebetrug sein, du weißt besser als ich von welcher Edition die war (ich weiß es nämlich nicht XD)

...

Das ist "VALUE!", die aktuellste RPG2000-Version 1.51
(http://tkool.jp/support/download/rpg2000/rpg2000up.exe)

Parallele Events tun jedenfalls auch bei mir weiterführen, was nach einem
Mapwechsel kommt, aber wiederholen sich nicht wie ein Autostart und darum
gings ja nicht.

[Lachsen]

*GRUMMEL*

Wieso sich diese Frage auf Map-Events beziehen sollte:
Weil bei Common-Events so gut wie ALLE Event-Methoden diese Eigenschaft erfüllen.

• Parallele Common Events laufen Map-Unabhängig
• AutoStart Common Events ebenso
• Call Common Events übernehmen die Eigenschaften von dem Event, das sie aufgerufen hat.

Wie es bei Map-Events ist:
ALLE Event Start Conditions BIS AUF "Parallel Process" verhalten sich in der Hinsicht gleich:

• Sie laufen unabhängig von Teleport und Map wechsel weiter
• Sie wiederholen sich nicht, wenn man sich am Ende des Events nicht auf
  der Map des Events befindet

Bei Parallel Events ist dies anders:

• Nach einem Map-Wechsel brechen Parallel Events ab.
• Dies passiert nichtauf der Stelle - einige Befehle werden direkt nach dem Teleport noch ausgeführt, etwa Change Switch.
• Sobald aber eine Wartezeit nach dem Teleport integriert wird werden die Befehle dahinter nicht mehr ausgeführt
• Auch andere Befehle, wie etwa Show Message, werden selbst direkt nach dem Teleport nichtmehr ausgeführt.

Dies gilt Sowohl bei der ungepatchten RPG-Maker 2000, als auch dem mit Gnarf-Picture-Patch. Es wäre eine ziemlich Dummheit, eine solch grundliegendes Verhalten durch einen Patch zu ändern, zumal verschiedene Skripte auf sowas basieren können und es überhaupt keinen Vorteil bringt, dieses Verhalten zu ändern - da es Sinn macht.

Und bevor hier Leute mit dem Argument kommen "Bei meinem Menu/KS/SkriptXY ist das aber so und so". Nehmt euch doch mal bitte 2-3 Minuten Zeit und bastelt euch ein kleines Projekt, das diese Eigenschaft isoliert und unabhängig von anderen Kram überprüft. Denn nur so kann man zu einer klaren Aussage kommen.

Das sind hier wirklich tolle Experten °

C ya

Lachsen

[R.D.]

so~ hab das jetzt mal getestet....
Und es stimmt, ich hab mich geirrt XD
naja, werd mir merken.
Jetzt fallen mir auch einige fehler in Phönix ein XD

mfg R.D.

[Orange4]

Und bevor hier Leute mit dem Argument kommen "Bei meinem Menu/KS/SkriptXY ist das aber so und so".

...

XD
Genau damit wollte ich gerade kommen ^^"

*GRUMMEL*[*]Dies passiert nichtauf der Stelle - einige Befehle werden direkt nach dem Teleport noch ausgeführt, etwa Change Switch.

...

Aber ich denke, dass die Sache mit dem Menü dann hier drunter fällt. Nach dem Teleport wird wie gesagt nur noch die Tranzparenz geändert und die Grafik des Helden aktualisiert - und ein oder zwei Switches abgestellt.

Werde es aber auch bei Gelgenheit mal testen, finde das sehr interessant.

LG,

Orange4

[Cherry]

Lachsen, könntest du bitte mal auflösen?

[Lachsen]

Lachsen, könntest du bitte mal auflösen?

...

Nagut, scheint ja niemand zu antworten.

Lösung: Ein paralleles Map-Event mit "Same Level As Hero" spielt den Inhalt mit halbierten Wartezeiten ab, wenn man das Event mit der Helden-Figur berührt (d.h. dagegen läuft). Das kann in einigen Situationen zu sehr verwirrenden verhalten führen. Von daher sind Parallele Events mit "Same Level As Hero" besser zu vermeiden.

Naja... ich schätze mal dann ist Freirunde.

[Cherry]

Hrmpf...

Wie kann es passieren, dass ein Event seine Move Route mit der HALBEN Frequency ausführt?