Quistess Alpha

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!

You ~could, but no-copy items have a bad rep for being fragile (try rezzing one on a mesh surface, or use firestorm's broken 'rez at last known location' feature, and they could disappear forever) and if a coalesed object contains even one no-copy object, it would inherit the same fragility. Also, having too many things selected at once can crash some lower end devices.

yes, but the OP wants to ignore time when the object is ~not attached. It wouldn't be too hard to add a little routine in the detach event to manage a global accumulator, but the detach event is not 100% guaranteed to run before the object has finished detaching, which could lead to a rare over-accumulation a more-correct implementation might be simply: integer gAttachedFor = 0; integer gUnixLast; default { state_entry() { llSetTimerEvent(5.0); // anything less than 1.0 is inefficient. gUnixLast = llGetUnixTime(); } timer() { integer t = llGetUnixTime(); integer diff = t-gUnixLast; gUnixLast = t; if(diff<10) // an overly generous allowance for lag. { if(llGetAttached()) // arguably should be nested in opposite order. { gAttachedFor+=diff; } } //if(gAttachedFor>X){...} } } but llGetTime() is nice for its simplicity.

Given the context I think it's clear enough. a more reasonable critique would be that the OP gave contact details, which would be expected to have a quicker response time.

A) A good faith 'please help me with this project' is welcome in this section, but this reads more like an add for the wanted section. . . B) Using an alt as a 'payment processor' account is indeed a good and common practice to make sure a system doesn't drain more funds than are allocated to it. C) The way I would design this system would be to use the description field of the terminal to indicate the total available funds. The terminal need only respond to a 'decrement' request on some shared channel, and the chairs keep the UUID of the terminal as a global variable in their script. the chairs should also listen for other chairs's decrement requests, and perhaps a manual 'update' message to re-check the terminal.

Perhaps the server is ignoring your request to reply with a specific range because you're using a POST request? did you try with GET?

Whether an object is attached as a HUD or regular object is only dependent on the attach point it's attached to. As for getting the object in the contents of the touched thing to attach, you need two different scripts, one in the touched object and ~another inside the object that you want to attach to the person.

See also :

If I'm not mistaken, llGetTime() will detail the amount of time an object has been in-world (rezzed or attached) since script reset or llResetTime(). The other solution is to just add to a global variable (or linkset data key / description field) on a timer.

It should be clear enough how to modify it so that it does. . .

Keep in mind we're all residents, and if you were to contact LL about it directly, youd probably get something along the lines of "hire an attorney for a brief consultation". That said, my 2 points: A) "what you can get away with" and "what is allowed" are rather different things. keep in mind that pretty much all of LL's policies are enforced by report. That means in a practical sense, how likely you are to get in trouble for anything depends on how many people see your stuff, and how pernicious the person you're copying is (not relevant to you, but Disney and Harley Davidson are well known for being mean). B) I (again, not an expert) think the main standard to be concerned with is 'would a reasonable person see my thing and associate it with the brand I'm copying?' if yes, you should try and change your thing so it's more generic.

Yeah, if you're clever with KVP, you can store records for everyone, as well as make a 'top ten' list for some specific metrics, but it's not very extensible if you sudenly decide you want to sort by something new. It does however have a clear advantage in being completely 'in-world' and not relying on expensive-to-maintain databases, or brittle APIs.