LLGiveInventory not giving animations to worn HUD

[Monica Balut]

I had built installer system last spring where a rezzed installer would give animations from its inventory to a HUD worn by the owner of the installer.  The relevant code in the installer looked like this:

 

               if (nAnimations > 0)
                        {
                            for (i=0; i<nAnimations; i++)
                            {
                                animName = llGetInventoryName(INVENTORY_ANIMATION,i);
                                llGiveInventory(HUDid,animName);
                            }
                        }

(nAnimations and HUDid are obviously defined elsewhere)

 

It all worked fine.  Simialr code later gives notecards to the HUD.

 

All of a sudden in the last couple weeks.  The code stopped working.  I get script error messages saying the HUD has refused the animations.  The notecards are still being transferred ok though.

 

If I rez the HUD on the ground, it all works fine again and animations get transferred.

 

So something has obviously changed, most likely in server code since this happens no matter what viewer I'm using.

 

So before I post a JIRA on this, I'd like to ask if anyone has ever used similar code to have a rezzed object give animations to a worn HUD.  This was the first time I had used llGiveInventory in this manner and wonder if there was just a loophole in the function during the time I happen to be developing this that allowed it to work for a time.

 

There is no mention of not being able to transfer animations in this way in the WIKI nor mention of any problems in the JIRA.  I know you could never just manually load animmations to a worn HUD and was happy to see I could do it via llGiveInventory.  Now it has all blown up.

[Rufus Darkfold]

Known showstopper bug.   They're working on it.   Workaround is to put the attachment on the ground before updating it.

[Monica Balut]

Do you have a JIRA reference?

When was this introduced?

[Void Singer]

https://jira.secondlife.com/browse/SVC-7283

it was introduced as part of an urgent security fix to permissions in the last roll set of server rolls (propagated to all channels)

[Monica Balut]

Thanks for the info folks.  I've sent out notices to warn my customers.  At least I know it's not me.