-
Notifications
You must be signed in to change notification settings - Fork 190
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
Set Move Route with Wait for movement: Turn 90° behaviour difference #2790
Comments
You found an edge-case here :) RPG_RT.exe has both Facing and Direction. In Player talking to an Event only updates the Facing but the Turning uses the Direction. |
Checked the RPG_RT implementation of talking to an event and this matches with ours. This means something else triggers that Direction update. Will need some work to figure this out :/ |
At least So it could be related to the jumping |
@TrunXGIT I need more context. The Move Route executes exactly like in RPG_RT. The problem is something else. Please send the entire project. |
Added the above mentioned move route without the jumping to a NPC and also a NPC with 180° (walk three steps aways from player and come back) to the sample project: All three NPCs behave different in rpg_rt.exe compared to player.exe. Player.exe is still using the initial facing direction as the starting point before the player interacted with the NPC. Here a screenshot from Player.exe once I interacted with each NPC: |
The difference is the "Wait for All Movement" command. When the command is missing it behaves like Player. o_O |
When you talk to a NPC/Event it automatically changes its facing direction towards the player.
Now if you use the Set Move Route command to turn it 90° left or right it behaves differently.
On RPG_RT.exe: It changes its direction relative to the current (changed) facing direction
Example GIF:
On Player.exe: It changes its direction relative to its original facing direction before the player interacted with the Event.
Example GIF:
Move Route that was used int the examples:
(I even tried out a manual "Turn toward Player" at the very beginning, but the behaviour stays the same in both cases.)
I assume this could be a critical bug desyncing the games from its intended behaviour in cut-scenes. Resulting in just a visually different behavior in best case and bringing the game to a complete halt in worst case (if the "Skip If Cannot Move" checkbox is not ticked).
The text was updated successfully, but these errors were encountered: