ID:2139023
 
Resolved
In pixel movement mode, objects jumping across a large distance to the east or north still ended up doing a pixel glide instead of a jump.
BYOND Version:511.1353
Operating System:N/A
Web Browser:N/A
Applies to:Dream Seeker
Status: Resolved (511.1354)

This issue has been resolved.
Descriptive Problem Summary:

Pixel gliding still happens inappropriately when moving an object far east or north, instead of treating the movement as a jump.

Code Snippet (if applicable) to Reproduce Problem:
// step_size is 0 or 1 tile worth
obj/verb/Jump()
set src in world
y += 2


Expected Results:

The movement should be a jump, not a glide.

Actual Results:

The object glides.
Lummox JR resolved issue with message:
In pixel movement mode, objects jumping across a large distance to the east or north still ended up doing a pixel glide instead of a jump.
I'm experiencing an issue with this. Before this change my mobs would jump their step_size (usually 3-6) when tapping west or south; it looked jumpy and ugly. Now it happens in every direction and makes all initial movement jumpy and ugly.

It can end up with people moving around without ever gliding if they take their time to just tap the key.



However, once the initial jump occurs all other movement is a glide.



(my movement uses step() calls)

I don't want to post this as a bug if it's intended behavior, but I feel like this change wasn't meant to effect small increments like this, given your use of "large" and "far".
If you have a test case, please send me a zip and I'll look at it.
Reformist, I took a look at your test project and it turns out it's a different issue.

In your project you're spawning a movement loop, and the way the loop is initiated by a spawn/sleep, or even by just a command directly, is the problem. The keyboard commands are coming in right after the map has been sent, and this causes the movement loop to trigger immediately. Unfortunately when the loop sleeps, it reawakens before the next map send. That's actually better, but the trouble lies in the fact that the loop has run twice in a row now without a map update.

So the issue you're seeing isn't new to the beta; it's a result of timing oddities. The best way I've found to solve this for now is to have a single global movement loop, instead of turning an individual loop on or off whenever something moves. In a future version, I think I'll want some kind of var indicator to say if maps have been sent this tick, which can be used to fine-tune your loop.

The code with that key1, key2, key3, key4 stuff needs an overhaul, BTW. Since you're simply tracking whether a directional key is on or off, you should just use bitflags for that, and a single var; it will simplify the logic enormously.