Difference between revisions of "Talk:PlayGamebryoAnimation - ObjectReference"
imported>HawkFest (→afEaseInTime?: typos and such) |
imported>HawkFest m (→afEaseInTime?) |
||
| Line 3: | Line 3: | ||
''afEaseInTime: The amount of time to take to ease-in the animation, in seconds.'' | ''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 | 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. | ||
My question in regards to the above quote : what exactly is doing an animation "''easing-in''" itself? What is the effect of this parameter? | My question in regards to the above quote : what exactly is doing an animation "''easing-in''" itself? What is the effect of this parameter? | ||
--[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-04-06T16:12:50 (EDT) | --[[User:HawkFest|HawkFest]] ([[User talk:HawkFest|talk]]) 2013-04-06T16:12:50 (EDT) | ||
Revision as of 15:23, 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.
My question in regards to the above quote : what exactly is doing an animation "easing-in" itself? What is the effect of this parameter? --HawkFest (talk) 2013-04-06T16:12:50 (EDT)