Order of updates of events that walk into each other is incorrect #884

Closed
Zegeri opened this Issue May 2, 2016 · 3 comments

Projects

None yet

5 participants

@Zegeri
Member
Zegeri commented May 2, 2016 edited

Here's to document some really crazy behaviour in RPG_RT.
Imagine you have some events lined up. Each of them has a move route that makes them walk to the position of the event right next to it, like here:
captura de pantalla_2016-05-02_20-23-35
In RPG_RT, they all walk together nicely without colliding into each other. While in Player some of them will collide with the one right next to it for a frame and create enought space between them to walk. If the events have IDs 1, 2, 3 and 4 and they're in the map lined up horizontally in that order from left to right. Player will update first the event 1, that will try to walk right and collide with 2. 2 will collide with 3 and 3 with 4. 4 can walk, so it'll be slightly ahead of the rest of them. In the next frame, 3 gets slightly ahead of 1 and 2. And so on.
captura de pantalla_2016-05-02_20-38-29
(Image from Player. Up: From left to right, events 1, 2, 3, 4 collide as described. Down: From left to right, events 4, 3, 2, 1 don't collide)
Here's the interesting part, in RPG_RT it doesn't matter the order of events, they all walk always together. Ghabry's eventtracer is again useful to tell what's happening. Let's use the followind ordering of events: 2, 1, 4, 3. The tracer reports that the order of execution the move commands has been 1, 4, 3, 2. Weird, we expected 1, 2, 3, 4. After trying other permutations it can be deduced that when an event checks the passability of a tile, it executes the move route of the events that are in that tile to see if they move out of the way. So in that last example, 1 is causing 4 to update because he's in the way, which is causing 3 to update because he's in the way. 2 isn't blocking anyone, so he gets updated as soon the tree of updates that 1 leads ends.
de
Crazy stuff.

Download a test sample. This bug will be fixed when the two lines of events walk with the same spacing between them.

@Ghabry
Member
Ghabry commented May 2, 2016

Wow, RPG_RT is really smart at this point. Very unexpected feature :o

@Zegeri
Member
Zegeri commented May 7, 2016

Some notes:

  • In RPG_RT, some variable must be used to make sure an event doesn't get updated twice. After some experiments with eventtracer, it seems that the DynRPG field Character::_unknown_74 is responsible for this. In PepsiOtaku's fork, this variable was (erroneously) renamed to onMap.
  • Notice that in Player, move routes and parallel interpreter are updated together (Game_Event::UpdateParallel). This still holds in this circumstances. In the last example, event 1 not only executes the move routes of event 4, but it also updates its interpreter if it's a parallel event.
  • The hero might also get updated early by this mechanism. Because of this, events will be able walk to the hero's position at the same frame the player press a movement key. This is relevant for #703.
@scurest scurest added a commit to scurest/Player that referenced this issue Jun 12, 2016
@scurest scurest Fix #884.
Game_Character::IsPassable becomes Game_Character::MakeWay, which does the same
thing but tries to update events to make room for self. Additionally, only one
pass through the events is made to check both the old and new coordinate.
7f54b8a
@scurest scurest added a commit to scurest/Player that referenced this issue Jun 13, 2016
@scurest scurest Fix #884.
Game_Character::IsPassable becomes Game_Character::MakeWay, which does the same
thing but tries to update events to make room for self. Additionally, only one
pass through the events is made to check both the old and new coordinate.
dd6c2e0
@scurest scurest added a commit to scurest/Player that referenced this issue Jun 17, 2016
@scurest scurest Fix #884.
Game_Character::IsPassable becomes Game_Character::MakeWay, which does the same
thing but tries to update events to make room for self. Additionally, only one
pass through the events is made to check both the old and new coordinate.
a557feb
@scurest scurest added a commit to scurest/Player that referenced this issue Jun 17, 2016
@scurest scurest Extend #884 to move the player early too.
For #703, Shibe no longer blocks your movements. However, he still
trails your movement by one frame.
1956502
@scurest
Contributor
scurest commented Jun 17, 2016

I notice Github has decided to make it extremely obvious that I had to --amend >_>

@scurest scurest referenced this issue Jun 19, 2016
Merged

Fix #703, #884 #913

@Ghabry Ghabry added this to the 0.4.2 milestone Jul 9, 2016
@Ghabry Ghabry closed this in #913 Jul 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment