Difference between revisions of "Talk:PlayGamebryoAnimation - ObjectReference"
imported>HawkFest (→afEaseInTime?: new section) |
imported>HawkFest |
||
| Line 5: | Line 5: | ||
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. For some others like the CommonWardrobe, it makes sound vs animation asynchronus - a solution 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. | 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. For some others like the CommonWardrobe, it makes sound vs animation asynchronus - a solution 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 is | 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:14, 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. For some others like the CommonWardrobe, it makes sound vs animation asynchronus - a solution 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)