Quistess Alpha

I'm a little concerned I didn't get any error though, helpful or not.

So, I've never seen LSL do this; when I save a script including this snippet [2 identical jump labels in similar scopes], the viewer doesn't complain, but the server refuses to run the script (close build menu, re-open and edit script and it is set to not running) default { state_entry() { integer a; integer b; if(a) { if(b) { jump break; } @break; }else { if(b) { jump break; } @break; } llOwnerSay("Hello Avatar"); } touch_start(integer total_number) { llSay(0, "Touched."); } }

IMO the most sane solution to the problem would be to allow access to the KVP datastore from outside experience-enabled parcels, but I don't see that happening.

Just a thought, but if this ends up being a user-facing project, you can use a (x)html website embedded in the script to ask the user to upload a file from their computer to the prim. ETA: actually, nevermind, that method cuts the length of the file to a few hundred less than 2048 chars <form enctype="multipart/form-data" method="POST" > <input type="file" name="fileselect"> </input> <input type="submit"></input> </form>

Since you asked, the documentation is a bit loose on attaching to a specific slot, but some older versions of RLV required you to put the attachent point name in the name of the object or folder to be worn. Whenever I've used it, it 'just works' with the default attachment point.

It still ends up one-line on the new script, which is fine if you just want it to run, not so fine if you're trying to understand why it runs. search replace "{" with "{\n" usually gets you a good start. I dunno if the inworld editor can do newlines, but some external ones can.

I think order of operations works in your favor there, but of it were me, I'd use 5.0/9.0 to avoid mixing integer and float arithmetic, or just multiply by .5555 .

A nice example, but as I read it, it returns a fixed number of digits rather than a fixed precision: Fixed to 3 Digits Fixed Precision 10ths place 12.7 12.7 101. 101.5 1.23 1.2 Whether there's a difference depends on the range of the input though. ETA: Actually I'm wrong as I read through it too quickly and didn't think through the weirdness of SL's default presentation, and tacit negative indexes.

There are various methods, but off the top of my head: float fTemp = formula; // calculate the temperature with full accuracy. fTemp = llRound(fTemp*10)*0.1; // round to desired accuracy. string sTemp = (string)fTemp; // convert to string; sTemp = llGetSubString(sTemp,0,llSubStringIndex(sTemp,".")+1); // remove trailing 0's. (untested) llInsertString() the decimal point into a llRound()ed integer might be a viable alternative approach, but llInsertString doesn't take negative indexes.

It's not too too bad if you also cut movement speed by about half. Last time this discussion came up (found it) someone touted these trailers as being a good example of realistic sizing so I took a blurry video:

The region sim doesn't stream audio itself, it just passes on the stream's URL to interested viewers.

Unfortunately, I don't think you can easily manage the complexity inherent in a project like that with the limited tools LSL has available, unless you limit yourself to some very specific parameters to adjust an 'already finished' build. The main 'do it yourself' building systems I'm aware of are sets of mesh elements that all work together at a specific scale, and not much customization on them is possible beyond llSetScale();. See for example: Zimberlab Blocks, Zimberlab Walls (they're different systems, useful to compare/contrast), Isil's 'Sci-fi' system

Another (rather expensive) method would be to add 14 [1]'s and 1000-14 = 986 [0]'s to a list, llListRandomize() it and step through it, rezing if you pick a [1] from the list, re-randomizing after you hit the end. That would result in a different kind of random distribution.

If @ing those people doesn't work, you could always try filing a jira https://jira.secondlife.com/secure/Dashboard.jspa

it depends on how the asset class ends up being managed. If it's fully configurable using in-world utilities (like a day/night setting object) ho-ray. On the other hand, if LL throws up their hands and implements it more like current textures (no 'fundamental' changes after upload, no-mod practically just applies to the description field) I could see some concerns.

You could try opening the stream URL in an in-world browser session. (ctrl-f seems to open a window in Kokua, YMMV for other viewers)

It would help to have some kind of identifying information about the skin you're looking for. Also, my experience has been that people are usually willing to tell you where they got stuff if you ask nicely.

Especially since Facebook is coaching people into helping their AI face-match you. Eww.

Moderate; no it cannot be changed, but you can of course buy or rent adult mainland if you are a premium member. "Adult" activities are in-fact allowed on moderate land if it's not advertised, and reasonable precautions are taken to prevent passers-by stumbling into it.

Just to provide another idea to try: if( (llHash(llGenerateKey())%1000)<14 ){...} is a more expensive alternative to llFrand that may or may not have minutely different randomness characteristics. ETA: see below, quick fix is: if( (llAbs(llHash(llGenerateKey()))%1000)<14 ){...}

https://marketplace.secondlife.com/p/TMG-Bladencat-MK8-ULTRAUpdated-6-15-20/19280993 and that creator has a handful of minor variations on it. Clothing support is fairly limited though.

That's doable with llList2Integer(llGetParcelDetails(POSITION,[PARCEL_DETAILS_FLAGS]),0)&PARCEL_FLAG_ALLOW_SCRIPTS; for some POSITION on the same region. You mean the number of avatars who are currently on a region? That should be discoverable by some contrivance. . . 1 & 2 are privacy concerns even if you can manually check #2 from a shared group, #5 seems pretty niche.

I'm not well-versed in viewer internals, but anecdotally, "Right-click 'updates' the object" seems common to most (all?) viewers. My main experience with it is that right-click "removes" ghost clones of an object that might remain after llSetRegionPos()ing the object to a different region.

Probably an issue with you specifically not receiving the update packets due to a loose connection. Are you setting all the faces to the same texture? If so try: llSetLinkPrimitiveParamsFast(Link, [ PRIM_TEXTURE, ALL_SIDES, texture, <1,1,0>, <0,0,0>, 0.0 ]); otherwise: llSetLinkPrimitiveParamsFast(link, [ PRIM_TEXTURE, 0, texture0, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 1, texture1, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 2, texture2, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 3, texture3, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 4, texture4, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 5, texture5, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 6, texture6, <1,1,0>, <0,0,0>, 0.0, PRIM_TEXTURE, 7, texture7, <1,1,0>, <0,0,0>, 0.0 ]); or so. If you have multiple links you can even string them together in the same call with PRIM_LINK_TARGET.

Your script seems to be working as expected (response gets saved to the variable and reported back) the problem is probably with the other script. For debugging it's often useful to add in some llOwnerSay Statements: Note that it is case sensitive. in this case though, it might help to make the script a bit less 'brittle' to specific inputs: integer ChIn = 925528; //Channel-In handles incoming "Ask" message integer ChOut = 925529; //Channel-out speaks Answer to asking prim string $SavedState; default { state_entry() { llListen (ChIn, "", "", ""); } listen (integer channel, string name, key id, string message) { if(ChIn==channel) { if("ASK"==message) { llSay(ChOut,$SavedState); }else { $SavedState=message; } } } //listener end }//default end alone might make it more obvious what it's picking up. Remember, LSL is case-sensitive. If you need case-insensitivity you could try something like: if (channel==ChIn && llToLower(message) == "red") {...}