Quistess Alpha

A bit of a tangent, but if you have mega bucks, 'literally everyone is doing it' and you can prove the copyright holder isn't actively doing much to protect their claim. . . but I think that's more common for trademarks.

Your account status shouldn't change how you upload files to SL. It's probably an issue with your viewer. Use an older version if you still have a copy, or try switching to a different viewer. Ask around in your viewer's support group if it has one. (Cool VL Viewer is a good choice for debugging viewer differences, as it's the most 'different' from other viewers.)

that makes sense, even if unintuitive; LSL's scope detection doesn't take jumps into account; the fact that there exists a variable definition previously in the same scope means the erroneous say references the local version of the variable (which isn't declared because of the jump!). Consider also: default { touch_start(integer total_number) { if(FALSE) jump hook_1; // no error if TRUE. else jump hook_2; @hook_1; string s = "1"; jump hook_out; @hook_2; //string s = "2"; // compile time error! @hook_out; llSay(0,s); } } also noteworthy is that the fact that the variable is a string is important; integers seem to be initialized correctly to zero even if their declaration is jumped over.

It seems the OP wants to make a HUD that instead of changing the texture on your own clothing, changes the texture on someone else's clothing. In principal, that's not too different from a regular texture change HUD, but it would require specific changes to the script, and possibly the addition of a UI for targeting the specific person who's clothing is to be texture changed. (or just a switch between targeting oneself and llGetObjectDetails(...OBJECT_LAST_OWNER_ID...) )

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.