Quistess Alpha

High level stuff you already know: To rez an object tangent to another object, you need 3 pieces of (rotational) information: The normal of the surface being rezzed on The normal/axis of the object to be rezzed (semi-optional) the 'roll' the object will have when rezzed (I.E. if your thing is a piece of paper, where do the corners go?) for sake of illustration, or if you ~really don't care about the roll (Ex. because your object is a cone/radially symetric) llRotBetween((2),(1)); should give you a semi-reasonable orientation: vector a; vector b; // application dependant. list ray = llCastRay(a,b,[RC_DATA_FLAGS,3]); key k = llList2Key(ray,0); vector pos = llList2Vector(ray,1); vector normal = llList2Vector(ray,2); // do some sanity checking on those, I've not tested in-world. // if sanity passes: vector up = <0,0,1>; // which vector points 'up' for the object? float half_height = 1.0; // distance from ground to object center llRezAtRoot("rez-me",pos+half_height*normal, <0,0,0>, llRotBetween(up,normal), 0); ETA: I was going to explain the cross-product trick as an improvement, but Fenix already wrote out an example of it.

if your routine is something that can be don in terms of llSetLinkPrimitiveParams(fast), or a "link" function, then you just have to loop through all prims in the linkset: //integer index_prim = llGetObjectPrimCount(llGetKey()); // does not count sitting avatars. integer index_prim = llGetNumberOfPrims(); // may count avatars sitting on the object. // loop backwards: do { llSetLinkPrimitiveParamsFast(index_prim, [...]); }while(--index_prim); There are very few things left in LSL that must be done by a script in the specific prim which needs to be modified. Sounds were the most glaring example, but link sound functions were added fairly recently.

Making the avatar walk at a specific speed is non-trivial if you want other nice things like being able to walk up stairs/tiny ledges, and not fly backwards when trying to go forwards while falling. I have a few different implementations in my "fine for personal use, but probably not good enough for a general-use product" bin of 95% finished products. see:

for pretty much anything I do, a single script is sufficient, but I imagine for a system with enough complexity, you could probably implement some sort of 'no-write' flag while the complex read function is working. that might not be ~perfectly immune form certain race conditions, but it would probably be good enough for most applications.

