ID:2247975
 
Not a bug
BYOND Version:511
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 57.0.2987.133
Applies to:DM Language
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

Altering pixel_z with animate() no longer behaves correctly. Noticed immediately when running my game after updating from 510 to 511. Prior to the update, the following code would cause src to rise upward by 16 pixels
animate(src, pixel_z = 16, time = 3)

Now, src lowers for some reason and by what appears to be less than 16 pixels

Workarounds:

Strangely, using a negative integer causes src to go up but it still doesn't look as good as it did prior to the update.


I unfortunately can't show a side-by-side comparison considering I'm now running 511

Lummox JR changed status to 'Unverified'
I need a test case. When I tried this it worked exactly the way it was supposed to.
Lummox JR wrote:
I need a test case. When I tried this it worked exactly the way it was supposed to.

https://i.gyazo.com/c9fc3a0b4390e425e940eccafa0cfd83.gif

Just an animate(), a single step(), and then resetting the pixel_z afterward:
animate(src, pixel_z = 16,time = 3)
step(src, thisDir)
src.pixel_z = 0
That code isn't going to do what you want it to do. Resetting the pixel_z immediately will mess up your animation; you should reset it in another step (best) or after a sleep() instead.
In response to Lummox JR
Lummox JR wrote:
That code isn't going to do what you want it to do. Resetting the pixel_z immediately will mess up your animation; you should reset it in another step (best) or after a sleep() instead.

Adding a spawn before resetting pixel_z with another animate() with time = 0 solved the issue, but why did the same code behave completely differently prior to the update? I'm guessing it was actually broken before and fixed in 511?
In response to SolarOblivion
Yes, that's probably the case. A number of animation fixes went in for 511.
Lummox JR resolved issue (Not a bug)
Changing a var that is currently controlled by an animation has never screwed with the animation before.
I'm assuming that was the buggy behavior that got resolved then.
I'd really hope not because alot of /tg/ animate shit relies on it
The basic theory behind it is that the var change alters the animation's starting and ending points. Animating pixel_z from 0 to 16 and resetting pixel_z before the animation plays should translate to animating from -16 to 0.
We use it mainly to reset transforms.

The biggest issue with animating things is returning to the original after the animation ends. Almost all of our animations are temp, Screen shaking, spinning something while it's being thrown, animating the space backdrop when the shuttle goes into hyperspace, etc. We try to keep these animations state agnostic. Ie, it does not assume anything about the state of the object that was sent to it.

If you keep the original cached/stored for too long it can become stale if another animation triggers on that same object, as now the temp version gets cached.

So we generally queue the animation steps, and then immediately reset the variable back to what it was.

And I can't add animation steps for this because most of the cases of animations are infinite loops that stop on some other trigger.

At the end of the day, the animation should be base off the value of when it was triggered, not when the client got the animation message.

So this is a race condition if changing the value after you trigger the animation (and even before the next tick) changes the animation.
Animations are based on the value when it was triggered, but the problem here is that they need to be responsive to changes in the vars. If you're animating pixel_x from 0 to 8, then pixel_x += 2 should change that to 2 to 10.
Strictly speaking that would be a new feature that as far i can tell wasn't documented.

When did this happen? We've been having some odd issues with some of our animations that might be explained by this.

Don't get me wrong, I can see the benefit, but up until now I've been able to assume that once an animation controls a var you can safely change the server side version of that without it affecting the clients.

Ie, animations detach client's version/view of appearance vars from the server.

When it's a relative var like pixel offsets, complete detachment of that var from the server appearance is not intended. In fact a number of bug reports have been handled and fixed on that subject.

Vars that should act detached are ones like icon, icon_state, etc.

IIRC, color behaves more like pixel offsets in this area.

Login to reply.