Pom Gets Wi-Fi: Interpreter stops after a "Stop!" message #937

fdelapena opened this Issue Jul 16, 2016 · 3 comments


None yet

5 participants

fdelapena commented Jul 16, 2016 edited

The issue title is pun intended, but it really happens 😆.

Game. Savegame.

To trigger the halt sequence, press the decision key with the dog or with the door. After some dog advice and a transition, the door will be opened and a dog will say a "Stop!" message and interpreter halts. Some dogs should appear and start a battle instead. Earlier master versions were working there, so this is a regression.

Actual Bug
When a event that is "Waiting" collides with another event the wait timer reduces faster (depending on how many are colliding), so when one collides the wait countdown is twice as fast.

@fdelapena fdelapena added this to the 0.5.0 milestone Jul 16, 2016
scurest commented Jul 16, 2016
Zegeri commented Jul 18, 2016 edited

Here's the explanation: In the map 21 (The Gate Open2), the event EV0004 tries each frame to walk where EV0005 is. The move route of EV0004 is skippable. EV0005 has a parallel event with a ProceedWithMovement.

In EasyRPG, EV0004 tries to walk where EV0005 is. Because of #884, EV0005 runs its interpreter early, executes ProceedWithMovement and, because EV0004 is still moving, doesn't continue. After that, EV0004's movement fail. Because it's a skippable move route, the move route ends.

In RPG_RT, things go the same way but after all that, EV0005's interpreter gets updated a second time. This time, EV0004 doesn't have an overwritten move route, so it passes the ProceedWithMovement command.

I'm not sure in what circumstances does an event get update twice.

Ghabry commented Jul 21, 2016

In the meanwhile we know that it's the collision which causes this behaviour.

As a notice for the laaaaaaaate future when the editor is ready: The Player should offer for EasyRPG games a "Engine: EasyRPG" mode which does not emulate such bugs. ;)

@Zegeri Zegeri added a commit to Zegeri/Player that referenced this issue Aug 7, 2016
@Zegeri Zegeri Use wait_count for waiting Pan Screen commands
For better compatibility with original save games and to reproduce correctly the behaviour of RPG_RT in the rare case of a parallel event running a waiting Pan Screen while other events walks against it (like in the cutscene of #937).
@Ghabry Ghabry closed this in 481dcf3 Aug 8, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment