- Joined
- Aug 25, 2014
- Messages
- 27
- Reaction score
- 2
- First Language
- Portuguese
- Primarily Uses
It seems to me that the problem comes from the way diagonal movement was implemented. The player moves, for example, up and left simultaneously at the normal speed towards each direction, making the resulting diagonal speed faster than normal. You tried to work around this by giving us an option to reduce movement speed when the player is moving in two directions at the same time.
The first problem is that the followers' speed is reduced at the same time as the player's. This means that when the player starts moving diagonally, the followers are still moving straight, but their speed is already reduced. This makes them lag behind.
The second problem is that, even when moving diagonally, the followers are still slower than the player, and they lag behind more and more. I have no idea why this happens, tbh.
My solution to this would be to make pixel diagonal movement not truly diagonal - when holding up and left, the player would alternate between up and left moves instead of doing both simultaneously. But if you did this, you'd need a check to lock the character sprite in one direction instead of alternating really fast. I'm not sure how feasible this is within your system, though, and it's probably not the optimal way to do it. I wonder what other pixel/diagonal movement scripts do?
EDIT: Never mind, I've just tried something similar, and it looks really jerky.
EDIT 2: I FIXED IT! The follower movement isn't perfect, but it's quite good, and I'm sure you can find a way for it to work better. Here's what I did:
def speed if @diagonal 2**real_move_speed / 11.31370849896 else 2**real_move_speed / 8.0 endendEDIT 3: I've just found an unrelated bug. Qmove works fine for movement speeds 1, 2 and 3 (if you use a 1px grid and a 32 multiplier, the event walks 1 square), but if you use speed 4, it walks 2 squares. If you use speed 5, it walks 8 squares, and so on.
The first problem is that the followers' speed is reduced at the same time as the player's. This means that when the player starts moving diagonally, the followers are still moving straight, but their speed is already reduced. This makes them lag behind.
The second problem is that, even when moving diagonally, the followers are still slower than the player, and they lag behind more and more. I have no idea why this happens, tbh.
My solution to this would be to make pixel diagonal movement not truly diagonal - when holding up and left, the player would alternate between up and left moves instead of doing both simultaneously. But if you did this, you'd need a check to lock the character sprite in one direction instead of alternating really fast. I'm not sure how feasible this is within your system, though, and it's probably not the optimal way to do it. I wonder what other pixel/diagonal movement scripts do?
EDIT: Never mind, I've just tried something similar, and it looks really jerky.
EDIT 2: I FIXED IT! The follower movement isn't perfect, but it's quite good, and I'm sure you can find a way for it to work better. Here's what I did:
def speed if @diagonal 2**real_move_speed / 11.31370849896 else 2**real_move_speed / 8.0 endendEDIT 3: I've just found an unrelated bug. Qmove works fine for movement speeds 1, 2 and 3 (if you use a 1px grid and a 32 multiplier, the event walks 1 square), but if you use speed 4, it walks 2 squares. If you use speed 5, it walks 8 squares, and so on.
Last edited by a moderator:
LAYERBOX[0]v[1] ||= Quasi::Movement:
