KT Kingsley

I can't get the video to play for me, so apologies if this has already been covered. The question should be, "Is it possible to simulate a universe?" If the answer to that question is no, then no, our universe cannot be a simulation. If the answer is yes, then yes, our universe is almost certainly a simulation: it'll be possible to create numerous such simulations, and within those simulations it'll be possible to create even more. Thus the number of simulations will vastly exceed the number of "real" universes. The odds of us living in a "real" universe would be vanishingly small. I do think, however, the more accessible/interesting/relevant/immediate question is, "Is the universe digital?", whether it's "real" or just a simulation.

You only have to put detail into the observed parts of the universe. All the rest can be LODded or potential, and procedurally generated as required.

This has been seen, JIRAed, investigated, and rolling restarts have been scheduled for the release candidate channels. See this thread:

Three minutes!

It works fine for me. Two suggestions: maybe the "Running" box at the bottom left of the script editor window got unchecked, or maybe you're on script-disabled land.

I've copied the whole script, with my suggestion bolded and in place, and with the original lines commented and crossed out. //Drop this script into an object with up to 22 textures inside. //When anyone Touches they will get a menu with all the textures available. Button names in menu will be first 10 characters from that item's name. //NOTE: Texture Names may not exceed 24 characters or script error and menu fails. integer side = ALL_SIDES; //ALL_SIDES or any face number 0 through 5 list texture_list; list texture_list2; key user = NULL_KEY; composelist() { integer currenttexture = 0; integer totaltextures = llGetInventoryNumber(INVENTORY_TEXTURE); if(totaltextures > 0 & totaltextures <= 12) { texture_list = []; do { texture_list = texture_list + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture > 0 & currenttexture < totaltextures); } if(totaltextures > 12 & totaltextures <= 22) { texture_list = ["Next Page"]; do { texture_list = texture_list + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture > 0 & currenttexture < 11); texture_list2 = ["Last Page"]; do { texture_list2 = texture_list2 + llGetInventoryName(INVENTORY_TEXTURE, currenttexture); currenttexture++; } while (currenttexture >= 11 & currenttexture < totaltextures); } if(totaltextures > 22) { llWhisper(0, "You may only have a maximimum of 22 Textures. Please remove any extra ones."); } if(totaltextures == 0) { llWhisper(0, "Please add up to 22 Textures inside this object."); } } //The Menu integer menu_handler; integer menu_channel; menu(key user,string title,list texture_list) { menu_channel = (integer)(llFrand(99999.0) * -1); //random channel menu_handler = llListen(menu_channel,"","",""); llDialog(user,title,texture_list,menu_channel); llSetTimerEvent(30.0); //menu channel open for 30 seconds } default { state_entry() { composelist(); //make list from inventory textures } touch_start(integer total_number) { //if (llDetectedKey(0) == llGetOwner()) // user = llDetectedKey(0); // menu(user,"nnPlease select one below.",texture_list); if (llDetectedKey (0) == llGetOwner ()) { user = llDetectedKey (0); menu (user, "\nPlease select one below.", texture_list); } } listen(integer channel,string name,key id,string message) { if (channel == menu_channel) { llSetTimerEvent(0.0); llListenRemove(menu_handler); if(message == "Next Page") { menu(user,"nnPlease select one below.",texture_list2); } else if(message == "Last Page") { menu(user,"nnPlease select one below.",texture_list); } else { llSetTexture(message, side); } } } timer() //Close the Menu Listen or we'll get laggy { llSetTimerEvent(0.0); llListenRemove(menu_handler); } changed(integer change) { if (change & CHANGED_INVENTORY) //inventory has changed { llSleep(0.5); composelist(); //rebuild the list } } }

You left out the braces, "{}", around the code that should be executed only when the if statement is true. As it stands, only the user = llDetectedKey (0); statement is conditional. You want if (llDetectedKey (0) == llGetOwner ()) { user = llDetectedKey (0); menu (user, "\nPlease select one below.", texture_list); }

Are the four lists the same length? If so, you could concatenate them and add list number * individual list length to the index when accessing the items: // four lists of three items each, concatenated list my_list = [ "A", "B", "C", // list 0 "D", "E", "F", // list 1 "G", "H", "I", // list 2 "J", "K", "L" // list 3 ]; integer individual_list_length = 3; default { state_entry () { integer list_number = 1; // the list numbers run from 0 to 3 integer list_item = 2; // the items in each list are indexed 0 to 2 string item = llList2String (my_list, (list_number * individual_list_length) + list_item); // 1 * 3 + 2 = 5 llOwnerSay (item); // "F" } }

Regarding llSitTarget, that's only applied when an avatar sits down on the object. Any changes made using llSitTarget won't be applied until the avatar stands and then sits down again. The llSitTarget wiki page includes Strife Onizuka's UpdateSitTarget function, which changes the sit target and moves the avatar using llSetLinkPrimitiveParamsFast to reflect the changed sit target.

Also, somewhere in the FURWARE package (maybe on one of its wiki pages), is a utility (I seem to remember a link to a download) that lets you create display fonts from TrueType fonts.

In the link the article is dated December 16 2015. Any current viewer you upload will be Bento compliant. You'd have to dig pretty deep to find an ancient viewer version that isn't.

So far it's only been bugs my own RLV scripts that have left me in a mess with no choice but to bail out.

Well, I did what I should have done in the first place, and got on to Live Chat, who waved their magic fixing wand, and fixed it.

Thae a look here https://wiki.firestormviewer.org/fs_nearby_chat_torn_off and/or here https://wiki.firestormviewer.org/fs_contacts_torn_off. Also, you can find your friends and groups in the People window, Ctrl+Shift+A, and from the Comm menu in the top menu bar.

To me, this suggests that the sim will recognise the text-only viewer and not waste it's time fetching and sending graphics data that'll only get ignored.

Rider Linden has documented the EEP script functions in this forum thread, and they're also in the wiki: The llSet/ReplaceAgentEnvironment functions require the targeted agent to be in the experience the script was compiled with. I'm not aware of a script method to set an environment for a parcel or region.

I guess because there's "recreational" and "functional" or "utilitarian" RLV, and "lifestyle" RLV usage. Nearly all my RLV usage is of the "utilitarian" type, but I do usually keep an open RLV relay going in the vain hope that someone, somewhere, will, one day, try something unexpected and entertaining on me. But... there's plenty of RLV restrictions that seem to me would only appeal to the type of RLV user who might only be described, politely, as an arsehole. So... my self-written relay script includes white/grey/black lists of RLV commands (because relogging in a non-RLV viewer, to get out of a mess... ok, so the mess is usually caused by me mis-scripting something... is a pain) – (and based on a "sounds like", wildcard – "*" – matching function, which I'm smug enough to be rather pleased with, but nowhere near confident enough about to post publicly and suffer the consequential ripping to shreds).

I've had the vague impression that the RLV relay protocol specifies the return of either the string "ok" for when an RLV command has been accepted and implemented, or "ko" (knocked out?) when it hasn't. And there's also the base assumption – for any IT-related situation – that if you don't get a response, it hasn't happened.

Whenever I login I see about 10% of my inventory is being "fetched". That is, somewhere around a start of 10,000 or 5,000 of the items in my 80,000 item inventory. Ok, it generally takes less than five minutes, but I don't think it should happen at all. If I log in and allow my inventory to populate fully and then immediately relog to the same location my inventory is full form the start. Usually. If I log out somewhere and relog back at a different location my inventory needs to re-fetch items. (This situation usually only arises when I crash away from where I logged in initially, and relogging to my last location takes me back to where I logged in initially before the crash.) If I logout and later log back in to a location other than that to which I initially logged in to, I go through the inventory fetching routine again. Can anyone explain what's happening? Can anyone suggest what I might do to make this go away?

Quite easy to test: https://en.wikipedia.org/wiki/Eratosthenes#Measurement_of_the_Earth's_circumference. Which brings to mind a potential derail question, which are the easternmost and westernmost (and, for that matter, northern- and southernmost) mainland regions in SL?

Could be any number of reasons. Try the steps here https://wiki.firestormviewer.org/fs_camera to fix it.

Don't forget that that when your draw distance lets you see into adjoining regions you're also impacting the simulators running those regions as they then have to feed you the data about what there is there for you to see. (That's the "child agent" thing you'll see if you look in the statistics window.) Having said that, I generally run with a 512m draw distance because a) my computer can, while maintaining a decent frame rate, and b) because I like sailing, and I like to see my surroundings (sailing in a void is kind of pointless), and I prefer to see oncoming maniacs in their speedboats in plenty of time to avoid colliding with them (given that they'll have their draw distances turned down so low, and their speed cranked up so high that they won't see anything in front of them until they have about 0.035 seconds to react).

I'm not sure where I saw the (nostrip) thing first, but if I call a HUD something like "My HUD (nostrip)" it doesn't get detached when I change outfit using RLV. That's really all there is to it. https://wiki.catznip.com/index.php/Nostrip ETA: I guess this feature might be exclusive to RLVa, which is what you get in RLV viewers other than the actual RLV viewer?

I also see that behaviour with HUDs and @detach=n, though not with non-HUD attachments. One way around it is to use "(nostrip)" as part of the object's name and not use the @detach=n command. I understand that using "(nostrip)" in the name of a folder will protect its contents, though I've not tested the details of this. (For example, I wonder if just making a random RLV folder, calling it "(nostrip)" and throwing links to stuff into it will work.) ETA: No, it looks like an item has to be attached using a command that directly references a (nostrip) folder (or, presumably, though I can't be arsed to check, a folder containing a "(nostrip)" sub-folder) for this to work.

If I remember correctly, JSON data is stored as a string, so you could try something like using llSubStringIndex to find what you want and then tracking back to the brace that precedes it and the parent key that precedes that. There's also llJson2List, so could use that to recurse through the JSON data, and test the resulting lists for your target.