New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
5 participants
@Zegeri
Member

Zegeri commented May 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Ghabry

Ghabry May 2, 2016

Member

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

Member

Ghabry commented May 2, 2016

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

@Zegeri

This comment has been minimized.

Show comment
Hide comment
@Zegeri

Zegeri May 7, 2016

Member

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.
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 added a commit to scurest/Player that referenced this issue Jun 12, 2016

Fix EasyRPG#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.

scurest added a commit to scurest/Player that referenced this issue Jun 13, 2016

Fix EasyRPG#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.

scurest added a commit to scurest/Player that referenced this issue Jun 17, 2016

Fix EasyRPG#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.

scurest added a commit to scurest/Player that referenced this issue Jun 17, 2016

Extend EasyRPG#884 to move the player early too.
For EasyRPG#703, Shibe no longer blocks your movements. However, he still
trails your movement by one frame.
@scurest

This comment has been minimized.

Show comment
Hide comment
@scurest

scurest Jun 17, 2016

Contributor

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

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

Ghabry added a commit that referenced this issue Jul 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment