ID:2224425
 
Resolved
Sync issues could cause movement animations to reset in some pixel gliding cases.
BYOND Version:511.1377
Operating System:Windows Vista Home Premium 64-bit
Web Browser:Chrome 56.0.2924.87
Applies to:Dream Seeker
Status: Resolved (511.1378)

This issue has been resolved.
Descriptive Problem Summary:

In our game we are using pixel movement based system. Before the BETA of 511's Build the movement was fine but after updating I noticed that when you hold dow the macro button the character walks for about a second and the icon changes according to the direction but then after that second your character continues to move but no icon cchanges. So its like the still state that shows.


Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
mob
key_down(k){..()}
key_up(k,hold){..()}


mob
keydown(k as text)
..()
if(k=="north"){instructy = 1;instructx=0;movement()}
if(k=="south"){instructy = -1;instructx=0;movement()}
if(k=="east"){instructx = 1;instructy=0;movement()}
if(k=="west"){instructx = -1;instructy=0;movement()}
if(k=="shift"){movement_run=1;movement()}

mob
proc

movement_step(xx,yy,zz)
if(xx)
step_size = round(sqrt(xx*xx),1)
if(xx>0) step(src,EAST)
else step(src,WEST)
//yy = 0
if(yy)
step_size = round(sqrt(yy*yy),1)
if(yy>0) step(src,NORTH)
else step(src,SOUTH)
//xx = 0
if(zz)
if(zz>0)
if(step_z + bound_depth-1 + zz > nearestroof()) step_z = nearestroof - bound_depth - 1
else step_z += zz
if(zz<0)
if(step_z + zz < nearestfloor()) step_z = nearestfloor
else step_z += zz
if(step_z == nearestfloor)
onfloor()
pixel_y = initial(pixel_y)+step_z


movement()
if(movement || movement_to)return 0
//adjust movement flag to true given that movement has began
movement = 1
var
pdir = dir
movement_limit = movement_max
while(movement)
if(stopmove()) break
if(movement_to) break

if(movement_run||usr.In_Battle)movement_limit = movement_max+10
else movement_limit = movement_max
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////
//////////////////////////////////////////////////////
//checks if a constant x movement is being carried out
if(instructx)
//checks if the x movement is positive (EAST)
if(instructx>0)
if(movement_x+movement_accel>movement_limit)movement_x=movement_max
else movement_x+=movement_accel
//checks if the x movement is negative (WEST)
if(instructx<0)
if(movement_x-movement_accel<-movement_limit)movement_x=-movement_max
else movement_x-=movement_accel
//checks if there is a movement_x to decelerate
else if(movement_x)
if(movement_x>0)
if(movement_x-movement_decel<0)movement_x=0
else movement_x-=movement_decel
if(movement_x<0)
if(movement_x+movement_decel>0)movement_x=0
else movement_x+=movement_decel
//checks if a constant y movement is being carried out
if(instructy)
//checks if the y movement is positive (NORTH)
if(instructy>0)
if(movement_y+movement_accel>movement_limit)movement_y=movement_max
else movement_y+=movement_accel
//checks if the y movement is negative (SOUTH)
if(instructy<0)
if(movement_y-movement_accel<-movement_limit)movement_y=-movement_max
else movement_y-=movement_accel
//checks if there is a movement_y to decelerate
else if(movement_y)
if(movement_y>0)
if(movement_y-movement_decel<0)movement_y=0
else movement_y-=movement_decel
if(movement_y<0)
if(movement_y+movement_decel>0)movement_y=0
else movement_y+=movement_decel


Expected Results:
Normal walking, icons to corespond.
Actual Results:
User alks in one state and frame
Does the problem occur:
Every time? Or how often? Everytime
In other games? Havent noticed
In other user accounts? Yes
On other computers? Yes

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? 510.1347

Here's what I need:

1) A test project that shows the problem in action.
2) You to edit your report and put in the actual full version number, because "511 beta build" is not an acceptable value for that field.
Ok. How can i send the test project?
If you upload it somewhere you can just page me a link. Be sure you compile just before packaging the source, so DM includes all the files..
ok. will do in the next couple of minutes
I noticed a bit of a slight change for the better when i doubled the frame rate to 50 instead of 25. Its just a little glitchy now
Lummox JR resolved issue with message:
Sync issues could cause movement animations to reset in some pixel gliding cases.
So how do we go about solving this issue?
A couple things I noticed in your source:

1) You set world.loop_checks = 0. That is a terrible, terrible thing to do except on a temporary basis. If your code hits an infinite loop, it will never stop. Turn loop checks back on.

2) In movement_step(), this code is no good:

if(xx)
step_size = round(sqrt(xx*xx),1)
if(xx>0) step(src,EAST)
else step(src,WEST)
//yy = 0
if(yy)
step_size = round(sqrt(yy*yy),1)
if(yy>0) step(src,NORTH)
else step(src,SOUTH)
//xx = 0

What you want instead is:

if(xx || yy)
var/d=0, ax=abs(xx), ay=abs(yy)
if(ax*2 >= ay) d |= (xx > 0) ? EAST : WEST
if(ay*2 >= ax) d |= (yy > 0) ? NORTH : SOUTH
step_size = -round(-sqrt(xx*xx+yy*yy)) // round up
Move(loc, d, step_x+xx, step_y+yy)

Taking the horizontal and vertical steps separately is a recipe for trouble. The code to calculate d just gets a rough facing direction from the offset.
OK Great, thank you! Will defintely be changing that. So runnig them seperately actually can cause issues? and what about the main issue?

Also heres another problem I am having: http://www.byond.com/forum/?post=2222504
The main issue was a bug, which will be fixed in the next release.
Great! Good to hear