Talk:PlayGamebryoAnimation - ObjectReference

afEaseInTime?

afEaseInTime: The amount of time to take to ease-in the animation, in seconds.

I've been playing around with this in container scripts that are used in conjunction with storage hubs between player homes. I found out that most of the time, this parameter interferes with sound synchronization. For some containers like NobleChestDrawers, it is somewhat mandatory else the animation would be rendered completely in a snap, instead of the intended animation timing. However the animation sound doesn't get processed. For some others like the CommonWardrobe, it makes sound vs animation asynchronous, the sound beginning to play at the end of the animation. A solution to the later issue is to not use afEaseInTime, and follow the PlayGamebryoAnimation instruction with a Utility.Wait(x.xx). Usually around 0.3 for close animations and between 0.5 to 1.0 for open animations.

EDIT - Let's say we want to animate a visible container (such as Wardrobe container) just before activating another container from within the code. the PlayGamebryoAnimation("Open") instruction by itself would make the game skip over the open animation (a huge part of it) and show the hidden container's inventory right away. Controlled timing is necessary. An example...

Instead of doing:

rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True, afEaseInTime = 0.5)
rContainerHUB.Activate(akActionRef)

which either skips all timings, either breaks the synchronization between sound and animation (depending on the container base embedded animation it seems, some work with this parameter others don't)...

We should do the following which works with all types of embedded animations (thus being a more "generic" method):

If rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True)
    Utility.Wait(0.5)
EndIf
rContainerHUB.Activate(akActionRef)

Now my question : regarding the above quote from the article, what exactly an animation "easing-in" itself is doing? What is the effect of the afEaseInTime parameter? I have the feeling I'm missing something here...

EDIT : trying to find an answer, I just used the above code adding the parameter afEaseInTime = 1.0, with a wait time of 2.0. When attached to a dwemer chest, in-game I can see the animation beginning right away, but its sound begins a second later. Because of a greater Wait time, the animation is however fully rendered along (but not synchronized) with its sound. My guess is that the motivation behind this parameter would be to impose some delay before the animation takes place, however it's too erratic (sometimes broken for those container objects I've tried it with) to be used in all confidence. --HawkFest (talk) 2013-04-06T16:12:50 (EDT)