Ruthven Ravenhurst

here's a pair of scripts I worked up real quick. Keep in mind they don't take into account for coloring set on seperate faces for say, tattoos or makeup. I rezzed a cube, changed the color, and the name, shift drag, new color and name, etc. Link them together. Create new script. Shift drag link set. Copy 1st script into the script in one of the link sets. Copy 2nd script into the script in the other link set. click a cube in the set with the 1st script. The second link set should show only the cube that matches the one just clicked. Click another cube in the first set, the second set should change to match again. default{ state_entry() { //llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { integer link = llDetectedLinkNumber(0); string name = llGetLinkName(link); llSay(-500, name); }} list names;list links;list colors;integer len;default{ state_entry() { integer numprims = llGetNumberOfPrims(); integer i; for(i = 1;i <= numprims; i++) { list linkcolor = llGetLinkPrimitiveParams(i,[PRIM_COLOR,0]); vector color = llList2Vector(linkcolor,0); string name = llGetLinkName(i); names += name; links += i; colors += color; } len = llGetListLength(links); llListen(-500,"","",""); } listen(integer chan, string name, key id, string message) { if(llGetOwnerKey(id) == llGetOwner()) { integer idx = llListFindList(names, [message]); list params = [PRIM_LINK_TARGET,llList2Integer(links,idx),PRIM_COLOR,ALL_SIDES,llList2Vector(colors, idx),1.0]; integer i; for(i = 0; i < len;i++) { integer linknum = llList2Integer(links, i); if(i !=idx) { vector color = llList2Vector(colors,i); params += [PRIM_LINK_TARGET,linknum, PRIM_COLOR,ALL_SIDES,color,0.0]; } } llSetLinkPrimitiveParamsFast(LINK_SET,params); } }}

Right, I meant to add/imply that. I was still waking up at that moment lol.

I'm working on a sensor object that will target avatars with particles. I hope I can explain the logic I'm looking for. I'm trying to figure out the logic in how to achieve the results explained below. It will be a repeating sensor. Each time the sensor runs, it will get a list of the detected avatars and the unix time. (I intend for a short range, so I doubt cap of 16 detections would matter). I want to compare that to the list of previously detected avatars. If they're not in the previous list, target them and add them with their unix time. (got that part)If they are in the previous list, compare the unix time to when they were previously detected.If it's within a certain amount of time, do nothing.(got that part)If it is over that time, replace their unix time with the time now, and target them with particles.(got that part)If they're in the previous list, but not in the current one, remove them from the previous list.(this is the main part I'm having trouble with, and then in which order to do it all in)If no one is detected, empty the list. (easy enough)

I think I understand what you're asking. Currently, mesh heads and hands can't be animated in the way that the sl avatar can have different expressions and finger positions. They use seperate texture faces or links for each expression or hand position. The hud communicates which expression or finger position is chosen, and the head or hand will apply 100% alpha to the appropriate texture face/link, and 0% to the others. The mesh face won't move in the way that you see the SL avatar face move for each emoji, unless it is made to simulate it, wich would require several layers for each frame of the animation I haven't tested it, I think it's just an idea. llGetAnimationList returns a list of animation UUIDS that the avatar is playing. I suppose you could search that list for the uuids of the internal expressions, then communicate the appropriate expression for the mesh to change to, but I doubt that would work for animations that are uploaded and have those expressions applied.

one other thing I figured out when making a demo item. I used llAttachToAvatarTemp and wanted it to detach after a time. My vendor would rez the item, ask for permissions to attach, it attaches, then when I tried to detach after the demo period, I realized it transfers ownership, and so the permissions to attach/detach didn't carry over. "When object ownership changes, any granted permissions are reset. After a successful attach, you will need a fresh call to llRequestPermissions to allow llDetachFromAvatar and other permission-required functions to work."

it does, it just bypasses the dialog and is granted automatically. the same with how sitting on an object *automatically grants animation perms. *assuming the script requesting permissions is in the same object being sat on. Exceptions would be beds that rez poseballs, and things of that nature. You sit on the poseball, it communicates your identity to the bed, and then the bed has the animation scripts that ask permission. You're not sitting directly on the bed, so when it asks permission, it has to use the pop-up.

I think this is more of an animation problem. I assume you're using custom animations or an AO? The animation itself or a sit target (or maybe hover height?) would need to be raised up from the normal center point

I saw that, but hadn't tried it yet. I use firestorm viewer, and just found by accident that it has a built in particle generator that even creates a script with the parameters. I didn't see anything usefull with the blending, but I only played with it a few minutes

I can't seem to find any examples using the particle blending parameters. Do they work like the behavior flags, as far as stacking them, or is it more like the pattern flag and it uses one or the other? I'm working on a particle engine and wanted to include those into it

If I remember correctly, you must have transfer perms of a texture to assign it with llSetLink..... Why not hard code the uuid of the texture, and not put the the texture into the contents?

The only thing I mentioned rlv for is there is some sort of viewer to lsl communication, because firestorm tells the worn all bridge when the owner is touching/editing something in order to create the custom particle stream. So it made me curious if there is also some sort of mechanicism that would communicate the OwnerSay messages to the bridge

also here, the timer is triggering the move function. does the: else {pos.x += TARGET_INCREMENT... update the global variable, or does: pos = <pos.x, pos.y,pos.z>; need to be added after adding the TARGET_INCREMENT for the global variable? Move(){pos *= brake; // Update position, effectively decays away 'speed'if (pos.x < 0) { pos.x=0; } // Dont allow negative X valueselse { pos.x += TARGET_INCREMENT; } // Speed incrementvector world_target = pos * llGetRot(); // Rotate into world co-ordinate systemllMoveToTarget(llGetPos() + world_target, LINEAR_TAU); // Move the vehicle}

yep, I see it too if (auto){auto=FALSE;llWhisper(0,"Cruise off");llSetTimerEvent(0.0);}else{auto=TRUE;llWhisper(0,"Cruise on");llSetTimerEvent(0.5);}llSleep(0.5);} and also here in the changed event, it's changing it to FALSE when the avatar stands up. maybe it needs to be added to the event to change to true when the avatar sits? added it and bolded it in red. Also there's a llDetectedKey() in the changed event that shouldn't be there changed(integer change){if (change & CHANGED_LINK){llWhisper(0,"if1");key sitter = llAvatarOnSitTarget();if(sitter != NULL_KEY) { llRequestPermissions(sitter , PERMISSION_TRIGGER_ANIMATION); }else{if (id == Driver){llWhisper(0,"Thank You for flying!");gFLYING = 0;llSleep(1.5);llSetSitText("Pilot");llSetStatus(STATUS_PHYSICS, FALSE);llMessageLinked(LINK_ALL_CHILDREN, 0, "stop", gOwnerKey);llSetTimerEvent(0.0);llReleaseControls();llStopSound();llResetScript();llStopSound();}}}}

Right, as Vulpinus said, it is sent only to the owner, not open chat. Open chat being any channel that an object can hear, or channel 0 which also avatars can hear. An exception to that is using RLV, which when active, will intercept any Ownersay messages starting with the @ symbol. Those messages won't appear in the chat, while the other ownersay messages will. I don't know how it works, but I don't think the LSL bridge that it uses hears the ownersay messages either

It stands for restrained life/love? viewer. It is used a lot for slave and master role playing wit Open Collar, but has many other benefits as described above, auto-sitting on an item, using a HUD or other scripted objects to make you change clothes, or add/remove items. Also for teleporting around. http://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI

you could also try using llParseString2List. I don't know a lot about html, so I don't know if it would be consistent enough to always use the same index, but it's worth a try: list bodylist = llParseString2List(body, ["<",">"],[]); integer listlength = llGetListLength(bodylist); llOwnerSay(llList2String(bodylist, listlength-8));

And then there's also RLV. I only recently started using it. I like using it when I'm rezzing something from a hud to have my avatar automatically sit on it if that is the intended purpose. You can also use it to make the avatar wear/add items, including clothing layers, skins, etc, or even entire folders

is the land set to not allow non-group scripts? that's the only thing I can think of that would make that not work

Oh I see, you can set the object's group in the edit window. also if the land group is required for building, you can set a child prim to a different group, but make sure the root prim is set to the land group

I'm not sure what you mean by same sim. The avatar needs to touch it to receive the item. Are you trying to send an item to an entire group? That would need to be done through the group profile, assuming you have priveliges to send notices

I love this function. I used it in a particle script to target the objects attached to various points of an avatar instead of their center. It's certainly possible for an avatar not to wear any attachments, but I'd say it's pretty rare these days. Even the starter avatars have hair and other attachments already.

but then, assuming the currency is set to transfer, there's the possability of using alts to collect, then transfer to the main avatar

wherorangi wrote: OP wrote it as a touch to try work out what was happening Yes, I realize that, but they also said they wouldn't know where to begin looking for an advanced script. Simply cycling back and forth through the faces/prims is one thing, but adding the logic to pause between blicking is slightly different. Not hard to do, but slightly different. My main observation was that the script was changing the alpha state on the same prim, but the picture appears to me multiple prims, which is why I suggested making a list of the prims being cycled through "I wouldn't know even where to begin looking for an advanced script with blinking + HUD attatchments for face states, I tried looking but it looks like I'd need to commission an actual scripter to do it for me. So for now I opted for a simple click script, merely to test things out..."

This looks very similar to the script for a flying mesh butterfly I got. It is a single prim, with multiple faces, and it cycles through the faces making it appear to fly. But yours appears to be multiple prims (maybe not?), so you would need to create a list of the links you intend to cycle through and use that in place of LINK_THIS. Next question, do you want it to blink on touch/command, or constantly? If constantly you'd probably also want to add a delay between each blink cycle so that it looks more natural.

sorry to bother with multiple replies lol, one idea I thought of is to put an on_rez event, and use something like on_rez(integer n){list dets = llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]);if(llGetOwner() == llList2Key(dets, 0)){llOwnerSay("Rezzed by the owner");}else{llOwnerSay("Rezzed by script");llDie();}}