In welchen Fällen versagt "Proceed with Movement"? (2k3)

[Davy Jones]

Beispiel:

Move Event für Hero: Er soll drei Felder nach links gehen.
Proceed with Movement nach diesem Move Event sorgt dafür, dass die Bewegung vollständig ausgeführt wird und erst danach weitere Befehle in Kraft treten (wie bspw. ein Dialog).

Mein Problem: Alle Felder sind betretbar, es steht nix im Weg und der Move Befehl wird komplett ausgeführt. Nur gibt es nach diesem Move Befehl einen Freeze. Der Haken bei Ignore impossible Moves (Unmögliche Bewegungen ignorieren) sowie der Phasing Mode (über alle Events und Tiles drüberlaufen) helfen mir hier nicht weiter.

Edit: Es klappt allerdings, wenn ich waits anstatt Proceed with Movement benutze. Am Boden auf dem sich der Char bewegt, liegt es also definitiv nicht.

Edit2:
Fehler gefunden. Die Sache ist wie folgt (beide Move Befehle befinden sich in einem einzigen Event, etwa von einer Cutszene):

- Move Event für NPC1: 15 Felder nach links, er wird allerdings schon nach 14 abgeblockt. Macht nix, weil er den Haken bei Ignore Impossible Moves in seinem Move Event drinhat. Das Spiel läuft problemlos weiter.

- Move Event für NPC2: Selbe Prozedur wie bei NPC1, nur hier stürzt das Spiel ab. Egal ob geblockt wird oder nicht, egal ob Phasing Mode oder nicht, egal ob Ignore Impossible Moves oder nicht, das Spiel friert ein wenn hier Proceed with Movement benutzt wird. Das Spiel "wartet" anscheinend auf die nicht mögliche Beendigung des Move Befehls von NPC 1 (Vermutung).

Edit3: Korrigiert.

[G-Brothers]

In M&T hatte ich mal das Problem, dass bei einer Sequenz urplötzlich (lief unverändert sonst immer normal) das Spiel eingefrohren ist, obwohl der gehende Charakter "Phasing Mode" an hatte.
PwM benutze ich daher gar nicht mehr, weil das irgendwie ein Lottospiel ist... õ_o

[Davy Jones]

Mittlerweile sieht es durch meine Experimente sogar so aus:
- Move Event wird geblockt, Ignore Impossible Moves, Spiel geht weiter.
- Nächster Move Event: Egal ob geblockt oder nicht, bei Proceed with Movement gibts nen Freeze.

PwM möchte ich trotzdem nicht missen, waits sind bei Move Events nämlich recht nervig, da sie im Zweifelsfalle immer wieder getestet und nachjustiert werden müssen.

Edit: Zudem sollte man keine Events bewegen, die noch garnicht existieren. Bspw. der Move Befehl für ein NPC, dass erst noch durch einen Switch "erschaffen" werden muss. Klappen tut es allerdings, wenn man ihm eine leere erste Seite gibt.

[TwoFace]

Das Problem wurde ja schon gelöst... aber halt all Movement und Proceed with Movement hab ich noch nie benutzt und werd ich auch nie benutzen. Verursachen nur Probleme und mit Waits klappt alles besser.

[Cherry]

Ist da vielleicht noch das Allow/Forbid Event Overlap im Spiel?

[Davy Jones]

Bei mir nicht.

Aber ich hatte mal in einer Cutszene das Problem, das ein laufender NPC von Forbid Event Overlap aufgehalten wurde und das Spiel zum Stillstand kam. Hab ich ziemlich einfach mit Phasing Mode/Slip through gelöst. Ein wait hätte hier von vornherein den Absturz verhindert, aber bei Proceed with Movement kann ich mir sicher sein, dass der NPC auch wirklich alle Bewegungen bis zum Schluss ausführt (ohne großartig mit Sekundenbruchteilen rumzutesten).


Verursachen nur Probleme und mit Waits klappt alles besser.
Bei komplizierteren Skripten wie bei dir kann das durchaus sein. Bei einer einfachen RPG-Cutszene würde ich dagegen niemals auf waits setzen, da der Testaufwand und die Feinjustierung sehr viel mehr Aufwand erfordern. Dieser Aufwand multipliziert sich zudem mit der Anzahl der Move Events.

[IndependentArt]

vlt ein bisschen off topic: "Allow/Forbid Event Overlap"<-- was bringt dieser befehl eigentlich...?

[Davy Jones]

Das kannst du in jedem Event einstellen.

Forbid Event Overlap sorgt dafür, dass bspw. ein NPC ein bestimmtes Feld nicht mehr betreten kann, du aber selber noch rüberlaufen kannst. So kannst du bspw. dafür sorgen, dass ein NPC nicht über die gesamte Map stiefelt, sondern hübsch in einem vorhergesehenen Bereich bleibt.