If I were implementing this, I think I'd have both listening modes available at the same time, and use llListenControl to switch them: (untested example code:) // HUD integer CHAN_SELF = 1234; // could use pseudo-random generation, but I don't see a benefit. integer CHAN_SYNC = 4321; integer gSync = FALSE; default { touch_end(integer n) { if(...) { // sync ON gSync = TRUE; // assuming the listener is an attachment, it will hear messages directed at the owner: llRegionSayTo(llGetOwner(),CHAN_SELF,"SYNC_ON"); }else if(...) { //sync OFF gSYNC = FALSE; llRegionSayTo(llGetOwner(),CHAN_SELF,"SYNC_OFF"); }else if(...) { // send message: if(gSync) { llRegionSay(CHAN_SYNC,"msg"); }else { llRegionSayTo(llGetOwner(),CHAN_SELF,"msg"); } } } } // listener integer CHAN_SELF = 1234; integer CHAN_SYNC = 4321; integer gHandleSync; default { state_entry() { llListen(CHAN_SELF,"",llGetOwner(),""); gHandleSync = llListen(CHAN_SYNC,"","",""); llListenControl(gHandleSync,FALSE); } listen(...) { if("SYNC_ON"==msg) { llListenControl(gHandleSync,TRUE); }else if("SYNC_OFF"==msg) { llListenControl(gHandleSync,FALSE); }else if(...) { } } }

My firestorm's broken at the moment, but I tested it in Kokua and that doesn't seem to be the case? (I think in some cases it may look like you're sending the offer, but the other party doesn't receive it; try testing with 2 accounts logged in at once, or use a friend.) "@permissive=n,showloc=n,sendim=n,share=n,pay=n" should be sufficient to give enough of an illusion of helplessness. There's nothing you can really do to stop say, messaging a friend on discord, or using an alt.

Making an avatar go somewhere via LSL is . . . clunky. The viewer actually as support for old runescape style 'click to move' though. My 'ease of use' solution would just be to auto target: is someone with a sword (and compatibility HUD or whatever) within 10 meters of a skeleton? Move the skeleton directly in front and facing the avatar (because moving avatars via script is hard) and have the skeleton and avatar play sword swinging animations and stuff. . . too bad we can't make damage number particles look nice, unless the system uses single-digits.

Yeah, and in RLV proper ( RLVa has a payment restriction ) you can always give someone 1L$ with a message asking them to come over.

@showloc or anything that restricts knowing the current location I believe (because I just tested and confirmed that it) also prevents sending teleport offers.

I think this link still is valid for searching the MP for freebies: https://marketplace.secondlife.com/products/search?utf8=✓&search[layout]=gallery&search[category_id]=&search[sort]=sales_rank_asc&search[per_page]=96&search[keywords]=NOT+demo&search[price_low]=0&search[price_high]=0&search[land_impact_low]=&search[land_impact_high]=&search[copy_permission]=0&search[modify_permission]=0&search[transfer_permission]=0&search[limited_quantities]=0&search[is_demo]=0&search[is_demo]=1

you need the entry # in the list; llListFindList() can help you find the entry number if you know exactly the thing in the list you're trying to delete.

Have you actually tried that? I may be mis-remembering, but I thought BOM without correct alpha mode led to dreaded red-skin.

Apparently, 'kitten' is the magic search word.

Yeah, I get 0/86 elements, with both accounts I tested with, all folders, no contents.

I have the folders, but they're all empty 😞

I ~really had to squint to see the OP's image seems to actually imply they're looking for platform boots, possibly compatible with the maze thighs addon.

That's an issue with how the editor variable is set-up in your configuration. TL;DR, the 'ExternalEditor' debug setting needs to have double-quotes around the %s to avoid the issue, for example: /usr/bin/st vim "%s" on my linux setup

you already can if the animations or whatever are full-perm. I don't recall if the HUD has to be full perm too.

Either the alt owns the thing that gives out money, or the thing that gives out money is deeded to a group, and everyone in the group who has a certain role responsibility (I'm too lazy to look and see exactly what the terminology is atm) will automatically have all the payments equally divided among them. I forget exactly how the permissioning for group-deeded objects works though. the role might also need an ability to permit the terminal to do transactions, and the more I think about it, that's actually a pretty bad idea, because anyone in the group with that ability could grant permission to a 'malicious' object which just gives themself a large amount of money. In a reasonably secure setup, a group owner would have to manually inspect and activate every terminal.

Looks like it's not using any particularly sophisticated protections on the raw media file: https://dcs.megaphone.fm/TPG5680173094.mp3

I think if someone wants to rely on the linkset_data event to keep track of multiple deleted keys. they should stagger the deletion similar to how a usual notecard read is structured (see code example). I don't think there's a good general case to handle that by back-end convention (a CSV in the linkset_data event argument could be equally problematic for large operations) string delete_regex = ".some regex."; default { state_entry() { llLinksetDataDelete((string)llLinksetDataFindKeys(delete_regex,0,1)); } linkset_data(integer type, string key,string value) { if(type==LINKSETDATA_DELETE) { // does llLinksetDataDelete(""); generate an event? if it does, do a sanity test here. llLinksetDataDelete((string)llLinksetDataFindKeys(delete_regex,0,1)); } } } // untested. I'd be happy with llLinksetDataDeleteFound() generating a special kind of linkset_data event with the integer parameter as a new constant LINKSET_DATA_DELETE_MULTIPLE (==3) , and perhaps overloading the name and value parameters with the number of deleted keys and number of found but not deleted respectively (same as list return values, converted to strings). Or some other useful info, like the regex used in the first parameter and the # of keys as a CSV in the second.

That would probably work well enough in practice, but you'll accumulate an 'orphaned' listen handle every time someone doesn't respond to the textbox. The 'standard' approach is to remove the listen on a timer, and before adding a new one with the same function. integer comChannel = 0; integer comHandle; default { touch_start(integer total_number) { llListenRemove(comHandle); comChannel = (integer)llFrand(1000000000)-1000000000; llSetTimerEvent(120.0); // 2 minute allowance for response. comHandle = llListen(comChannel, "", llDetectedKey(0), ""); llTextBox(llDetectedKey(0), "\nPlease enter a test-string to broadcast to growl-enabled devices:\n", comChannel); } listen(integer channel, string name, key id, string message) { llMessageLinked(LINK_THIS, comChannel, message, id); llListenRemove(comHandle); // come to think of it though, you do need to remove it in the listen event as well to prevent double responses. llSetTimerEvent(0); } timer() { llSetTimerEvent(0); llListenRemove(comHandle); } } although, personally I generally prefer a fixed channel and llListenControl(); integer comChannel = -14523; integer comHandle; default { state_entry() { comHandle = llListen(comChannel,"","",""); llListenControl(comHandle,FALSE); } touch_start(integer total_number) { llListenControl(comHandle,TRUE); llSetTimerEvent(120.0); // 2 minute allowance for response. llTextBox(llDetectedKey(0), "\nPlease enter a test-string to broadcast to growl-enabled devices:\n", comChannel); } listen(integer channel, string name, key id, string message) { llMessageLinked(LINK_THIS, comChannel, message, id); llListenControl(comHandle,FALSE); llSetTimerEvent(0); } timer() { llSetTimerEvent(0); llListenControl(comHandle,FALSE); } }

You're looking very prim and proper today. (technically a compliment, but the implication is prims are bad and ugly) Looks like you're all put together! (damned by faint praise?) Why, you look no older than the day you rezzed! (but don't new residents look kinda bad off the boat?

what did you try, and what exactly didn't work about it? Either should trigger a detection event (collision_start() or sensor() ) from which you should be able to get the key of the detected avatar(s) with llDetectedKey() and convert it to a name with llKey2Name or a fancy SLURL, (llSay(0,"secondlife:///app/agent/"+(string)ID+"/inspect");) if you want a 'notification' when you're not close by, consider llInstantMesage() or llEmail()

Hmm, that safety feature wasn't around 3 years ago or so, but that is rather nice. Also, flinging the first no-copy thing I found (that I know I can get from the MP for free) at some mesh didn't eat it, but it's hard to disprove that there's any scenario left where mesh ~could eat your no-copy items. Glad to know SL ~has improved some of the subtle stuff in the last few years!