Quistess Alpha

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") {...}

my vague recollections of micro-parcel rental rates were in the neighborhood of 50~100 L$ per week. Small parcels can often have inconvenient shapes though.

You're free to file a support ticket and tell us how (badly) that goes. . .

One of the first "adult" places I visited in SL had some very prominent "Kemono-no-no" signs (Kemono is a popular anime-esque body). Anime just really squicks some people I guess.

It helps to cite your sources. A quick google reverse image search finds: Tamisnapshots's flickr

Perhaps common sense doesn't need to be elaborated but. . . In any purchase where you're putting down that much money, you can and should contact the seller. If you make a sincere offer, they'd probably be willing to set all the parcels to sale to you, or work out some other methodology of doing the transaction where you're both happy with the (hopefully lessened after a friendly conversation) risk of the other party flaking.

A minor bug for an empty datastore: Also, to make it fire after changes to the datastore (useful for rapid sanity-testing/debugging), you can swap to a different state so it doesn't interfere with itself: // code as above until: llOwnerSay("LinksetData statisitcs:" // ... ); state waiting; } } state waiting { linkset_data(integer action, string name, string value) { state default; } }

N.B. I think it's been mentioned before in this or another thread, but apparently llLinksetDataWrite(k,v); does not generate a linkset_data() event if k already had the value v. This obviously makes sense in most use-cases, but it does make using LSD as a complete replacement for link messages slightly fiddly. (One possible protocol for an 'active message' is for the sender to write the LSD, and the receiver to delete it. This works fine unless the receiver doesn't receive the message (programming error) in which case the 'pipe could get stuck' if an identical message is common and you don't delete the value) No real reason not to use both if it makes sense to do so.

While working on my thing I just had a lightbulb moment: LinksetData can be used to turn any asynchronous request into a synchronous one with the help of another script (at the cost of some delay): // script A: string request = "Sensor"; llLinksetDataDelete(request); llMessageLinked(LINK_THIS,-5,request,NULL_KEY); string response; llResetTime(); do { llSleep(0.2); }while((""==(response=llLinksetDataRead(request))) && (llGetTime()<5.0)); llOwnerSay(response); //script B: link_message(integer i, string s, key k) { if("Sensor"==s) { llSensor(...); } } sensor(integer n) { list results; while(~--n) { results+=llDetectedName(n); } llLinksetDataWrite("Sensor",llList2CSV(results)); } no_sensor() // IMPORTANT, else A could end up in an infinite loop. { llLinksetDataWrite("Sensor"," "); } Of course, this isn't ideal if you can avoid it, but in some cases not having to "remember" finicky details (Ex. What am I sensoring for and why?) between events could be very handy.

I'm also starting to try and use it seriously for a thing, and the only thing I'd point out is that it's minorly annoying to distinguish between a 'key with a null-string value' and a 'non-extant key'. Also as a general rule, if there's a reasonable possibility other people's scripts might exist in the same object as yours, it's good hygiene to prefix your keys with something reasonably unique.

A domain-name conflict perhaps? Is your site associated somehow with the "Lane Cove Concert Band"? If not, you might need to reconfigure your host to use a different top-level url.

something like https://marketplace.secondlife.com/p/Escalator-sidewalk-rainbow/23762078 ?

If you're not familiar with llInstantMessage, try messing around to make sure you're happy with how it works when you're logged in or not. Depending on your account settings, it should send you an email if you're offline, which is a lot more noticeable than the easy-to-miss one-liner in local chat you'll get if you're logged in. If you expect to be logged in over region-restart times, you might consider llEmail(); instead or in addition to llInstantMessage.

PSYS_PART_FOLLOW_SRC_MASK disables generating particles at any non-zero distance from the emitter, and only makes particles "source-follow" the absolute position of the emitter, not its local orientation. So, the only way to make a particle "literally move" in a circle, as opposed to generating new particles for a "marquee lights" effect (spent too long searching for what those are called.. .) is to have the emitter prim offset from a llTargetOmega rotating root.

default { changed(integer c) { if(c&CHANGED_REGION_START) { llInstantMessage(llGetOwner(),"Region Restart: "+llGetRegionName()); } } } or so.

integer isOn; set_params() { integer i = llRound(llFrand(1.5))*isOn; llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, 2,i, PRIM_GLOW, 2, 0.15*i]); i = llRound(llFrand(1.5))*isOn; llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, 4, i, PRIM_GLOW,4, 0.15*i]); i = llRound(llFrand(1.5))*isOn; llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_FULLBRIGHT, 3, i, PRIM_GLOW,3, 0.15*i]); llSetLinkPrimitiveParamsFast(10,[PRIM_FULLBRIGHT, 2, i, PRIM_GLOW,2, 0.15*i]); i = llRound(llFrand(1.5))*isOn; llSetLinkPrimitiveParamsFast(10,[PRIM_FULLBRIGHT, 1, i, PRIM_GLOW,1, 0.15*i]); } default { touch_start(integer num_detected) { llSetTimerEvent(0.5*(isOn=!isOn)); set_params(); } timer() { set_params(); } } would probably work.

FIFY.