Quistess Alpha

Things I might test/ would like to see in the wiki: What happens if certain parameters (REZ_POS and REZ_ROT specifically) are not specified? I.E. What are the default values?

Yeah, but you need to own your own region for that.

Also note that HUDs are just just ordinary SL objects, like the ones you can rez in-world, but attached to a HUD attach point.

You could have a 'server' object set up in-word somewhere; the egg (or the chicken, but need not be both) messages the server instead of rezzing from inventory. The server then sends a (no-copy no-mod) generic chicken object to the egg's owner. The first time the generic chicken is rezzed, it asks the server for its specific characteristics.

Right, but presumably the rezzer will be in the same sim as the rezzed object at the moment of rez; assuming chicken-first: Chicken contains both a copy of itself and egg. Chicken rezzes egg, gives it copy of itself and a copy of egg to the rezzed egg. Egg may change regions, but still contains a copy of itself and chicken. Egg rezzes chicken, gives it a copy of itself and a copy of chicken. Chicken . . .

Oh, I seem to have missed that somehow. The wiki says the object_rez event happens in other scripts in the same object, so another script ~should be able to detect an object rez, unclear whether the new event will transfer to other scripts in the same link.

If your script rezzes more than one type of thing, I think it's pretty valuable. Either you store the UUID in a global to check which of the things you might have tried to rez actually got rezzed, (imagine simultaneously rezzing 2 things with the same name, and being able to tell which is which!) or sleep until some sanity check tells you the thing is finally rezzed.

try llOwnerSay((string)llGetLocalRot());

Since you need to (very briefly) rez anything that is temp-attached, I don't think attaching it to someone gives much benefit over just having it rezzed in-world while the seat is in-use: the land needs the extra LI 'float' in either case.

I thought something like that might be plausible to mention it, but I don't know enough about how those are actually handled to say one way or the other. another thing to try might be to play the animation on an invisible animesh to "preload" it, but those eat up a fair amount of Li.

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.