Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-139305] Gestures containing the "BigSmile" built-in animation take way too long to load #2498

Open
3 tasks
sl-service-account opened this issue Oct 27, 2017 · 6 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Oct 27, 2017

Steps to Reproduce

  • Make a new gesture.

  • Remove the sound step, replace the "Wave" animation with "BigSmile".

  • Add a chat step that says "/me smiles" to be sure the avatar makes an emote at the same time (so you know when the gesture actually starts).

  • Save the gesture, play it through chat or preview it from the Gesture window. In fact, previewing it from the Gesture window is preferable because the "Stop" button appears and lets you stop the gesture without having to wait for its completion. In fact, this simple gesture is so quick that you should not see the "Stop" button at all, if it worked.

  • After something like 2 minutes and a half, the gesture should finally play. But it is way too late if you intended to play the gesture in response to someone else saying something, you will play the gesture completely out of place.

    Actual Behavior

    Since v5.0.8 or v5.0.7, I can't really be sure, gestures containing the built-in "BigSmile" animation that animates the system head take forever to play, while other gestures (even those that play an animation) play right away.

    I am not clear whether it takes a while because it takes a long time to download (it shouldn't, most animations are usually really fast to load, faster than notecards), or because the viewer only checks the queue of gesture steps once in a while.

    Expected Behavior

    The gesture should load and play immediately, especially if the animation is already in the cache.

    Other information

    I've had random results after replacing "BigSmile" with "Smile" (the simple closed lips smile), in one case the gesture suddenly worked fine even after reverting to its original faulty content.

    I'm flagging this as major because some people like to play such an animation with a gesture, and they can't reliably do it anymore.

Links

Duplicates

Original Jira Fields
Field Value
Issue BUG-139305
Summary Gestures containing the "BigSmile" built-in animation take way too long to load
Type Bug
Priority Unset
Status Accepted
Resolution Accepted
Reporter Marine Kelley (marine.kelley)
Created at 2017-10-27T10:00:36Z
Updated at 2018-04-20T14:46:02Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2017-10-27T11:15:44.627-0500',
  "Is there anything you'd like to add?": "I am flagging this bug as Major because...\r\n\r\n- It is very visible.\r\n- It is very confusing.\r\n- People chalk this as some issue due to lag, when it's not, it has nothing to do with the connection speed and quality.\r\n- It potentially disrupts discussions with inadvertent gestures coming at the wrong time. Nothing bad I don't think, but annoying anyway.\r\n- It is a recent bug. I have checked llgesturemgr.cpp but it hasn't changed in years, so I suspect some work around the cache instead.",
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': "Since v5.0.8 or v5.0.7, I can't really be sure, gestures containing an animation that animates Bento bones (fingers, face, tail, wings and/or hind legs) take forever to play, while other gestures, even those containing legacy animations (animations that don't move Bento bones) play right away. It doesn't matter if the animation has been played once not long ago, and therefore should be in the cache, the viewer downloads it again and takes a while to play the gesture.\r\n\r\nI am not clear whether it takes a while because it takes a long time to download (it shouldn't, most animations are usually really fast to load, faster than notecards), or because the viewer only checks the queue of gesture steps once in a while.",
  'What were you doing when it happened?': '- Make a Bento animation, for example a smile for a mesh head, or something that moves the wing, whatever.\r\n- Make a gesture that plays it, and maybe stops it after a moment if it is looped.\r\n- Save the gesture, play it through chat or preview it from the Gesture window.\r\n- Wait.\r\n- Wait some more...\r\n- After something like 2 minutes and a half, the gesture should finally play. But it is way too late if you intended to play the gesture in response to someone else saying something, you will play the gesture completely out of place.\r\n\r\n',
  'What were you expecting to happen instead?': 'The gesture should load and play immediately, especially if the animation is already in the cache.',
  'Where': 'http://maps.secondlife.com/secondlife/Shamazaar/20/113/25',
}
@sl-service-account
Copy link
Author

Marine Kelley commented at 2017-10-27T16:02:57Z

There is a new development !

I was with a friend, both on the latest RLV (which is based on the latest SL viewer, I must point out that the bug occurs on the official SL viewer as well), standing next to each other, with the same emote built from the repro above.

When she plays he emote, it works fine for her, and when she plays it in front of me, I hear the "/me smiles" coming from her avatar. I don't see her smile because she wears a mesh head.

However, when I play this emote, both she and I must wait for the "/me smiles" coming from my avatar.

I tested this with my alt earlier, before writing this ticket, but I didn't think of doing so with both avatars at the same place (I was working on something else elsewhere at the time).

It's like this bug happens only to me and to nobody else. Odd. So if you cannot repro it, don't sweat it too much unless other people experience the same issue, I can live without the "BigSmile" emote now, as I'm wearing a mesh head.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-10-27T16:15:45Z, updated at 2017-10-27T16:16:06Z

Not just you Marine ;) Reproduced on Second Life 5.0.8.329115 (Second Life Release)

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-10-27T16:21:13Z

Gestures play instantly (emote and animation) when using the other internal animations.
When using "Big Smile", it takes 3+ minutes to play the emote & the animation.

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-10-27T16:25:19Z

Reproduces on Firestorm too (Firestorm 5.0.9 (53408) Oct 22 2017 19:17:23 (Firestorm-FizzlefireAnimeshx64) with OpenSimulator support)

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-10-27T17:46:05Z

Results of further testing

  • Stripped down to the default female avatar & deactivated all other gestures & bug still reproduces.

  • Bug also reproduces for the "Open Mouth" animation.
    All the other default gesture animations do not reproduce the bug.

  • Bug cannot be reproduced by everyone!
    Dan, Kyle & Alexa can't reproduce it.
    I can reproduce it on my alt accounts too.
    Just to note Whirly & the alts I tested with & Marine are on different inventory servers, so this doesn't seem to be the cause of the problem.

  • Best clue yet - bug only reproduces on asset-http builds.
    Tested on Firestorm 5.0.7 & LL obsolete platforms 3.7.28.300847 (both pre-asset-http) & bug does not reproduce.
    Tested on the most recent LL viewer build before asset-http (http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-bear/rev/326444/arch/CYGWIN/installer/Second_Life_5_0_5_326444_i686_Setup.exe) and bug does not reproduce.

  • So this looks like it may be a problem with certain local CDNs & those 2 specific animations?

@sl-service-account
Copy link
Author

Whirly Fizzle commented at 2017-10-27T18:47:56Z

BigSmile is express_toothsmile - b92ec1a5-e7ce-a76b-2b05-bcdb9311417e - avatar_express_toothsmile.bvh
Open Mouth is express_open_mouth - d63bc1f9-fc81-9625-a0c6-007176d82eb7 - avatar_express_open_mouth.bvh

Ref: http://wiki.secondlife.com/wiki/Internal_Animations

Note that express_toothsmile used to cause the viewer to crash, see BUG-3794
So I wonder if the fix for that crash somehow causes this bug for certain people?

Also note the Firestorm crash JIRA issues at https://jira.phoenixviewer.com/browse/FIRE-14589 & https://jira.phoenixviewer.com/browse/FIRE-14972
Both these turned out to be the same crash caused by memory corruption after playing the express_toothsmile animation

Also note that there is no delay when playing express_toothsmile or express_open_mouth by script when using an asset-http viewer.
Example script - place in a box & touch box to play animation.

default
{
    touch_start(integer detected)
    {
        llRequestPermissions(llDetectedKey(0), PERMISSION_TRIGGER_ANIMATION);
    }
    run_time_permissions(integer perm)
    {
        if (perm & PERMISSION_TRIGGER_ANIMATION)
        {
            llStartAnimation("express_open_mouth");
            llOwnerSay("animation will end in 5 seconds");
            llSetTimerEvent(5.0);
        }
    }
    timer()
    {
        llSetTimerEvent(0.0);
        llStopAnimation("express_open_mouth");
    }
}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant