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.

One goal being to code a script which would be reusable as much as possible, here's an example... Instead of doing:

Float Property fOpenAnimationTiming Auto
...
rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True, afEaseInTime = fOpenAnimationTiming)
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):

Float Property fOpenAnimationTiming Auto
...
If rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True)
    Utility.Wait(fOpenAnimationTiming)
EndIf
rContainerHUB.Activate(akActionRef)

We could add a Wait instruction above the If statement so as to add some delay before the animation takes place. Note that using the afEaseInTime parameter in the above code can be done : I haven't encountered one yet, but maybe that there are GameBryo animations requiring some "easing-in"? Nonetheless, those which had their timing skipped over via this parameter should be ok thanks to the Wait instruction following it. However, the parameter still renders another flaw : in-game asynchronous processing between sound and animation.

Now a 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 if not a bug.

EDIT : Conclusion - Trying to find an answer, I just used the above code adding the parameter afEaseInTime = 1.0, with a wait time of 1.5. When attached to a dwemer chest, in-game I can see the animation beginning right away, but its sound is processed 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 (those containers I've tried had solely their sound being "eased-in", not their animation), to be used in all confidence from within a reusable script. For that context, use the above suggested method instead. --HawkFest (talk) 2013-04-06T16:12:50 (EDT)