Quistess Alpha

Yeah, your logic isn't really making any sense. Since everything is happening in state_entry's, if your conditional doesn't happen, the execution will reach the end of the event and nothing will ever happen again. You need to either poll for the change you're expecting in a timer() event, or hope that the changed() event has a suitable condition. ETA: changed event doesn't fire on sitting, so: integer wasSitting; default { state_entry() { llSetTimerEvent(1.0); } timer() { integer isSitting = llGetAgentInfo(llGetOwner())&AGENT_SITTING; if(isSitting!=wasSitting) { if(isSitting) { // turn invisible. float alpha = 1.0; do { llSetAlpha(alpha-=0.1,ALL_SIDES); llSleep(0.1); }while(alpha>=0); }else { // turn visible float alpha = 0.0; do { llSetAlpha(alpha+=0.1,ALL_SIDES); llSleep(0.1); }while(alpha<=1.0); } wasSitting = isSitting; } } } there's probably a more elegant way to do the alpha loop, but this works.

if it's just for personal use, you might try experimenting with some of the animations from oracul's bento enhanced head (you can copy the animations out of the HUD) otherwise the "real" answer would be to read up on the api for every major head brand to see what they expect to ask them to play a smile animation. or craft several open mouth animations tailored to each target head of interest separately.

"express_open_mouth" is a system-head only animation. system head emotes don't work on mesh heads and mesh head anims don't work on the system head (IIRC). given that the OP must be using a system head for this to work at all, it's relatively safe to assume animation conflict isn't an issue. (as system heads don't have complicated animation scripts in them that could interfere)

Bumpety up bump.

Unfortunately, for a linked sliding door you can't get truly smooth movement. but you can move a thing in small increments until it's where you want it to be. // linked sliding door script. // Quistess Alpha 2022. vector gDelta = <1.0, 0, 0>; // x,y,z distance to move with respect to the prim // (edit linked, snap-local and check the directions of the red(x) green(y) and blue(z) arrows) integer gSteps = 28; // how many steps does it take to get from closed to open? float gTimeMove = 7.0; // how many seconds does it take to get from closed to open? float gTimeStayOpen = 15.0; // how long to stay open, 0 for indefinitely. string OpenSound = "cb340647-9680-dd5e-49c0-86edfa01b3ac"; string CloseSound = "cb340647-9680-dd5e-49c0-86edfa01b3ac"; // script managed variables: integer isOpen = FALSE; open_door(integer open) // let open = 1 to open, 0 to close. { if(isOpen!=open) { isOpen=open; }else { llOwnerSay("Warning: attemting to set door state to current state."); return; //do not open the door if it is already open, do not close if already closed. } if(open) { if(OpenSound) llPlaySound(OpenSound,1.0); llSetTimerEvent(gTimeStayOpen); }else { if(CloseSound) llPlaySound(CloseSound,1.0); llSetTimerEvent(0.0); } open = (2*open) -1; // if open is 0, set it to -1. vector pos = llGetLocalPos(); rotation rot = llGetLocalRot(); vector delta = (gDelta*rot)*open; integer loop=1; for(;loop<=gSteps;++loop) { llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_POS_LOCAL,pos+(delta*loop)]); llSleep(gTimeMove); //llOwnerSay("tick"); } } default { state_entry() { // convert global variables to more useful formats. gDelta = gDelta/gSteps; if(gTimeStayOpen) gTimeStayOpen+=gTimeMove; gTimeMove = gTimeMove/gSteps; } touch_start(integer total_number) { open_door(!isOpen); } timer() { open_door(0); // close door. (also sets timer to 0). } } Or so should work as a basic example, making a version that lets you shut it mid-opening or open mid-closing would be a tad more complicated.

Alternatively, perhaps purple lemmings eat KIWIS

Forget ontology; Cultivate universal spiritual POWER! P.S. I need to stop watching donghua and go to bed. . .

Someone else probably said it first but didn't governance meetings get cancelled some months ago?

unfortunately, not everything is for sale. some things are 'unique' no-copy one-of-a-kind specialties, and some things are limited-time-only sales etc. If you read up on how the permissions system works, you'll soon see why you can't buy most things. https://wiki.secondlife.com/wiki/Permission

The overview answer is that you either A) create an animation that translates bones, and then play it (either from inventory or via script) and assuming no other animation translates the bones, they will remain deformed until an animation reset or relog. You'd have to use a tool like Avastar or my (beta stage) animation format converter to create such an animation. B) create a rigged mesh with bone translation enabled. This is more 'robust' against resetting skeleton and animations, and IMO a bit less janky to random fluctuation/difference between observers, but it's a bit more work to create, and not as convenient to use (only one specific deformation per attachment). An attachment of this kind can be created in blender without any special plugin (see the free shoulder deformer available from my store as an example) , although I presume Avastar would make the process a good deal easier.

As far as I know, there's no way to do it directly, but assuming your thing is a flat plane, and the colliding things are very roughly spherical: // asume this object has 0.01 z-dimension (height) collision_start(integer n) { rotation rSelf = llGetRot(); vector posSelf = llGetPos(); while(~--n) { key kDet = llDetectedKey(n); vector posDet = llDetectedPos(n); posDet = (posDet-posSelf)/rSelf; // if we only expect collisions on one side, this conditional can be eliminated: if(posDet.z>0) posDet.z = 0.005; else posDet.z = -0.005; posDet = (posDet*rSelf)+posSelf; // at this point posDet is where we expect the collision occured. (in region coordinates) } } or so might work? (untested)

You have to design the texture to work with llSetTextureAnim, not visa versa; it's rather limited in what it can do outside of its intended scope.

