KT Kingsley

From the LSL wiki (https://wiki.secondlife.com/wiki/Category:LSL_Events), "Events do not interrupt each other, but instead are queued FIFO, though the state_entry event can jump the queue." For your other scenario, no, you can't pause an event so another event can execute. You'd need to put the continuation code into the listen event itself.

I just did a quick check, and it looks like @showinv sets a global restriction; any single object can set this to prevent opening the inventory floater, and all objects that have set it must reset it to allow opening the inventory floater. According to the RLV API wiki page, "Some commands set global behaviours, which aren't limited to the object sending the command." but I don't see any indications as to which commands do and which don't. (Also, https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Important_note_about_the_global_behaviours_such_as_sendchat.)

There's the Teleport History tab in the Places floater you might try. In Firestorm Alt+H brings it up directly. Edit: actually, Alt+H brings up a stand-alone Teleport History floater, independent from the tab in the Places floater.

The RLV command @getinvworn seems to be what you're looking for. https://wiki.secondlife.com/wiki/LSL_Protocol/RestrainedLoveAPI#Clothing_and_Attachments_.28Shared_Folders.29

There's llGetLinkKey. I guess the way to use this would be to run through the linkset saving the key and the link number of the critical prims based on their names or descriptions when the linkset is first made. Then when/if the changed event is triggered with CHANGED_LINK set, you'd run through the linkset again resaving the link numbers of the links whose keys you've saved. And you could use LSD to save this data so that it survives a script reset.

First you must create a listener using the llListen function. This is where you can specify which channel is to be monitored, and filter chat on this channel by the name of the speaker, the key of the speaker and the message being sent. You can use the empty string, "", as a parameter for the name, id and message parameters which causes the listener to accept any message, from anyone or anything. Only the channel must be specified: llListen (99, "", "", "");. Listening object script: default { state_entry () { llListen (99, "", "", ""); } listen (integer channel, string name, key id, string message) { llOwnerSay (name + " (" + (string) id + ") said \"" + message + "\" on channel " + (string) channel); } } Speaking object script: default { touch_start (integer total_number) { llSay (99, "Touched."); } } (Or just type /99 Hello! into chat.)

Maybe their clothing contains scripts that collect the UUIDs of nearby avatars.

This quickie (using the Firestorm particle editor) creates a ring around the generating object. The essential items are the cone pattern, the begin and end angles, the burst radius and the (lack of) speed. Is this the sort of thing you're after? default { state_entry() { llParticleSystem( [ PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_ANGLE_CONE, PSYS_SRC_BURST_RADIUS,0.5, PSYS_SRC_ANGLE_BEGIN,1.5, PSYS_SRC_ANGLE_END,1.5, PSYS_SRC_TARGET_KEY,llGetKey(), PSYS_PART_START_COLOR,<1.000000,1.000000,1.000000>, PSYS_PART_END_COLOR,<1.000000,1.000000,1.000000>, PSYS_PART_START_ALPHA,1, PSYS_PART_END_ALPHA,0, PSYS_PART_START_GLOW,0, PSYS_PART_END_GLOW,0, PSYS_PART_BLEND_FUNC_SOURCE,PSYS_PART_BF_SOURCE_ALPHA, PSYS_PART_BLEND_FUNC_DEST,PSYS_PART_BF_ONE_MINUS_SOURCE_ALPHA, PSYS_PART_START_SCALE,<0.500000,0.500000,0.000000>, PSYS_PART_END_SCALE,<0.500000,0.500000,0.000000>, PSYS_SRC_TEXTURE,"", PSYS_SRC_MAX_AGE,0, PSYS_PART_MAX_AGE,2, PSYS_SRC_BURST_RATE,0.3, PSYS_SRC_BURST_PART_COUNT,10, PSYS_SRC_ACCEL,<0.000000,0.000000,0.000000>, PSYS_SRC_OMEGA,<0.000000,0.000000,0.000000>, PSYS_SRC_BURST_SPEED_MIN,0, PSYS_SRC_BURST_SPEED_MAX,0, PSYS_PART_FLAGS, 0 | PSYS_PART_EMISSIVE_MASK | PSYS_PART_INTERP_COLOR_MASK ]); } }

The RLV command @getinvworn (which is what I was thinking of in my earlier post) will, in fact, also indicate empty folders and sub-folders, so you could try using this to build your list. Using llGiveInventoryList as specified in the RLV wiki page might be useful for building a new inventory tree (you can specify sub and sub-sub-etc-folders in the folder name parameter), but there are problems: the root folder of the tree in the #RLV folder must have a name starting with a tilde (which you could rename manually), the item list can't be empty (so your new tree will contain items, at least in its terminal folders – but maybe giving the items a common, easily searched name will make manual deletion easier – or just use a non-wearable asset), you'll have to get your head around the order in which you call the function for the various branches so as not to create duplicate folders in your tree, and you'll have to respond to an Accept/Decline dialog with every call.

I'm probably wrong in assuming that ChatGPT is what's wrongly called an artificial intelligence (and is perhaps better described as a pattern learning, matching and extrapolating system), that's been geared towards code for various programming/scripting languages, with maybe a smidgen of context keywords thrown in? If I'm not wrong then ChatGPT is matching it's rudimentary and incomplete input of the patterns of LSL code (and possibly an overexposure to LSL function wish-lists) with those of, I guess, JavaScript or something similar where a hover event is a given. Possibly someone influential at Linden Lab will see this as a message from the Singularity and implement some LSL that would definitely be cool, if maybe not all that essential.

With RLV, the most you can get about folder/sub-folder contents is none/some/all items worn. Which, depending on what you're trying to do, and how (assuming you're only looking at messing with yourself) you've arranged your #RLV folders and sub-folders does actually give for a multitude of absolutely non-creepy uses

