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 was archived by the owner on Apr 4, 2025. It is now read-only.
Quite simply this would be an additional flag for llSetKeyframedMotion(). If set to TRUE it indicates that the server should attempt to guarantee the timing of an animation, doing this either by speeding up the animation and/or skipping frames in order to get the animation to its correct frame position within the timing specified; e.g - if a frame should be five seconds, played for one and was delayed by another second, then it should aim to finish with three seconds, not four in order to catch up.
Essentially, any time an animation is interrupted, be it through lag, being grabbed etc., whenever the animation is able to resume playback the server will do a quick calculation to determine where in the animation the object should be. For example, if an animation is 30 seconds long, played for 5 seconds and was grabbed for 5 seconds, then the server should try to return it to the 10 second mark it should be at, or catch up to a reasonable point afterwards; in this case it could play at double speed for 10 seconds, causing it to catch up at the 15 second mark.
There are some alternatives for consideration however; firstly, re-synchronising when the animation resumes may be infeasible, or even unwise (if a lot of animation were delayed), so it might make more sense for the server to queue up re-synchronisations and perform them periodically, smoothing them as much as possible. The other alternative would be to give us some kind of KFM_CMD_SYNCHRONISE option which takes an additional value, namely a time-stamp to which the animation should be re-synchronised (aligning the animation's start to that time).
Why is this feature important to you? How would it benefit the community?
At the moment if a keyframed motion lags, the animation simply carries on from where it was when it continues. This is fine for some motions, particularly those for automated vehicles (elevators, trains etc.) but it's not really very good for anything that is supposed to happen in concert with other effects where lag or other interruptions will cause any effect to be ruined.
While the current behaviour is preferable for some cases, one of these proposed options would allow content creators to produce products that, while perhaps not perfectly guaranteed, would at least recover from timing irregularities.
{
'Business Unit': ['Platform'],
'How would you like the feature to work?': 'Quite simply this would be an additional flag for [{{llSetKeyframedMotion()}}|https://wiki.secondlife.com/wiki/LlSetKeyframedMotion]. If set to {{TRUE}} it indicates that the server should attempt to guarantee the timing of an animation by skipping frames in the event of lag in order to keep up.',
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': "At the moment if a keyframed motion lags, the animation simply carries on from where it was when it continues. This is fine for some motions, particularly those for automated vehicles (elevators, trains etc.) but it's not really very good for anything that is supposed to happen in concert with other effects.\r\n\r\nThe idea behind this flag is that instead of playing smoothly, an animation will speed up or even drop frames in order to complete an animation step within the given time limit. For example, if the animation stage is 5 seconds long, plays correctly for one second, then lags for a second, then instead of the stage taking 6 seconds in total the server should speed up the animation to reach the 5 second target, or skip the portion of the animation that was delayed (i.e - jump to the 2 seconds mark).",
}
The text was updated successfully, but these errors were encountered:
How would you like the feature to work?
Quite simply this would be an additional flag for
llSetKeyframedMotion()
. If set toTRUE
it indicates that the server should attempt to guarantee the timing of an animation, doing this either by speeding up the animation and/or skipping frames in order to get the animation to its correct frame position within the timing specified; e.g - if a frame should be five seconds, played for one and was delayed by another second, then it should aim to finish with three seconds, not four in order to catch up.Essentially, any time an animation is interrupted, be it through lag, being grabbed etc., whenever the animation is able to resume playback the server will do a quick calculation to determine where in the animation the object should be. For example, if an animation is 30 seconds long, played for 5 seconds and was grabbed for 5 seconds, then the server should try to return it to the 10 second mark it should be at, or catch up to a reasonable point afterwards; in this case it could play at double speed for 10 seconds, causing it to catch up at the 15 second mark.
There are some alternatives for consideration however; firstly, re-synchronising when the animation resumes may be infeasible, or even unwise (if a lot of animation were delayed), so it might make more sense for the server to queue up re-synchronisations and perform them periodically, smoothing them as much as possible. The other alternative would be to give us some kind of
KFM_CMD_SYNCHRONISE
option which takes an additional value, namely a time-stamp to which the animation should be re-synchronised (aligning the animation's start to that time).Why is this feature important to you? How would it benefit the community?
At the moment if a keyframed motion lags, the animation simply carries on from where it was when it continues. This is fine for some motions, particularly those for automated vehicles (elevators, trains etc.) but it's not really very good for anything that is supposed to happen in concert with other effects where lag or other interruptions will cause any effect to be ruined.
While the current behaviour is preferable for some cases, one of these proposed options would allow content creators to produce products that, while perhaps not perfectly guaranteed, would at least recover from timing irregularities.
Links
Is depended on by
Original Jira Fields
The text was updated successfully, but these errors were encountered: