animate() triggers client disconnect after period of time

ID:2947633
 
Oct 9, 11:19 am
BYOND Version:515
Operating System:coffee
Web Browser:black widow
Applies to:Dream Seeker
Status: Deferred
This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
When calling animate() a whole bunch of times (like every tick) it causes the client to disconnect with a bad read error.

Numbered Steps to Reproduce Problem:
see code

Code Snippet (if applicable) to Reproduce Problem:
mob
    step_size = 8
    proc/Tick()
        animate(src, time = world.tick_lag*2, transform = null)
        // doesn't matter what you're animating.  ie: not specific to transform


Expected Results:
no crashy crashy

Actual Results:
zoom zoom skrrrrrrrrrrrch bang

Does the problem occur:
Every time? Or how often?
all the time
In other games?
only if they do the dumb stuff i do
In other user accounts?
doubt this has any impact
On other computers?
last time i tried to test a bug on my girlfriends laptop she got mad because it caught on fire

When does the problem NOT occur?
when you don't run the code that causes the bug

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
The opposite of the problem wasn't not presently not occuring in 515.

Workarounds:
don't run the code that causes the bug

Oct 9, 1:07 pm
Lummox JR changed status to 'Deferred'
Oct 9, 1:11 pm
So I've looked into this and I'm noting the issue for when I return to it in the future.

The problem is that multiple animation sequences are piling up on each other and being superseded. The example creates a situation where an animation sequence takes 2 ticks, but a new one supersedes it at the halfway point. The previous sequence has to be kept so a transitional appearance can be computed.

I've temporarily added a small sanity check that deals with the test case by dropping sequences that do nothing, but that obviously doesn't solve the problem generally.

The general solution to this will necessarily involve making the server handle some appearance interpolations like the client does. For obvious reasons (maintaining two near-identical code paths, for one) this is far from ideal, and will be a bit of a project in itself. So I'm shelving that for now.
Oct 11, 9:41 am
ANIMATION_END_NOW and ANIMATION_PARALLEL flags do in fact solve the crash, and since the animation is so quick the difference in effect is barely noticable.