I seem to be seeing two versions of this, one where the viewer forgets to render stuff that it knows is there (which happens after maybe 10% of TPs), and one where the viewer just doesn't appear to know about stuff (which happens after maybe 1% of TPs). The former can be cured by clicking or by toggling wireframe mode, while the latter seems to need a TP out and back after a few minutes. This has been happening for quite a long time, months or even years, but I haven't noticed any increase recently. I'm using Firestorm.

The switch object needs only a very simple script that reacts to the touch_start event by by chatting a message to the moving object. Ideally this would be done using llRegionSayTo with the UUID of the moving object, and on whatever channel you choose (usually a large negative number). The moving object script sets up a listener using llListen set to that channel. When the listen event is triggered the moving object can compare its current position with either of the two jump locations and then move to the one it isn't at. You can get the moving object's UUID by putting a line, llOwnerSay ((string) llGetKey ()); into its script and copying the resulting chat into the switch script. This is fine if the moving object gets rezzed and stays rezzed. If, however, it's something that comes and goes it may be necessary to add some more script lines to both scripts to enable the necessary mutual recognition.

I think a better effect is obtained by reacting to the listen event; with llGetAgentInfo you'll trigger the flashing while you're typing, correcting, changing your mind, answering your phone and then retyping. Also, in reacting to the listen, you can modulate the flash rate depending on something like the length of the words. As Christmas is on the horizon, here's a very crude and basic script that does that: float letter_time = 0.02; float space_time = 0.1; default { state_entry () { llListen (PUBLIC_CHANNEL, "", llGetOwner (), ""); } listen (integer channel, string name, key id, string message) { list words = llParseString2List (message, [" "], []); integer count = llGetListLength (words); integer counter; do { llSetLinkPrimitiveParamsFast (LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, TRUE]); llSleep ((float) llStringLength (llList2String (words, counter)) * letter_time); llSetLinkPrimitiveParamsFast (LINK_THIS, [PRIM_FULLBRIGHT, ALL_SIDES, FALSE]); llSleep (space_time); } while (++counter < count); } }

In the sensor event you could use a loop to populate the list with several copies of your own UUID, or just append the sensor result to itself a couple of times.

When you want to put several statements, as in the touch start event in the second script, into one part of an if statement you need to enclose them in braces, {}, unlike in the first script where there's only a single statement. integer gListener; default { touch_start(integer total_number) { if (llDetectedGroup(0) ) //same as llSameGroup(llDetectedKey(0) ) (with llSameGroup, detected must be in the sim) { // See 'discussion' page for more comments on choosing a channel and possible left-open listener integer channel = -13572468; // "" saves byte-code over NULL_KEY gListener = llListen( channel, "", "", ""); llTextBox(llDetectedKey(0), "Some info text for the top of the window...", channel); } else llSay(0, "Wrong active group!"); } listen(integer channel, string name, key id, string message) { llListenRemove(gListener); llSay(0, "You wrote: " + message); } }