Allow Event Overlap kenne ich als Begriff nicht (zumindest nicht bei mir im 2k3), aber es dürfte sich um die Standardeinstellung in jedem Event handeln, dass dieses betreten werden darf (Ausnahme: Wenn Same Layer as Hero eingestellt wird). Für Forbid Event Overlap machste halt einfach den entsprechenden Haken rein und das wars.

[IndependentArt]

so das man quasi eine art gehege für random events erzeugen kann? ^_^

[Davy Jones]

yop =)

[IndependentArt]

Hallöle,

gibts zu dem Thema irgendwelche neuen/weiteren Erkenntnisse?

Ich hab ca. 1 Mal pro Demodurchlauf (6 Stunden) das Problem, dass das Spiel an verschiedenen Orten einfriert. Ich kann das also schwierig auf ein bestimmtes Event beziehen und die Fehler sind idR nicht reproduzierbar. Wenn ich also lade und die Passage nochmal spiele, funktioniert alles. Ab und zu ist es auch so, dass es kurz einfriert und dann weiter läuft. Hat also mit Sicherheit mit PwM zu tun. Die meisten Events auf den betroffenen Maps haben ein random Movement.

Vielleicht kann ja jemand mit tieferem Einblick *hust* was dazu sagen.

[BDraw]

Wenn ich mich recht erinnere war das Problem bei Proceed with Movement, dass nicht nur die Bewegung des aktuellen Events abgewartet wird, sondern alle Bewegungen auf der Map. Hast du noch andere sich bewegende Events in den von dir angesprochenen Situation, bzw. was genau umfasst hier "einfrieren" - Proceed with Movement dürfte ja nur ein Event anhalten, bis alle Bewegungen durch sind, aber alles andere sollte davon unbeeinträchtigt bleiben.

[Ghabry]

Also Proceed with Movement ist global, daher kann es schon passieren, dass irgendein NPC mit Move Route z.B. aufgrund eines anderen NPC, der zufällig läuft blockiert wird und der NPC mit der Move Route den [x] Skip impoosible moves (oder wie die Option hieß) Haken nicht gesetzt hat.
Würde generell von dem Befehl abraten, wenn es Zufallskomponenten auf der Karte gibt. Hatte beim spielen von Ara Fell z.B. auch ständig deadlocks wegen dieses Befehls. Kannst alternativ am Ende der Party-Moveroute einen Switch togglen, der das Routenende markiert.
Wenn es hängt kannst du (im TestPlay Modus, vom Editor aus gestartet) bei DynRPG & EasyRPG mit F11 das Spiel überall speichern und dann nachträglich den Spielstand analysieren.

Wenn die Move Route "Repeat" aktiviert hat, gilt die Bedingung von "Proceed with Movement" übrigens erfüllt, wenn die Route 1x komplett durchlief, aber ich geh mal von, das ist bekannt.

[Ken der Kot]

Also bei mir bewirkt weder Halt All Movement, noch Proceed With Movement auch nur irgendwas. Erbitte kurze Erklärung, gerne auch umfangreich, wofür das da ist.

[Brei]

Halt all Movement: Bewegungen die mit Hilfe von "move event" begonnen wurden werden gestoppt. (nicht die move pattern von events wenn ich mich nicht irre)
Proceed with Movement: Das Ende aller(!) Bewegungen die mit Hilfe von "move event" begonnen wurden wird abgewartet.
Ich schätze Proceed with Movement ist für Cutscenes gedacht, die mehrere Events bewegen und erst danach weiter ausführen sollen. Generell gehört das zu den Befehlen, die wirklich niemand nutzen sollte.

Folgende alternativen sehe ich:
In der Move-route kann man switches an und aus machen. In einem Loop kann man auf den switch warten. Ich empfehle ein "Wait for switch #123" Common event, mit einer Schleife, einem Wait und einem "If switch #123".
Davon kann man natürlich mehrere nehmen.
Alternativ kann man wohl die Dauer der Bewegung aus der Geschwindigkeit vorhersehen etc.

Für den konkreten Anwendungsfall gibt es sicher auch weitere Lösungen.

[Leana]

Standardsituation in meinen Spielen: Held läuft automatisch zu einer bestimmten Stelle und dort angekommen sagt er irgendetwas.

Diesen Ablauf erreiche ich mit der Befehlsfolge "Set Move Route", "Proceed With Movement" (= "Wait for All Movement" im legalen RM2k3), "Set Text". Würde ich "Wait for All Movement" weglassen, dann würde die Textbox bereits erscheinen, bevor der Held die gewünschte Stelle erreicht hat.

