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

Closed
fdelapena opened this Issue Jul 16, 2016 · 3 comments

Projects

None yet

5 participants

@fdelapena
Member
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
Contributor
scurest commented Jul 16, 2016
@Zegeri
Member
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
Member
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).
a6577de
@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