KT Kingsley

Thanks. Not either of the first two, but Edge worked fine where Chrome failed.

Trying to download the latest Firestorm I'm finding access to the Firestorm website is blocked by this: www.firestormviewer.org Checking if the site connection is secure Verify you are human www.firestormviewer.org needs to review the security of your connection before proceeding. Checking the verify checkbox appears to reload this same page. Any suggestions as to what's happening here?

I have a vague memory of something called "Key Experience", which is, I think, an estate level setting that requires visitors to a region to belong to a particular experience or be denied entry. I've not used it myself.

It's in the most indented items under the "buttons limits" heading:

The LSL wiki page for llDialog includes a code snippet that'll trim strings including multi-byte characters to 24 bytes.

Also, you could use the changed event and CHANGED_TEXTURE to trigger the report.

Any code in the attach event that isn't executed before being derezzed gets executed when the object is next rezzed, and before the attach event is is triggered for the reattachment.

For what it's worth, the braces issue has been fixed in the latest Friestorm.

I think auto-unindentation stops working following a line of text that wraps-around.

In the Firestorm viewer (I don't know about others) there's a Copy Keys button near the bottom of the General tab of the build window which seems to work even for other people's no modify objects.

Also:

I think the RLV command @attachover will work here.

Also, Ctrl+click for adding or removing single items (which includes whole folders and their sub-folder) to or from a selection.

You could try "preloading" the images by placing them on some object faces in the vicinity of the main display, so that they're already loaded into viewer cache before they're projected, and you could try setting the transparency of those faces to 100%, or colouring them black, so that they're not too intrusive.

The script function to deliver a text box to an avatar (any avatar in the same region) will work from any rezzed object, whether it's rezzed on the ground or attached to an avatar (either the avatar being targeted or by a completely different one – even an avatar completely unaware of it's presence). It could be triggered by almost any event (a sensor response, a collision, an avatar attaching the object containing the script; there are many other possibilities). For more detail see the LSL wiki for llTextBox here: https://wiki.secondlife.com/wiki/LlTextBox

A long time I was given a completely unscripted physical clock when I came across its builder in a sandbox. It usually seems to run for a few minutes before something breaks it.

You can circumvent autoreturn by carrying a passenger - perhaps an alt running on a second instance of your viewer.

Unless I'm completely misunderstanding your question, I think the answer is to initiate the dialog after the data from the text box has been received. integer text_box_channel = 1; integer dialog_channel = 2; state_entry () { llListen (text_box_channel, "", "", ""); llListen (dialog_channel, "", "", ""); } touch_start (integer count) { llTextBox (llDetectedKey (0), "text", text_box_channel); } listen (integer channel, string name, key id, string message) //the id parameter is that of the avatar using the text box or dialog { if (channel == text_box_channel) { //do text box stuff llDialog (id, "test", ["button1", ...], dialog_channel); //use the id parameter to target the dialog at the avatar that used the text box } else if (channel == dialog_channel) { //do dialog stuff } }

The SL help page: I want to reactivate my account.

Assuming you're using the attach event to detect when the item is attached, you can also use it to detect when it's detached: in this case the key id parameter is NULL_KEY, as opposed to the key of the avatar to which it is attaching to. A couple of lines of code will be (fairly reliably) executed when the item is detached. Note that any code not executed will be then be executed when the item is reattached before the attach event is triggered again.

Use the id data from the touch event (click) only to initiate the text box. In the listen event that handles the data sent from the text box, you get both a key id value and a string message value. These should make clear which user sent which message.

Just a quick glance at the code here (so I'm likely way off line) but this bit isn't usual: integer index = (~llListFindList( USERS, [llDetectedName(0)])); if(index != -1){ONLIST = TRUE;llOwnerSay("user onlist = TRUE");} If the variable index is assigned the return from ~llListFindList it will never equal -1 because ~(-1) is 0. Try integer index = (llListFindList( USERS, [llDetectedName(0)])); if(~index){ONLIST = TRUE;llOwnerSay("user onlist = TRUE");} In the quoted wiki example the value of ~llListFindList is not saved. It is usual here to save the returned index from llListFindList, and then test (~index) and if that's non-zero to use the value of index in any further operations. Hope this doesn't further muddy the waters if I've got it completely wrong.

SLAM (incorporating the double slash motif) is a content brand in SL, with both in-world and marketplace stores. A quick look, however, didn't find the "phone" keyword among its products.

https://status.secondlifegrid.net/ Investigating - We are receiving reports that scripts are malfunctioning for regions found on RC Server channels. Our engineers are investigating this issue further. We apologize for any inconvenience. Please follow this blog for updates. Feb 01, 2023 - 09:07 PST Update - We will be rolling RC regions back to their previous version. Regions that have already been restarted for today's rolling restarts will be restarted again. We apologize for any inconvenience, and thank you for your patience. Please follow this blog for updates. Feb 01, 2023 - 09:19 PST

You'll have to call llSetColor four times, once for each individual face. You could also consider using llSetLinkPrimitiveParamsFast, where this can be done with a single function call (albeit with quite a few items in the list parameter). (Or call llSetColor once for ALL_SIDES, and then twice more to change the front and back faces to what they ought to be.)