Playing Animations via UUIDs

[Aasha Kohime]

In a nutshell I want to give a demo item out that only works while in a certain sim.

I'm concerned people would merely take the animations from the contents of the freebie however. 

Can I use UUIDs so the item animates without putting animations into the contents?

[Rolig Loon]

No.  To run an animation, you need to use the LSL function llStartAnimation, which requires the name of a animation in the contents of the scripted object.  You can make the animation no-copy/no-trans, however.  That way, the object's owner will not be able to make a second copy and will not be able to transfer that one to anyione else.

[Aasha Kohime]

Whenever I uncheck one of those boxes the other grays out with a check added. I assumed this was the case for everyone for a while now.

Besides they could still take the contents into their inventory and then dump the contents from there into a new item. 

Thanks for replying though. I'll just think of something else.

[irihapeti]

as I remember Copy to Inventory menu command can/will only copy from the root prim

so have 2 prims. Put the animations and the animation script in the child prim. Set the animations and script in the child prim to NoMod/Copy/NoTrans. Set the root prim to NoMod/NoCopy/Trans

+

also look at scripting the object to delete the contents of the child prim when the object changes region

http://wiki.secondlife.com/wiki/CHANGED_REGION

 

 

[Qie Niangao]

AFAIK, a single asset can be either no-copy or no-transfer, but not both, and the combined no-copy / no-transfer permission is obtained for objects that contain assets with a combination of permissions.

Also, it's still easy to pull assets from the contents of child prims, just by editing the linked prims and dragging the assets from the Contents tab to Inventory. (In theory, one shouldn't really be able to pull no-copy assets from a no-mod object, but I think that works, too, or at least has done so at some point.)

So, for a demo, I'd suggest just using another scripted object as an animation engine, and talk to it from whatever object is being demo'd. Somehow that animation engine must obtain PERMISSION_TRIGGER_ANIMATIONS, so either that must be asked explicitly by the anim engine script or obtained because the demo user is sitting on the anim engine object or has granted permissions to an Experience with which the anim engine script is associated.

[irihapeti]

i remembered wrong. You are right. I just tested it. Can still rip the contents out of a no-mod child prim

[Rolig Loon]

---

Aasha Kohime wrote:

Whenever I uncheck one of those boxes the other grays out with a check added. I assumed this was the case for everyone for a while now.

Besides they could still take the contents into their inventory and then dump the contents from there into a new item. 

Thanks for replying though. I'll just think of something else.

---

Yes, they could always move the animation to another item.  However, (1) they'd need to have a script to trigger the animation in the new item, (2) they'd leave the original item with no script in it, and (3) they'd be unable to give the animation to anyone else.  You wouldn't be losing anything by letting the owner take his own copy of your animation out of the object if he wants to.

[Aasha Kohime]

I've suceeded in making scripts people can't use outside of our sim, but some people have tossed the scripts and are just using the animations with new scripts that perform the same functions.

 

I read somewhere that LL made it this way to make animations harder to steal. I just want to point out this is a horrible setup for SL. Imagine how hard it would be to steal a texture if it were required to be put in the contents of an object. A lot easier, right? Exactly.

[Aasha Kohime]

I added this issue to Jira in case anyone wants to help me change this issue.

https://jira.secondlife.com/browse/BUG-8162 I'd appreciate any upvotes and comments.

[irihapeti]

the general solution for your usecase is what Qie said. Temp attach the HUD when the person enters the sim/parcel

http://wiki.secondlife.com/wiki/LlAttachToAvatarTemp

 

 

[Aasha Kohime]

Okay I tried that. It works well for what it does. But I have one thing that's annoying the bazeesus out of me.

Everytime someone clicks the rezzer and makes the object appear I myself get messaged about permissions to attach it. in 5 minutes I'd probably had over 60 messages. This is not a perfect system. It is incredibly annoying. D:

[irihapeti]

sounds like the HUD script is asking llGetOwner for permissions instead of who ever touched the rezzer. Maybe something like:

 

touch_start(integer num_detected){    key id = llDetectedKey(0);
    rezMyHUD(id);}

...

rezMyHUD(key id)
{
   .. set up a channel to listen on
   .. rez the HUD passing the channel number in the llRezObject integer param   
   .. listen on the channel
   .. when HUD sends IAmAlive message on the channel
   ..      then pass avatar id to the HUD on the channel

   .. .. HUD script now has avatar id to request permissions of .. ..

}

 

eta. I just add on here for anyone reading maybe one day in the future. bc of the script example I post below which might cause confusion between this and them

ok

this script goes in the rezzer. The alternative below is the approach when using 2 scripts in the actual HUD and is assumed that the HUD is already rezzed in world (like not in a rezzer)

the main reason for using the rezzer to capture the avatar id and passing it to the HUD script is:

when do this way then the person receiving the HUD to wear only has to touch once (the rezzer) 

[Innula Zenovka]

In general, there's a gotcha with temp attachments like this.

When the object is rezzed, it still belongs to you.   So, when someone touches the rezzer to ask for a demo object, you need to grab their UUID and pass it to the rezzed object.

When they grant PERMISSION_ATTACH to the object and it attaches to them, they become the owner and the script loses all its permissions, so you need to ask them for PERMISSION_TRIGGER_ANIMATION  in the attach event.

If you want a more detailed account, you can see me struggling with this in the talk section of the wiki article on llAtttachToAvatarTemp and Dari Caldwell and Rolig explaining it to me.

