Quistess Alpha

I'm not old enough to remember "grey goo", but it's certainly possible if you're clever enough. Check out llRemoteLoadScriptPin(). it's a bit of a pain, but it mostly solves the matryoshka doll problem.

llSetLinkTexture(link_number,"texture's UUID (in quotes)",face_number); // only one of the following 2 lines is really neccessary: llSetClickAction(CLICK_ACTION_DISABLED); // or: llSetScriptState(llGetScriptName(),FALSE); somewhere in the money event right after a line that has llGiveInvenyory...

In that case, sounds like a fairly standard custom vendor script. If you already have a the code for a vendor script that already does most of what you want, I think some nice people might offer to add simple additions for free. From scratch on the other hand. . . Talking about exact prices is sticky territory, but I can't imagine it would take more than an hour or two of someone competent's time.

Making a script react/interact with the marketplace is very hard if not impossible. I'd be a bit wary of anyone who says they can (ask about other web-interaction projects they've done, chat with their references/actually look at said project). (MP-> inworld direction is much easier than inworld-> MP) Just texture-change after some trigger is very easy.

The hard part that you might have glossed over is that she wants the in-world item to respond to a transaction happening on the marketplace. Off the top of my head, I think the most practical way to get that to happen would be to forward marketplace emails to an in-world 'controller' object that could then send a message to the specific painting that had been sold. That could get mildly complicated, (and would differ a bit depending on whether a personal email forwards only relevant messages, or if the in-world script is set to receive all marketplace messages) but certainly not impossible. The problem is making the marketplace take down a listing that has been bought in-world. I think it might be possible to have a 'bot' agent delete an item from their marketplace folder, thereby removing the listing, but if that doesn't work, making the script interact with the MP in any way would be very difficult if not impossible.

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.