Quistess Alpha

It depends on exactly what you want your renters to be able to do, and which group role you're going to give them. In the group window for your group, in the "roles and members" accordion, select the "ROLES" tab, then the name of the role you want to modify (or create a new one), then scroll down to the 'allowed abilities' section. by default, new roles will have none of the abilities enabled. Don't enable any of the abilities under 'parcel management' or 'parcel identity' sections.

just don't give the renter's role in the group the necessary abilities to do so.

No Kupra size, but I thought back to this post when I saw: https://marketplace.secondlife.com/p/V-VoluptasVirtualis-Jade-MaitreyaSlinkBelleza-DEMO/18949213

For sounds+animations, have you tested the efficacy of gestures rather than controlling the effect via a script?

I don't think it says as much on the wiki, but CAMERA_POSITION and CAMERA_FOCUS are the most generally useful for doing anything that isn't specifically intended by the built-in camera model, but, they're quickly overridden by said model unless the *_LOCKED parameters are set to TRUE. I don't like using fast timers, but you need this to go as fast as possible for it to not feel bad. Also, given its server-side nature, it might feel weird for people with a laggy connection.

SL camera controls are borked because there's no way to turn off the camera's default behaviors without destroying its ability to smoothly interpolate between positions. that said: vector gPosTarget = <38,166,2016>; default { state_entry() { llRequestPermissions(llGetOwner(),PERMISSION_CONTROL_CAMERA); } run_time_permissions(integer perms) { if(perms) llSetTimerEvent(0.022); } timer() { vector posOwner = llList2Vector(llGetObjectDetails(llGetOwner(),[OBJECT_POS]),0); vector posBetween = 0.5*(gPosTarget+posOwner); // exageratedly far out: //vector posLeft = posBetween+ 10*llVecNorm((gPosTarget-posOwner)*<0,0,0.71,0.71>); // different zooming: //vector posLeft = (0.75*posOwner)+(0.25*gPosTarget) + 0.9*((gPosTarget-posOwner)*<0,0,0.71,0.71>); // more like mortal combat: vector posLeft = posBetween + 0.65*((gPosTarget-posOwner)*<0,0,0.71,0.71>); //posLeft.z = posOwner.z+2.0; // higher camera looks better further away, posLeft.z = posOwner.z; llSetCameraParams( [ CAMERA_ACTIVE, TRUE, CAMERA_FOCUS_LOCKED, TRUE, CAMERA_POSITION_LOCKED, TRUE, CAMERA_FOCUS, posBetween, CAMERA_POSITION, posLeft ]); } } Roughly works.

Also, on the topic of rezzing objects, how hard would it be to rez something that's ~Not in the object's own inventory? Scripting objects that are inside of other objects is a major pain, so being able to rez a copy of an object that is already in-world would be super helpful for developing a system, even if it doesn't get used in a final product.

how about adding arbitrary linkset data keys with your new rez function, REZ_LSD --- parameters: string key, string value --- the linksetData Key 'key' will be set to have a value of 'value' in the rezzed object--- Bonus points if it can be specified multiple times in the list for different keys/values.

https://wiki.secondlife.com/wiki/LlAddToLandBanList and the similar related functions mentioned at the bottom of that page. doesn't work on mainland parcels. To implement the 'only allow access when not home' idea, I think you might have to loop through llGetAgentList on a timer and llEjectFromLand everyone on your parcel if you're not in the list. (and have a warning + 10~30 second grace period before the ejection)

index should start at 0, and you want to populate another global list (or make your list 2-strided) to contain the keys so you can associate them with the names.

For this specific functionality on personal projects, I'll usually just use 'chat links' which, are arguably less user-friendly, but have fewer scripting caveats. Roughly: gKeyMenuer; // the person using the menu. gChanMenu; // the menu channel gSensorTag = "nearby avatar"; // code for why the sensor is happening, and what to expect in the listen event. sensor(num) { llRegionSayTo(gKeyMenuer,0,"Right-click -> 'run this command' on the "+gSensorTag+" to select:"); while(~--num) { llSleep(0.1); // need to be careful about not tripping sayTo throttle. key ID = llDetectedKey(num); string name = llKey2Name(ID); llRegionSayTo(gKeyMenuer,0,"[secondlife:///app/chat/"+(string)gChanMenu+"/"+llEscapeURL(gSensorTag)+","+(string)ID+" "+name+"]"); } } you can also have an agent/inspect SLURL as well as the chatlink SLURL for a bit of extra clarity. I only skimmed it, but I don't see that on the cited page. The last time I tried to implement that, I used some new linkset data functions which happen to count bytes rather than characters.

Actually, I just realized SL ~Does store the original x,y dimensions of every texture, just not in a way scripts can access. Details of how to access it vary by viewer, but it's usually underneath the texture in the 'texture picker' window when you try and texture an object. The default wood texture is 512x512, the blank white texture is 32x32.

Also of note, inventory of in-world objects do seem to have a description field. . . as well a sale price and buyable flag.

Yeah, LL damage isn't a very fleshed out system. Usually combat systems manage to somehow implement their own version of 'health points', which usually requires all the participants to be wearing some sort of HUD with non-trivial scripting. With an experience, it's feasible to force everyone on the parcel to wear such a HUD (if they opt-in to the experience).

AFAIK, there's (currently) no way to get the description field of a texture via script.

👍 that is indeed standard practice for this sort of thing.

PERMISSION_DEBIT is fine as long as you understand the use and the risks. Especially if the vendor's script is visible to you, you know it's not going to do anything too dumb.

You can set the "click action" to pay (edit window, or llSetClickAction) , so they can left click instead of right click; but unfortunately, the user needs to initiate the payment interaction, there aren't many good ways to directly suggest it to them. You can use a SLURL, but it's not intended and buggy (obscures the name of the thing you're paying, doesn't respect llSetPayPrice) default { state_entry() { llSay(0, "[secondlife:///app/agent/"+(string)llGetKey()+"/pay click here to pay]"); } money(key payer, integer amount) { llInstantMessage(payer,"Thank you for your donation."); // Used for testing, turns out it only works if you're on the same region (obviously?) } }

- SL is moderated by Land-owners first, and Linden Lab* second. If someone is being mean to you, send an IM to whoever owns the land (look at world ->"about land") and politely explain your problem. You can also block people you don't like, and nobody can follow you if you teleport away. - Third party viewers (TPV's) exist. They often have special features (Area search, built-in AO, RLV(a), better linux compatibility. . .) that the standard viewer from LL doesn't. https://wiki.secondlife.com/wiki/Third_Party_Viewer_Directory - You can add local textures to an object without uploading them, but only you will see them. - The Beta grid exists - There are lots of free and low-price things on the marketplace. In-world "freebie" stores often just have "old junk" that long time residents might look down on. * (bonus fact, Linden Lab is singular)

More efficient too. If you're a real visual snob, you do have to be careful about the edges though, as everything's on the same texture: when viewing a texture at low resolution, different 'frames' can bleed into each-other slightly.

depends on how you set it up. If you piggy back on an already existing service (N.B. chatGPT specifically is designed to avoid adult content, but I assume there are alternatives) the simplest implementation usually just involves giving the model a 'starter string' (there's a technical term for it I'm sure) that coaxes the model to behave in the way you want it to ("you are an android in the virtual world of Secondlife. . . someone comes up to you and starts a conversation: . . . <begin user input>) and append all the conversation and the AI's responses to that as part of the string the AI is trying to expand (Large language "AI" models are basically just 'find the next word given this string' solvers, applied in intelligent ways). if the algorithm is already trained and set in stone, User's responses don't bleed into each-other, but that would depend on the exact service and implementation. The "safest" option would of course be to roll your own system, but that would at a minimum involve keeping logs of every conversation your users have with your bots, which seems a bit ethically grey to me. (less grey than handing those logs over to a third party, but still.)

Oh a friend of mine has something like that with RLV for RP purposes: No IMs unless she regularly charges her phone.

Substantially different from existing systems like thundr and avmatch.com ? Paying someone to write something on that level of polish would be rather expensive (high hundreds to low thousands of USD ) and learning to do it yourself would be very time consuming. And given that there's already competition in that area, I don't think it would be especially lucrative. Something on a smaller scale might be possible though.

That sounds like it could be rather involved. Something for a speed-dating session or more of a discoverability platform?

Yeah, I didn't want to throw out an accusation of the last example of where I expected it, but when the code doesn't match the comments, and there are some comments that wouldn't make sense to put in a script for personal use (like "//don't change anything below this line" after the global variables section) it does make me really suspicious. It's a little frustrating, because the "mistakes" in -the kind of code I suspect of being written by a bot- just don't seem at all the kind of mistake someone honestly trying would make, so there's no real logical help to give other than "this is a right way to do it" which isn't really the point of these forums. Idunno, do we need a "please don't ask for fixes to machine generated code" community guideline?