[Aasha Kohime]

I'll give that a try if I get a chance. In a sudden topic change I have an abundance of people ripping it off now because of the demos I had put out before (the whole not being able to use UUIDs for animations thing). While I want to try the Account-UUIDs at the moment I'm highly concerned about that. I need to have the animations I made for it removed from the grid to start over. But I've never done this before. How do I do this? Who do I talk to?

[Rolig Loon]

You can't, really.  Once an asset's description is in the asset servers, it's there for all time.  AFAIK, there's no provision for removing one, except in the case of a DMCA complaint.

BTW, the system that Innula described does essentially what the script I gave you does.  The only difference is that the rezzer Innula described grabs the person's UUID before it rezzes the item instead of grabbing it when the person clicks on a rezzed item.  In both cases, it only needs the UUID to know who to request permissions for. 

[Aasha Kohime]

I'm willing to go the lengths of DMCA filing after having worked on these animations for months but honestly I'm trying for a gentler and easier way first.

Hopeful for simplicity.

[Aasha Kohime]

At the moment this is the script I use.

---

integer gRegCh;

key gAv;

default

{

touch_start(integer num)

{

if (!llGetAttached()) llRequestPermissions( llDetectedKey(0), PERMISSION_ATTACH);

}

attach(key id)

{

gAv = id;

}

changed (integer change)

{

if (change & CHANGED_REGION)

{

llDetachFromAvatar();

}

}

run_time_permissions (integer perm)

{

if (!llGetAttached() && (perm & PERMISSION_ATTACH)) llAttachToAvatarTemp(ATTACH_MOUTH);

if ((perm & PERMISSION_ATTACH) && (gRegCh)) llDetachFromAvatar();

}

}

---

When it gets rezzed from the box - no matter if I rez it or they rez it - I get the blue box pop-up asking for permission to animate my avatar.

They click the sword and attach it to themselves all well and good. That part works fine.

The animations of the sword (which are in a different script that I don't want to publicly display) won't play for them. But if I happen to wear the sword and use it everyone around me will perform the animations and sounds with me. Is there any way you can tell me what I need to do from this without needing the other script?

[irihapeti]

i just guess at whats happening ok

1) you have the script you posted in the HUD. Is this script that request permission to ATTACH
2) you  have another script in the HUD which controls the animations. Is this script that should request permission to animate 

examples to show how this program logic flows:

 

// ".attach" scriptkey id;default{       touch_start(integer total_number)    {        id = llDetectedKey(0);        llRequestPermissions(id, PERMISSION_ATTACH);            }        run_time_permissions(integer perm)    {        if (perm & PERMISSION_ATTACH)        {            llWhisper(0, "owner is: " + llKey2Name(llGetOwner()));            llWhisper(0, "person requesting is: " + llKey2Name(id));            llSleep(0.5); // wait some small time for chat to show                                  llAttachToAvatarTemp(ATTACH_MOUTH);

	    llResetOtherScript(".anim");          }    }}

 

// .anim scriptkey id;default{    state_entry()    {        id = llGetOwner();        llWhisper(0, "owner is: " + llKey2Name(id));        llSleep(0.5); // wait some small time for chat        llRequestPermissions(id, PERMISSION_TRIGGER_ANIMATION);    }    run_time_permissions(integer perm)    {        if (perm & PERMISSION_TRIGGER_ANIMATION)        {            llWhisper(0, "perms granted by: " + llKey2Name(id));            }    }}

 

 eta: ttypo

[Callum Meriman]

Reading the reason behind this - myself, I would do it like a danceball rather than the methoods you think of in this post and the other.

You have a central server that will play the animation in it's contents, one script per person in the sim using your sword.

You have the sword that talks to this server and requests the animation on demand.

Have the sword use llRegionSayTo messages on a negative channel to (1) tell the server that a person attaches a sword - ping them for permission, assign them to a script. (2) play an animation (3) respond to a heartbeat so you know if a person leaves with the sword attached and free the server script (4) detect a detach and free the server script.

I can't see this script being too hard for a competant programmer, most of the work is just in the housekeeping so that your scripts free up when people crash/leave whatever.

 

Be aware on your sword..... To pirate it even with a llDie() detach, go to a private SIM with scripts turned off... rez the sword and remove the kill script.

[irihapeti]

PERMISSION_TAKE_CONTROLS will keep the script running 

[Aasha Kohime]

PERMISSION_TAKE_CONTROLS may or may not work in this situation. The player doesn't have direct control of the weapon functions. It isn't free-range combat so much as a combat mini-game where the players are technically sat down and inputting various commands and movements on the hud to perform different actions and move around the board. Worth a try though since nothing worked perfectly yet.

[Aasha Kohime]

The danceball idea is sort of something one of my partners is working on actually.

I'm well aware how easy it is to rip even a sword scripted to die. It's part of the reason I start such a fuss about content not being safe.

[irihapeti]

if for demo purposes the player is sitting on your inworld object on your sim then is unclear to me why the anims need to be in the demo HUD

in this case would seem to me that the anims and the anim script be better in the object being sat on. Communicating with the gameplay HUD scripts on a channel 

+

ps eta:

having the players sitting on objects so that they are pieces on a gameboard is a really good idea. I like it

[Aasha Kohime]

I didn't make the base game. I made a custom weapon for it. This way everyone has their own weapon and fighting style. The weapons hold the animation and sound information though.

[irihapeti]

yes ok

can see now what the issues are