Quistess Alpha

midi could be fun to play with, postscript would be awesome if it worked (doubtful)

I didn't know you could directly embed a (severely space constrained) page directly into the URL like that. Neat!

The in-viewer web browser can resolve SLURL links (anchors) in HTML, but I'm not sure if it can do the pretty formatting. for example: <a href="secondlife:///app/agent/8645873d-1306-4f22-a60c-4f2bc3bb9ca2/about"> Tessa's profile </a> creates a clickable link to my profile if viewed as (X)HTML in the in-viewer web browser. It would be really useful if app/chat links weren't blocked for some generic 'security reason'. but that's off-topic. . .

I'd have to have the viewer remap window in front to confirm or deny, but perhaps that function prematurely stops the "walk_to" action? (By default I think walk_to is unbound, I usually bind it to 'q', rarely useful, unless you're used to runescape style controls; could be useful in a setup where a script forces an overhead camera view.)

Ahh ok, it's not clear on the wiki page, but according to that they're supposed to resolve to the key that is bound to that function for the user's viewer. That's a pretty nice and sensible design idea!

So I just looked at the 'Viewer URI Name space' page and noticed a lot of things that definitely weren't there last time I looked. Specifically the /keybinding domain; it's not 100% clear how those are supposed to work, how do you describe the key that is to be bound to the action? (if that's what they do?) which print the key that the user's viewer expects to perform the given function.

if it's for saying / ownerSaying you can convert the key to a SLURL like secondlife:///app/agent/<key>/inspect which is often more useful than just their name.

If I'm reading it right, the script already seems to have a non-zero PSYS_SRC_MAX_AGE, which will cause its particle effect to activate whenever someone sees it enter their draw distance or receive any unrelated-to-particles object update. People other than the wearer may already see the particles happen when the wearer teleports into a region.

They probably copy-pasted from a word processor and didn't turn off rich-text support (a blink or you'll miss it option that pops up in this forum's interface after such a copy).

If you want other people to be able to see it, and you have land rights, and access to a private server, the parcel media texture accurately displays the parcel media image on particles. (but not projectors unfortunately)

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.