Peeve: the internet is slowly hard-locking content and functionality behind owning a mobile phone. Paypal locks you out after a month or two if you don't have one, and common email providers are following suit. you can't make an email account with most providers now without one, and there's no telling when one will decide to suddenly lock you out.

and it points at a specific object. . . I'm straining a bit to imagine what it might be, but an alternative could be to use object SLURLs to make it easier for users to place map beacons. E.g: [secondlife:///app/objectim/190f571d-fdf1-8f6c-4e9d-973e9b5e0566?name=ObjectName&owner=c93c3129-2250-4c79-a5f7-8c755ca2707e&groupowned=true&slurl=Location/128/128/27 ObjectName]

I suggested a follower because @Jenna Huntsman followed up by clarifying she's trying to get an object that's at an avatar's position to track something other than that avatar. If you have a follower (rezzed object which moves to the avatar's location) pointing at another object (ex. a treasure compass pointing at a piece of gold) neither actually need to know what that avatar's rotation is, circumventing the problem. ETA: I was assuming the follower is directly above the avatar and not offset in front or to the side.

In that case, couldn't you implement the attachment as a 'follower' instead?

The main problem is that exact avatar rotation isn't accurately synced across the 'shared experience'. Just like no two people see a particle in exactly the same place at the same time, or exactly which frame of an animation someone is on, which way an avatar is looking is subject to a certain error threshold (about 10~20 degrees) across different observers. In order to 'put something into an avatar's local coordinates' You need to attach it to their avatar_root (or center, exact attach point name differs between viewers) or sit the avatar on something which does respect shared experience shared orientation.

You need to be careful about some nasty gachas with object inventory renaming: If you add 5 copies of "soup" to your box, no problem, they get renamed : "soup" "soup 1" "soup 2" etc. but if by some contrived circumstance, you add "soup 2" to a box that already has a "soup 2" in it, you get a "soup 2 1". Roughly: list name_simple; list name_real; string name_simple_last; integer i = llGetInventoryNumber(INVENTORY_OBJECT); while(~--i) { string name = llGetInventoryName(INVENTORY_OBJECT,i); list parsed = llParseString2List(name,[" "],[]); while((integer)llList2String(parsed,-1)) { parsed = llDeleteSubList(parsed,-1,-1); } string name_simple_check = llDumpList2String(parsed," "); if(name_simple_check!=name_simple_last) { name_real+=name; name_simple+=name_simple_check; } } You'll also have to keep track of both the "pretty" name of the thing ("soup") as well as the specific number (series) of the copy you intend to sell next.

I suppose it would if the detach procedure doesn't fire before it's actually detached. A more foolproof method is indeed to just add to an accumulator on a timer: string gRegionName = "My awesome RP sim!"; integer gTimeSpent; default { state_entry() { llSetTimerEvent(60.0); } timer() { ++gTimeSpent; // gTimeSpent = gTimeSpent+1; } touch_start(integer n) { llSay(0,"HUD has been attached for: "+ (string)(gTimeSpent)+ " minutes."); } // basically the same from this point: attach(key ID) { if(ID) // was attached. { if(llGetRegionName()!=gRegionName) { llRequestPermissions(ID,PERMISSION_ATTACH); } } } changed(integer c) { if(c&CHANGED_REGION) { llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer perms) { if(perms&PERMISSION_ATTACH) { llDetachFromAvatar(); } } }

Indeed, that would be a problem. Practically speaking, that could be mitigated by the rezzer sleeping for a bit after rezzing something, but that's not 100% error-proof either.

I know this is an old thread, but I happened to think about the 'problem' of rezzing an attachment and communicating to it who it's supposed to attach to again today, and as happens when you revisit old problems, I think I thought up an even more elegant solution: simply set the description (or invisible hover text) of the rezzer to the key of the avatar to attach to: //rezzed attachment: on_rez(integer i) { key rezzer = llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]),0); key attach_to = (key)llList2String(llGetObjectDetails(rezzer,[OBJECT_DESC]),0); // alternatively OBJECT_TEXT, depending on the rezzer setup. llRequestExperiencePermissions(attach_to,[]); } // ...

Yup, I just tested it, the only issue I can see is that if it is detached before it is attached (i.e. you put the script in while it is attached to you, or edit it while it's on you) then the attach time never gets set to something reasonable. You'll want to set gTimeAttached to the current unix time in state_entry, and set the total time spent back to 0 when the owner changes.

Roughly: string gRegionName = "My awesome RP sim!"; integer gTimeSpent; integer gTimeAttached; default { touch_start(integer n) { llSay(0,"HUD has been attached for: "+ (string)(gTimeSpent+llGetUnixTime()-gTimeAttached)+ " seconds."); } attach(key ID) { if(ID) // was attached. { if(llGetRegionName()!=gRegionName) { llRequestPermissions(ID,PERMISSION_ATTACH); } // set attached time in any case, to simplify detach logic. gTimeAttached = llGetUnixTime(); }else // was detached. { gTimeSpent+= llGetUnixTime()-gTimeAttached; } } changed(integer c) { if(c&CHANGED_REGION) { llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer perms) { if(perms&PERMISSION_ATTACH) { llDetachFromAvatar(); } } } (untested, may have bugs and syntax errors) It's probably possible to do it without forcing the HUD to detach when not on the region, but this seems like the most straight-forward method. Actually using that time value in some sort of meaningful way is where it gets complicated.

bump

an important caveat is that you can detach the HUD when the object is detached with that method, but not visa-versa: HUDs don't show up in the attach list