"Halt All Movement" (= "Stop All Movement" im legalen RM2k3) hab ich bisher noch nicht eingesetzt, deshalb kann ich dazu nichts sagen.

[IndependentArt]

Wenn die Move Route "Repeat" aktiviert hat, gilt die Bedingung von "Proceed with Movement" übrigens erfüllt, wenn die Route 1x komplett durchlief, aber ich geh mal von, das ist bekannt.

Nee, war mir nicht bekannt. Woher auch? XD

Konnte es jetzt reproduzieren.
Schuld war eine Gruppe von Vögeln. Die Fliegen weg, wenn man sich ihnen nähert. Im Laufe des Spiels werden es allerdings weniger. Die Move Event Befehle machen da keinen Unterschied und bewegen immer alle 5. Das läuft auch ganz normal ab, bis zum nächsten "Wait for all Movement"-Befehl. Dann friert es ein. Also der Fall, den Davy Jones auch schon beschrieben hatte.
Konnte das fixen, indem ich nur die Vögel bewege, die noch da sind.
Ich denke, wenn man das beherzigt, kann man den Befehl ruhig benutzen. Ich muss allerdings das Spiel nochmal nach potentiellen Konstellationen dieser Art abscannen ...

Aber der Tipp mit dem Switch ist auch gut, darauf bin ich noch nicht gekommen.

[Brei]

@IndependentArt: Sicherlich *kann* man den Befehl benutzen.
Man muss dann nur das ganze Spiel auf korrekte Interaktion zwischen jedem "Move Event" und jedem "Proceed with movement" absuchen.
Und kann mit jedem "Move Event" das man unbedacht einfügt kleine, schwer erkennbare, schwer reproduzierbare timing Fehler erzeugen.
Und gegebenenfalls softlocks. Und das alles ist auch noch stark timing-abhängig, daher nicht deterministisch.

Am Ende darf natürlich jeder mit dem Maker machen was er will, aber so richtig robust ist diese Arbeitsweise auch nicht.

[IndependentArt]

Ja, das muss ich mir halt jetzt einbläuen. Oder auf Switches umsteigen. Es muss eine entscheidung geben.

[Ghabry]

Muss zugeben, dass mir auch erst beim nachdenken über das Thema bewusst wurde, dass das der Sinn von "Toggle Switch" in Move Routes sein muss.

Besser wäre aber echt, wenn "Wait for Movement" eine Option gehabt hätte, wo man das Event angeben kann :/.

[IndependentArt]

Muss zugeben, dass mir auch erst beim nachdenken über das Thema bewusst wurde, dass das der Sinn von "Toggle Switch" in Move Routes sein muss.

Was meinst du damit? In Moverouts kann man doch kein Toggle angeben. Im Gegensatz zum normalen Switch Befehl.


Besser wäre aber echt, wenn "Wait for Movement" eine Option gehabt hätte, wo man das Event angeben kann :/.

Kann ja noch kommen. *zu Cherry schiel*

[G-Brothers]

Old but gold (und ein angehefteter Thread im Technikforum): "Detail-Wissen und Geheimnisse des RPG-Makers" (https://www.multimediaxis.de/threads/71-Detail-Wissen-und-Geheimnise-des-RPG-Makers-vorallem-f%C3%BCr-Erfahrene-Profis-lehrreich)

Des Weiteren hab ich versucht herauszufinden, wie lange ein "Schritt" in einem Move-Event je nach Geschwindigkeit in "Wait"-Zeit dauert...
Ich kam zu folgendem Ergebnis:


Ein Schritt mit der Geschwindigkeit "Normal" dauert In "Wait": "0,1 Sek" + 2x "0,0 Sek" (also 8x 0,0 Sek)
Ein Schritt mit der Geschwindigkeit "2xSlower" dauert In "Wait": "0,2 Sek" + 4x "0,0 Sek" (also 16x 0,0 Sek)
Ein Schritt mit der Geschwindigkeit "4xSlower" dauert In "Wait": "0,4 Sek" +8x "0,0 Sek" (also 32x 0,0 Sek)
Ein Schritt mit der Geschwindigkeit "8xSlower" dauert In "Wait": "0,8 Sek" +16x "0,0 Sek" (also 64x 0,0 Sek)
Ein Schritt mit der Geschwindigkeit "2xFaster" dauert In "Wait": 4x "0,0 Sek"
Ein Schritt mit der Geschwindigkeit "4xFaster" dauert In "Wait": 2x "0,0 Sek"
Mit diesem Wissen kann man die exakte Zeit ausrechnen.
Empfehle ich mehr als jenen verwünschten Befehl.