ID:132257
 
I don't use pixel movement for anything but I do use some of the features such as bound_width, bound_height, and step_size for icons larger than 32x32(I only use them in multiples of 32). Before the most recent update everything worked great. But with this recent update, just because I decide to use bound_width and height I now have jumpy movement. I really think it should go back to the way it was in BYOND 490.1105.
This is because the pixel movement was supposed to be used for projects that allowed movement spaces lower than the icon_size, the lower step_size compensated for the lack of glide. What are you doing anyways that uses bounds but not pixel movement?
AbdelJN wrote:
I don't use pixel movement for anything but I do use some of the features such as bound_width, bound_height, and step_size for icons larger than 32x32(I only use them in multiples of 32). Before the most recent update everything worked great. But with this recent update, just because I decide to use bound_width and height I now have jumpy movement. I really think it should go back to the way it was in BYOND 490.1105.

I think we can account for the tile multiple case.
In response to Lummox JR (#2)
Danbriggs wrote:
This is because the pixel movement was supposed to be used for projects that allowed movement spaces lower than the icon_size, the lower step_size compensated for the lack of glide. What are you doing anyways that uses bounds but not pixel movement?

Large objects...

Lummox JR wrote:
I think we can account for the tile multiple case.

Alright that's great but also what about step size as well? I think glide should be disabled if you aren't using step_size in increments of 32. I use a step size of 64 for faster objects such as small weapons and such.