Difference between revisions of "Talk:PlayGamebryoAnimation - ObjectReference"
imported>HawkFest (→afEaseInTime?: added an example) |
imported>HawkFest |
||
Line 10: | Line 10: | ||
<source lang="papyrus">rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True, afEaseInTime = 0.5) | <source lang="papyrus">rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True, afEaseInTime = 0.5) | ||
rContainerHUB.Activate(akActionRef)</source> | rContainerHUB.Activate(akActionRef)</source> | ||
which either skips all timings, either breaks the synchronization between sound and animation... | 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 parameters others don't)... | ||
We should do: | We should do the following which works with all types of embedded animations (thus being more "generic"): | ||
<source lang="papyrus">If rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True) | <source lang="papyrus">If rVisibleContanier.PlayGamebryoAnimation("Open", abStartOver = True) | ||
Utility.Wait(0.5) | Utility.Wait(0.5) |
Revision as of 20:41, 6 April 2013
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 parameters others don't)...
We should do the following which works with all types of embedded animations (thus being more "generic"):
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? --HawkFest (talk) 2013-04-06T16:12:50 (EDT)