Maybe top menu/Advanced/Rendering types/Water (Ctrl+Alt+Shift+7).

This could also be a projector mirror. Inara Pey's instructions on making one yourself: https://modemworld.me/2018/05/12/projectors-as-mirrors-in-second-life/.

Extending steeljane's option 1, above, if the hair is mod you can also try changing that to use alpha masking. If you can use alpha masking you'll probably need to play with the cutoff level to get something useable. Looking at that hair, though, the fine detail will likely suffer considerably.

There are specific limitations as to where and upon what llPushObject is effective: https://wiki.secondlife.com/wiki/LlPushObject#Caveats. The llDetected* functions only work in events where there is something to detect, like touch* or collision*, etc. In these events the parameter is an integer telling you how many items were detected. You must then loop (for example) llDetectedKey(n) with the values of n running from 0 to the parameter - 1 (indexes rather than ordinals). Perhaps you could have the script make a list of the keys of the components of the object when it's rezzed and at explosion time loop through that list applying a push to each individual severed part. (I think unlinked objects keep the same key they had when they were part of a linkset.) Perhaps you could have an invisible object suddenly increase it's size at explosion time, pushing all the individual components away.

If you use Firestorm you can play with particles directly. Rez an object, edit it, and select Object/Edit particles from the build menu. You can copy and paste the settings you've used or create a script in the object itself.

Is there, perhaps, a copy of the original script lurking in any of the other linked objects?

I did try that script in the root prim of three linked cubes and the child prims showed what seemed to be the correct flapping behaviour with the flapping turned on and off by clicking any of the prims. This should work if you have your transparent root prim containing the script and the two wings linked to it as child prims. When you link objects it's the last object selected that becomes the root, so select the two wings first and then the transparent one, in that order, before linking them. Linking other items will upset the script because doing so messes with the link numbers, and it's link numbers 2 and 3 that it assumes are the wings. (Also, the order in which you select the wings for linking will determine their link numbers and hence the direction in which they move when flapping.)

Here's a modified script that might do the job: float counter; integer stage = 0; integer flapping; //not flapping/flapping flag (keeps track of whether the wings are flapping) float wing_speed = 0.1; float degrees_per_increment = 2; default { state_entry() { llSetLinkPrimitiveParamsFast(2,[PRIM_ROT_LOCAL,llEuler2Rot(<180.0,0.0,0>*DEG_TO_RAD),PRIM_LINK_TARGET,3,PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,0>*DEG_TO_RAD)]); //llSetTimerEvent(wing_speed); //don't start the timer until there's been a click } touch_start (integer count) //there's been a click { if (flapping) //are the wings flapping? { llSetTimerEvent (0.0); //stop the timer (where the flapping movements are done) flapping = FALSE; //reset the flag llSetLinkPrimitiveParamsFast(2,[PRIM_ROT_LOCAL,llEuler2Rot(<180.0,0.0,0>*DEG_TO_RAD),PRIM_LINK_TARGET,3,PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,0>*DEG_TO_RAD)]); //park the wings in their non-flapping position counter = 0.0; //reset the counter (wich keeps track of where in the flap the wings are) } else //no, the wings aren't flapping: { llSetTimerEvent (wing_speed); //start the timer flapping = TRUE; //set the flag } } attach(key id) { if(id) { llResetScript(); } } timer() { if(stage == 0) { counter += degrees_per_increment; if(counter >= 20) { stage = 1; } } else if(stage == 1) { counter -= degrees_per_increment; if(counter <= 0) { stage = 0; } } llSetLinkPrimitiveParamsFast(2,[PRIM_ROT_LOCAL,llEuler2Rot(<180.0,0.0,counter>*DEG_TO_RAD),PRIM_LINK_TARGET,3,PRIM_ROT_LOCAL,llEuler2Rot(<0.0,0.0,counter>*DEG_TO_RAD)]); } }

I've long wished for something like llUnsitTarget().