Quistess Alpha

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.

If you're a premium member, and the script only ever runs on your land, or land on which your experience is enabled, consider using the experience database llCreateKeyValue and related functions.

This step in particular is impossible (excluding the possibility of a manual copy/paste using the viewer). So that leaves only a few possibilities: Automatically send an updated version of the object/system to all owners of the previous version. You track those owners either via the distribution method somehow (depends on whether you use MP/casper/something-else.) or send a message to your server the first time the product is rezzed. It's pretty trivial to write a script that llGiveInventoryList()'s to a list of people, although it gets slightly less trivial depending on your order of magnitude. Send users of the old version a box that interacts with your old version and eventually uses llRemoteLoadScriptPin() to update the scripts. This is fussy and prone to weird failures. IMO not worth it in most cases unless the script has a lot of userdata in script memory (which can now survive transfer in a less fiddly manner with llLinkSetData) If your scripts are only to be used in one specific spot (A roleplaying region or something) this technique might be a bit more viable. The "box" could just be set up in the region. The scripts are "dumb" and mostly rely on internal data which can be updated. For example, a "texture HUD" could send a message to your server on each rez, and the server could message back if some of the textures are different in the new version. In most cases, getting stuff done in-world involves having a permanently rezzed prim or two. Prims do not change UUID on region-reset, so slow email communications are stable, but they will lose a url they acquired via llRequest(Secure)URL(). As for the more general "how do I get and use a webserver" question, (amazon-web-services)AWS free tier, seems like a decent entry-point if you don't have the technical know-how or reliable enough internet connection to self host with apache or similar.

Off-topic, but : Eww, why do they need my phone number for an account?

If you want the particles "spinning" I often find it useful to mix llSetTargetOmega() in with the particle effects, which works differently to the kind of omega the particle system itself provides. (using both at once can lead to some fun results)

~Possible, yes. ~practical, almost certainly not. the only way I could think to make that work would be either A) have LSL update the URL with some querystring data that gets passed into the javascript somehow, (javascript really isn't my area of expertise, I just have good luck googling "how do I do XYZ") or, B) even worse, the javascript periodically polls the prim for "is such and such button pushed". A is better performance wise but would involve LSL guessing the amount of time the user is into the track, B is "bad" on SL servers for obvious reasons, and could have worse responsiveness.

AVsitter rezzes the thing and then tells it who to attach to. The only way to "skip the rez step" is to use RLV, where you give the object to the wearer using a special folder via llGiveInventoryList, and then politely ask their relay (assuming they're wearing one) to 'force' them to wear the contents of the folder.

llPlaySound from a HUD should in theory work 'the best' in terms of volume, but would only be hearable by the person wearing the HUD.

So, when you're a premium member, your 1024 "free" land allotment can either be used to own a linden home on belliseria, OR you can use that tier to own up to 1024 meters of non-belliseria mainland. If you get both you would have to pay an extra monthly fee. In either case, 1024 meters of land only gives you 351 prims (unless you buy double prim mainland which is very expensive). In beliseria that doesn't include the prims for the house LL provides. Prim allowance scales linearly with meters of land, slightly more than 5 prims per 16 square meters. The only way to get a linden home is through LL: https://secondlife.com/land/lindenhomes/index.php For mainland, there are a few different ways to get a plot of land: you can buy one through direct sale from another resident, either by asking someone who has land for sale, or directly buying a piece of land that is set for sale (you can see parcels for sale on the world map) You can bid on land through an LL auction: https://places.secondlife.com/auctions#0 You can file a support ticket asking LL to sell you any piece of abandoned land (land that is marked as abandoned and owned by "governor linden") and LL will more often than not sell you the land at 1L$ per metre.

Here's an example for the x-axis facing the owner: rotation YPR2Rot(vector v) // Yaw Pitch Roll { return <llSin(v.z/2),0,0,llCos(v.z/2)> * <0,llSin(v.y/2),0,llCos(v.y/2)> * <0,0,llSin(v.x/2),llCos(v.x/2)> ; } rotation uVectorRoll2Rot(vector v,float r) { return YPR2Rot(<llAtan2(v.y,v.x),-llAtan2(v.z,llVecMag(<v.x,v.y,0>)),r>); } default { state_entry() { while(TRUE) { vector target=llList2Vector( llGetObjectDetails(llGetOwner(), [OBJECT_POS]),0)-llGetPos(); //Use one or the other and compare: rotation rot = // choose 1 uVectorRoll2Rot(target,0); //llAxisAngle2Rot(<0,0,1>,llAtan2(target.y,target.x)); //we can change the 'forward axis' with a left multiplication: //rot = llRotBetween(<0,0,1>/*forward axis*/ , <1,0,0>) * rot; llSetRot(rot); } } } I'm a tad too lazy at the moment to fit that into a sensor (in a sensor event, llDetectedKey(0) is usually the closest detected result)