You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
This is a repost of SCR-73 from the defunct script project (so it's not really a duplicate, but I can't move issues).
The proposal is for the following function:
llPreloadAnimation(stringname);
The function has the same requirements as llStartAnimation() except that instead of triggering the animation, the animation is preloaded for the avatar for which the script has received PERMISSION_TRIGGER_ANIMATION.
I don't know enough about the animation system to know if this can be supported in a legacy friendly way; for example if an animation can have its priority overriden then a priority of zero could be used, since avatars always have animations running unless they've been explicitly stopped, so although the "preloading" animation would be playing on legacy viewers, it wouldn't be visible. Updated viewers could however optimise this so the animation is only downloaded and cached.
Preloading animations are counted against the limit on the number of active animations on an avatar, but could be discarded to make room if regular animations are started.
Why is this feature important to you? How would it benefit the community?
Currently there is no way to reliably preload animations except through trickery (e.g - start the "preloading" animations first followed by animations that will override, and thus hide, them). This can make it very awkward to ensure that an animation is ready before you need it.
While other proposals such as llStartAnimationSynced() can help to mitigate this, it's main purpose is to guarantee the timing of animations. This function meanwhile would ensure an animation is downloaded in advance of being needed on a per-avatar basis, hopefully avoiding any delays in which an avatar is doing nothing.
llPreloadAnimation() - Per-Avatar Preloading of Animations
Type
New Feature Request
Priority
Unset
Status
Been Triaged
Resolution
Triaged
Reporter
Haravikk Mistral (haravikk.mistral)
Created at
2014-11-19T15:05:24Z
Updated at
2015-12-16T11:44:31Z
{
'Business Unit': ['Platform'],
'Date of First Response': '2015-03-04T13:40:56.246-0600',
'How would you like the feature to work?': 'This is a repost of SCR-73 from the defunct script project (so is not really a duplicate, but I can\'t move issues).\r\n\r\nThe proposal is for the following function:\r\n\r\n{code:title=New Function}llPreloadAnimation(string name);{code}\r\n\r\nThe function has the same requirements as [{{llStartAnimation()}}|https://wiki.secondlife.com/wiki/LlStartAnimation] except that instead of triggering the animation, the animation is preloaded for the avatar for which the script has received {{PERMISSION_TRIGGER_ANIMATION}}.\r\n\r\nI don\'t know enough about the animation system to know if this can be supported in a legacy friendly way; for example if an animation can have its priority override then a priority of zero could be used, since avatars always have animations running unless they\'ve been explicitly stopped, so the "preloading" animation shouldn\'t be visible, newer viewers meanwhile would optimise this so the animation is only downloaded and cached.\r\n\r\nPreloading animations are counted against the limit on the number of active animations on an avatar.',
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': 'Currently there is no way to reliably preload animations except through trickery (e.g - starting "preloading" animations first followed by high priority animations that will override them). This can make it very awkward to ensure that an animation is ready before you need it.\r\n\r\nWhile other proposals such as [{{llStartAnimationSynced()|https://jira.secondlife.com/browse/BUG-7729] can help to mitigate this, it\'s main purpose is to guarantee the timing of animations. This function meanwhile would ensure an animation is downloaded in advance of being needed on a per-avatar basis.',
}
The text was updated successfully, but these errors were encountered:
Haravikk Mistral commented at 2014-11-19T15:23:06Z, updated at 2015-11-19T11:45:31Z
Just wanted to note the relation to BUG-7854 since there's a little overlap; both would allow preloading of animations, however the major difference is that llPreloadlAsset() allows each viewer encountering the object to preload a single animation before any script(s) have triggered, this is perfect for preloading the first animation in a set, or for a sit animation if there is only one.
Meanwhile this function is more useful for preloading animations on avatars that are already being animated. For example, in a dance system, if there is an upcoming dance then it can be set as preloading before it is actually needed, before playing it and stopping the previous animation. Basically this function allows for sequences of animations on a per-avatar basis, while preload asset is useful for preparing avatars to begin animating in the first place.
How would you like the feature to work?
This is a repost of SCR-73 from the defunct script project (so it's not really a duplicate, but I can't move issues).
The proposal is for the following function:
The function has the same requirements as
llStartAnimation()
except that instead of triggering the animation, the animation is preloaded for the avatar for which the script has receivedPERMISSION_TRIGGER_ANIMATION
.I don't know enough about the animation system to know if this can be supported in a legacy friendly way; for example if an animation can have its priority overriden then a priority of zero could be used, since avatars always have animations running unless they've been explicitly stopped, so although the "preloading" animation would be playing on legacy viewers, it wouldn't be visible. Updated viewers could however optimise this so the animation is only downloaded and cached.
Preloading animations are counted against the limit on the number of active animations on an avatar, but could be discarded to make room if regular animations are started.
Why is this feature important to you? How would it benefit the community?
Currently there is no way to reliably preload animations except through trickery (e.g - start the "preloading" animations first followed by animations that will override, and thus hide, them). This can make it very awkward to ensure that an animation is ready before you need it.
While other proposals such as
llStartAnimationSynced()
can help to mitigate this, it's main purpose is to guarantee the timing of animations. This function meanwhile would ensure an animation is downloaded in advance of being needed on a per-avatar basis, hopefully avoiding any delays in which an avatar is doing nothing.Links
Related
Original Jira Fields
The text was updated successfully, but these errors were encountered: