Descriptive Problem Summary:
When two objects or mobs are moving in sync with the same glide_size values, they will often de-sync and one will lag behind the other, or vice versa. The expected behavior is for them to move completely in unison.
Example:
http://i.imgur.com/aSk6Czf.gifv
If there's any more information that's needed, I'll try to provide it.
ID:2013703
 Jan 6 2016, 7:14 pm
|
|||||||||||||
Resolved
| |||||||||||||
|
Jan 6 2016, 7:19 pm
|
|
Lummox JR
  |
Any chance you can make this into a quick demo I can look at?
|
Sure. I've compiled a simple test case that has a noticeable difference between DreamSeeker and the Webclient:
https://dl.dropboxusercontent.com/u/10657252/ byond_glidesize.rar | |
Thanks.
| |
Uhm, you didn't even set animate_movement to SYNC_STEPS in your demo.
| |
I haven't tested this with the webclient yet, but I just wanted to let you know that you don't need to use the diagonal calculation; you can set appearance_flags to LONG_GLIDE as of 509.
| |
I did find a bug here, although it was a tricky one to suss out. There were actually a couple of parts to it, one of which was that id:1947630 hadn't been fixed yet (which it has now; it'll be fixed in the next release). But the other part was a subtle, accidental difference in the same-direction logic used by Dream Seeker and the webclient, which caused the sync issue in your code to be much more prominent in the webclient than in DS. So that's been fixed, and now the webclient looks just like DS in this regard.
That said, you do have a sync issue in your code that shows up in both DS and the webclient. The problem is that you're altering glide_size after moving instead of before; altering it before the move is much safer and doesn't result in so many hiccups. (Of course the alteration itself is obviated by LONG_GLIDE and 509's addition of floating point glide sizes.) | |
Lummox JR resolved issue with message:
Gliding was sometimes inconsistent with Dream Seeker's behavior. | |