Quistess Alpha

Actually, yes, but if the script is in the detached object, it may or may not have enough time to do whatever useful thing you want it to do. from inside the attachment: default { attach(key ID) { if(ID) { llSay(0,"This object was just attached."); }else { llSay(0,"This object was just detached."); // anything more placed here may or may not happen the next time this object is attached, before any other events. } } } for anything more complicated than saying a message, you should expect that some of the code may run during the next attach. see https://wiki.secondlife.com/wiki/Attach From another object, you'd need to iterate through llGetAttachedList() on a timer.

I glanced at the site, but didn't see anything about an open API. If ZCS doesn't provide a clear and open way to interface with their scripts, then it is not possible to read their health-bar to do other stuff with. RLV stripping requires specific setup on the part of the person being stripped. Depending on the script implementation, they'd need to be very careful about attach points, or place their stripables into specific RLV folders (as the 'literal' object, not links).

https://jira.secondlife.com/secure/Dashboard.jspa for the official SL viewer, look in the help menu (top bar) of your viewer of choice, firestorm for example: https://jira.firestormviewer.org/secure/Dashboard.jspa

Do temp attachments usually show up in llGetAttachedList()? If so, might be interesting to check if temp attachments that are "stuck" show up. If they don't (which is what I expect) it's probably a viewer bug. If it's a viewer bug, maybe some TPV (e.g. firestorm) could implement a 'check that all my temp attachments are valid' function to manually clear the stuck attachments.

Assuming 'this' is to have a HUD 'locked on' but not disable wireframe mode. . . no. Just for a list of things that do lock on but also disable wireframe mode availability: list cmd = [ "@clear","@clear,detach=n","@clear,detachthis=n","@clear,@detachthis:testing=n","@clear,sharedunwear=n" ]; list desc = [ "unlocked","locked","self-folder locked","direct folder locked","shared folder locked" ]; integer ind; default { touch_start(integer total_number) { ind = (++ind)%5; llOwnerSay(llList2String(cmd,ind)); llOwnerSay(llList2String(desc,ind)); } }

"senra" returns 88 results. Most of it is shapes/BOM and other low-effort or repurposed material. I did see a catsuit and some underwear for Jamie. Things which fit closely to the skin with minimal additional detail are the easiest to produce or re-fit quickly.

Even if you made some ~very aggressive assumptions about how quickly creators in SL could churn out new clothes for the body, there's really no way any creator who wasn't secretly in on it before the official release can have more than one or two fitted mesh clothing articles. Maybe in a few months at best there will exist enough product for some event to try and collect it in one place.

I'd call that an 'underbust' but it's still a bit hard to pick from the weeds and duplicates. https://marketplace.secondlife.com/p/BBD-IRMINA-Mesh-Latex-Underbust-Corset-BLUSH-PINK-Maitreya-Petite-Legacy-Perky-Slink-Belleza-Kupra-eBody-Reborn/23722627 https://marketplace.secondlife.com/p/insanya-Underbust-Corset-Black/8479866 https://marketplace.secondlife.com/p/ValkyrianBrutal-Velvet-Domina-Shelf-Corset-ADD/25103803

I'd recommend adding a "boolean operator" "NOT demo" to the search, as there are countless demos which are not marked as such (even though that's against the MP's listing guidelines and is a reportable offense: click the red flag then select "disallowed listing practices" and "demo not linked to full version" ) MP Freebies all but 2 of the first dozen or so in your search were demos

operators and flow control are also (IMO) essential reading. Even if you think you know it, it never hurts to refresh on basics, and LSL has some subtle differences from analogous things in other languages.

Leveraging built-in functions for "true" randomization (e.g. probably deterministic, but the determinism is handled by SL somewhere in the background) the main options are to use llFrand(), llListRandomize() or llGenerateKey() and convert the key to an integer (which you can do by prepending "0x" to the key before the cast : (integer)("0x"+key); ). If you want to implement something yourself, https://en.wikipedia.org/wiki/List_of_random_number_generators might be a good starting point. I wouldn't reccomend using one of those methods in a "practical" application, but it might be a good educational exercise. llRegionSayTo() is sufficient for pretty much all cases, slightly more secure if you "authenticate" based on the creator of the object. a gratuitously secure application might leverage the xtea implementation I posted in the lsl library (object 1 sends an encoded key to object 2 using a secret shared between object 1&2, then object 2 sends back the decoded key. if the decoded key matches the one object 1 encoded, then object 1 can trust object 2 ), or use a private server to broker a http connection between the two objects. Just using a secret large channel, or generate a channel based on an unguessable algorithm (for example: (integer)("0x"+llGetKey())^sharedSecret ) is enough security for most applications though. LinksetData functions and global variables. If you're not already familiar with lsl's data types: https://wiki.secondlife.com/wiki/Category:LSL_Types llSay functions: llSay llRegionSay(to) llShout() rarely llEmail() (fun fact, every single prim (and mesh) rezzed in SL has its own email address!) or llHTTPRequest() (Somewhat counterintuitively, a request can be used to ~send information, not gust get it back from the requestee ) This gets interesting, as it often involves the design of the object just as much if not more than how it's scripted. Most of the ways to get information out of an object involve changing the visual appearance of the object in some way, and most of the visual change functionality can be done with a rather bloated function llSetLinkPrimitiveParamsFast() which will let you change the color/texture/physical appearance of an object in numerous ways. llSetText() also a notable way of displaying short and simple text on an object. Other options include using llSay/Shout/Whisper on channel 0, which makes an object "talk" in public chat, or llDialog() which brings up a pop-up box for a specific person. You can also use 'media on a prim' functions to display a simple webpage hosted by a LSL script onto a face of an object.

llGetHTTPHeader is an interesting contrast: its "detected" information can be accessed in other events, even though it's really only relevant in the http_request event.

Officially, no. SL is more or less a "buyer beware" market. I'd talk to the owner of the land where the photographer took the picture, and where you met. If you can get them on your side, the photographer might be more cooperative with the threat of being banned from a good photo/client-gathering spot backing you up. The forums, are unfortunately, not a place to publicly warn against a specific person/group.

Surprisingly, it seems like LSL might be able to handle the API for that. https://developers.google.com/youtube/v3/live/docs/liveChatMessages The message you need to send to google to make a message appear seems a lot more convoluted than discord's api, but at first glance it looks like LSL should theoretically be able to handle it. google lets you build an example using curl, for reference that looks something like: curl --request POST \ 'https://youtube.googleapis.com/youtube/v3/liveChat/messages?part=snippet&key=[YOUR_API_KEY]' \ --header 'Authorization: Bearer [YOUR_ACCESS_TOKEN]' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"snippet":{"liveChatId":"<your livechat ID>","type":"textMessageEvent","textMessageDetails":{"messageText":"<The text inside the message>"}}}' \ --compressed If you can get that to work as a proof of concept, it shouldn't be too hard to translate it into a llHTTPRequest from LSL.

If you use the linkset_data() event as a direct substitute for link messages, probably imperceptibly worse. However, the advantage of linksetData is that it allows for different programming paradigms that are more effective than link message alternatives. Consider a toy example: a system with 3 scripts all in the root prim, one 'main' script, and 2 'child scripts'. Each of the child scripts can be updated with some sort of configuration parameter (what is the UUID of a notecard that needs to be read, what color should some effect be etc etc.) but that parameter does not need to be used when it is updated, but is only used when some secondary effect takes place. In a Link Message implementation, each child script needs some logic to 1) determine if any received message is relevant to itself, and 2) if relevant, update a global variable. Both of the scripts receive messages intended for the other which need to be ignored, which adds some inefficiency. If too many messages are sent too quickly, the event queue will overflow, and some messages will be dropped. In a LinksetData implementation, the child scripts don't respond to the change until they actually need to use the parameter. If the parameter represents something that isn't a string (which is almost always the case), a typecast needs to be made for each read. So, arguably in cases where the information is read more than it is written, link messages could be more efficient, but linkset data scales better for a large number of scripts, and/or a large number of messages/information to transfer.

The age-block on the site only works if you run their scripts. If you don't run scripts from untrusted sources, or instead. just look at the raw html, no age verification.

Good point, but unless the rugs are built together intelligently, (Say, the rugs have the same base, but different tassels or something) that would require some advanced technical stuff in blender, for a result probably no better than linking all the models together.

I'm not intimately familiar with AVsitter, but for completeness, I'll point out that any solution needs to either rez different scripted objects (which Emma pointed out can be done in this system via props) or have all of the options linked together and make all but one of them invisible. "model swapping" proper isn't possible for SL meshes (but can be done with sculpties).

This is one of the few times I'd recommend using llEuler2Rot(). Move (a copy of) your object somewhere out in the open so you can move it around. Set the rotation of your object to all zeros in the build interface. Rez a cube put a sit script in the cube use a script that has a sit target with ZERO_ROTATION, and check that when you sit on it, you're sitting upright and facing due East (cube has 0 rotation) sit on the cube, move the cube inside your object, rotate the cube to fit. copy the x,y,z rotation values of the cube from the build menu to your script (the one in the object) as the values of the vector gRotation.

@Alexacroft does this kind of work and posts adds on the forums regularly. His prices seem pretty reasonable, but still an order of magnitude more than the high end of what things like this cost from a big-name seller already made.

I'd be very surprised if the fur looks that good in-world, if it even exists at all and isn't some Photoshop magic.

. . . Yes, even if that tooltip isn't part of the scripting interface. hovering over an object named "Object" with world->hover tips->"show hover tips"(ctrl-shift-t) enabled can paste "Object" into the script window, if the script window is active. (if you click outside the script window, the text-cursor disappears and tab does not paste text.) Buttons on the bottom row, and some things at the top of the viewer also produce hover-texts with paste-able content. As a helpful point to a potential bug report, pressing tab in a notecard editing window does not paste hover-tip text.

Same "helpful" feature: If your pointer is hovering over a comment (and the tooltip is displayed) . . . /* move text-cursor to next line while mouse-hovering over this line, then press tab: */ Comment (multi-line) // move cursor to next line while tooltip on this line is visible, then tab: Comment (single-line) "Move cursor to next line while hovering over this etc. etc.:" String literal listen listen(integer Channel, string Name, key ID, string Text) llListen integer llListen(integer Channel, string SpeakersName, key SpeakersID, string Text);

That happens when a tooltip is visible. for example, if you type 'listen' and then hover the mouse over it, then tab will paste: listen(integer Channel, string Name, key ID, string Text) it's mildly annoying that it duplicates some of the text ("listen" gets pasted even though you just typed it) and yes, very easy to do accidentally, but it's also useful in limited circumstances.

There are 2 methods of making a particle system only have a short duration. Use the PSYS_SRC_MAX_AGE parameter to set a duration. This comes with a few odd caveats, mainly when the system is on but the duration is passed, anyone coming into range from far away might see the particles go off, and people might see the particles go off if you teleport away while wearing it or the object is modified. Set a timer to go off when the particles should turn off. Fewer caveats, but mildly more complicated logic. you want to make sure to turn the timer off after it is activated, and when the particles are turned off otherwise.