Quistess Alpha

default { on_rez(integer i) { llSetTimerEvent(600.0); // die after 600 seconds == 10 minutes } timer() { llDie(); } } To do that, the rezzing script would need to tell the rezzed object who requested it, which would require changes to the rezzing script. Alternatively, die if nobody is nearby: float distance = 9.0; // how far away before de-rez. (in linden-meters) default { on_rez(integer i) { llSensorRepeat("","",AGENT,distance,PI,20.0); // check every 20 seconds. } no_sensor() { llDie(); } }

*coughs* Yes, I'm glad I considered that such would be much better than using the animation without omega.

SL linking doesn't have any 'heirarchy', so when you link the red box+animesh to the plywood cube, the animesh becomes linked as a child of the plywood cube. The only solution I can think of would be to make an animation that moves the center joint, and apply that animation to the animesh.

Ignore me, I confused myself in testing by using scripts that had already been running and had triggered the timer before being rezzed, which resulted in confusing behavior.

Apparently, the attach event triggers before permissions are even accepted? anyway this seems to work as a toy example: integer gHandleListenRLV; integer gChanListenRLV = 1728; integer gTriesGetRLV = 0; default { on_rez(integer n) { if(!llGetAttached()) { llRequestPermissions(llGetOwner(),PERMISSION_ATTACH); } } run_time_permissions(integer perms) { if(perms&PERMISSION_ATTACH) { llAttachToAvatarTemp(ATTACH_HUD_CENTER_1); } } attach(key ID) { gTriesGetRLV = 3; gHandleListenRLV = llListen(gChanListenRLV,"",llGetOwner(),""); llSetTimerEvent(0.5); llOwnerSay("@camdistmax:10=n,getstatus="+(string)gChanListenRLV); } listen(integer Channel, string Name, key ID, string Text) { llOwnerSay("RLV activation confirmed: \n"+Text); llSetTimerEvent(0); } timer() { --gTriesGetRLV; if(gTriesGetRLV>0) { llOwnerSay("RLV not received, retrying"); llOwnerSay("@camdistmax:10=n,getstatus="+(string)gChanListenRLV); }else { llOwnerSay("RLV failed. No more retries."); llSetTimerEvent(0); } } }

camera params don't work if the camera is unlocked from the avatar, which, depending on how one uses the camera, could be most of the time.

I haven't but given that you're doing testing at the moment, I'll presume there is some issue there. The alternatives to tempAttach are regular llAttachToAvatar, and #RLV folder attaching. llAttach is a pain, because it doesn't handle ownership transfer, you have to get the recipient to buy the object (for 0L$) before it can attach, and #RLV folder attaching has all kinds of timing and communication issues that need to be handled delicately in the script. For being stubborn in a temp attachment, you could try @getstatus to confirm/deny the rlv was successfully applied, and retry if no/unexpected response received.

couldn't you just take the camera's rotation and left-multiply by a 90 degree turn on the z-axis? rotation point_y_to_camera = <0, 0, 0.70711, 0.70711>*camera_rotation;

-- irrelevant tangent -- Certain high-frequency events like touch() and control() jump-queue and replace their last instance such that there is only ever one event of the type in the queue (preventing it from overflowing too easily). consider default { touch_start(integer n) { llSleep(1.0); } touch(integer n) { llOwnerSay((string)llGetTime()); } } // touching this object for less than 1 second produces only 1 line of output. That's a bit of a semantic question, but I'd reserve the term 'blocking' only for scenarios where an event sleeps or loops for an unordinarily long time. It's the difference between closing your eyes and turning off your monitor. Maybe if you want to be pedantically more correct, you could say llListenControl "masks" the event?

single threaded, with a fifo queue that holds 64? events. Ergo, nothing can happen 'at the same time' in a single script.

which last time I checked was something like 100 megabytes. but there are LSL functions to check how much you have left in your own experience.

I'm too lazy to do tests, but editing a notecard should effectively simulate uncaching it if you read it by name? Put an unneccessary sleep in the read loop to give yourself time to do the edit while the loop is still running.

The HUD for Nanite system's main product does this; they call it 'laserline'. Anecdotally, I read they're not putting that feature into their total-overhaul of the system because it takes up too much script resources for a relatively unnecessary feature. Might be interesting to see if they reconsider given this new function.

The specifications of everything RLV can do (RLVa, which catznip and firestorm use can do some other things, but nothing super major, mostly minor blindfold differences, and payment restriction) is here: https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI Wireframe mode is not a supported action. Closest thing would be denying textures, which by default turns everything grey or replaces all (albedo/non-material, unclear how it will work with PBR) textures with one specified:

Multiply by a power of ten and then cast to an integer? ( llFloor(x) is basically the same as (integer)x ) float f = 123.456789; string round = llInsertString((string)llFloor(f*100),-3,"."); // off the top of my head. // for only 10ths: *10),-2 // will fail for numbers < .1 llOwnerSay("Debug, "+(string)f+" -> "+(string)round);

I'd argue that it is, but possibly in a way you hadn't considered. Just as you have trouble listening to voice, there are some people who have a hard time with reading (not speaking to any specific condition, but some people are just slow at it, others, could get headaches from reading). While text-to speech solutions exist, It's not hard to imagine such people would much rather just hang out in places where voice is the norm.

I'm sure you know, but might be important to add that a notecard's UUID changes every time it is modified; so 'remote reading' either requires some way to track the UUID for anyone who might want to read it (KVP would be a good intermediary) or accept that the data in the notecard can never be changed if it is 'hard-coded' in the script.

Oh really? how recent is that and has it reached non-rc channels?

ImmaBrat

Yes. Polling for a result is (marginally) more resource intensive, than an event trigger. llSensorRepeat is annoying kinds in the back of the car asking if we're there yet, llVolumeDetect is the parents just knowing when you get there and saying so. The physics simulator is always running in any case and probably already knows if something collided with your object whether the script asks to be informed about it or not. Now, in the very improbable edge-case in which lots and lots of non-avatars are colliding with your object all the time, and you only care about avatars, maybe llSensorRepeat() could hypothetically be better than constantly asking if the thing is an avatar and finding out that it isn't.

Check the box next to 'edit linked' and the radio button next to 'select face. Then, click the left or right arrows that are directly underneath the checkbox for 'edit linked' until only the part you want to modify has the highlight effect around it.

If I had to guess, perhaps there's some sort of naive show/hide system in the collar that (on some condition) turns everything in the linkset visible. The solution in that case would be to set the texture of the ball to the 100% transparent texture.

FWIW, In some cases, an inconspicuous face that's color is set to black, or just a prim that's small and inside something else non-transparent, can serve the same role as a face that's completely transparent.

If you could make it physical, you could use llPushObject() on it on land that doesn't have push disabled (I do not recommend doing so, but AFAIK it's the only method of affecting an object via script without the script being in that object) . I don't think you can make non-physical no-mod objects physical, but it's not impossible that llRezObjectWithParams allows setting that flag on no-mod objects (if it does, I'd consider that a bug to be honest.)

my assumption would be dragging from inventory onto a face to change the texture (which is very error-prone, I highly recommend doing it via the build window instead). And in that case, the problem is that changed(integer c){ if(c&CHANGED_TEXTURE){ /*...*/} } provides no information to the script about ~how the textures have changed. AFAIK, the only solution would have to be a rather involved script-copy of the information about all texture-parameters of the object in global variables or (much more conveniently) Linkset Data.