✨ Feature Requests

With the shiny new PBR materials and Linden Lab's ongoing indifference to anyone actually trying to enjoy the Mainland, how about this radical idea: only load the parcel I'm standing on, instead of every single bordering parcel at once. This should be an option and it is super simple to implement into your ancient un-optimized code. Yes, I know draw distance exists, but it clearly isn't solving the problem of your engine rendering the entire neighborhood's junk while I’m just trying to stand still without my FPS tanking. LL, for once, try pretending you actually care about the existing user experience instead of just cranking out more generic prefab houses to bait people into P+. MAINLANDERS ALREADY PAY FOR A MEMBERSHIP PLUS A RIDICULOUSLY HIGH TIER. I'm on a 500mbps connection and have a mid-range gaming PC and still lags out on a low draw distance. o.O Newsflash: not everyone wants one of your little cookie-cutter McMansions that sucks all creativity out the window nor do we want to pay to have 5fps which turns SL into a slide show. Second Life was supposed to be about creativity, right? Yet your low-prim, boring, zero-personality starter homes offer all the creative freedom of a Soviet-era apartment block. Brilliant strategy. Let's show some love to the tens of thousands of us who own mainland parcels, all of whom are paying members. Provide a quality experience and people will stop leaving!! Mainland is in severe decline, as seen by the plummeting prices and quantity of abandoned parcels and parcels for sale. Fault lays on LL for ignoring the mainland. End the mainland or fix the issues.

basically a webhook for script errors -- Nexii Malthus, summarizing what we need You develop scripts for Secondlife. You start hearing people reporting that your scripts are crashing. Now what? Unless it's a very reliable crash, you're kind of in unexplored territory. SL is vast, many unique and hard-to-reproduce situations could be happening. The crash log is seen by your end user, not by you. The developer cannot know how widespread the problem is, whether it's a bug in a SL Server update, whether it's an edge case in their own programming... Possibly avenue to a solution: An unmodified, compiled script has consistent bytecode, and if I understand it right, an internal asset id corresponding. The simulator knows when this item has crashed (and currently only generates a message to the owner on a message channel). Perhaps a developer could "flag" scripts for logging "that script", or the set of scripts for a project that is in the wild and reporting problems. The developer could view (on the web? in the viewer?) a simple log, aggregating the crash reports from the currently-logged scripts, grid-wide for each flagged script. Perhaps some bit of information like the simulator version/memory use/event queue at time of crash. The simulator knows all sorts of things about what happened; Any log improves the current total black-box situation. Eg, "hearing that scripts are crashing on region restart? start logging now and see what comes in". This would be a limited utility. The number of scripts we can flag and limit how many log entries each script holds would be small. This would not be a performance monitoring tool; it would be turned on when a problem is suspected, to capture what's happening "out there." Acknowledged implications: Plenty of privacy concerns abound. To avoid adding new means of tracking users, gaining access to personalized data etc: The developer should not be able to find out what specific region the script was in when it crashed The developer should not be able to view the script's memory The developer should not be able to view who was running the script Might be useful: What type of crash list of events queued simulator version number region status Anything else that could be useful without opening bad implications? Any other implications that need calling out?

Need quicker home page upload. It can take approximately 2 or more minutes for the page to load. Also, 30 seconds to 1 minute for touched icons to respond.

Lots of time is spent by Residents customising their SL Viewer settings, getting the viewer to look or perform as they want it, or need it. But there is also a fear and annoyance of having to reinstall a clean viewer, or an updated version of their SL Viewer, where sometimes all those special custom settings have been reset to factory settings and have been lost forever. As well as SL Viewer not having a "Save Settings" feature, it also doesn't have a "Load Settings" feature either, meaning a Resident has to needlessly waste time manually reinstating settings that were lost. I request that SL Viewer be given a "Save Settings" and "Load Settings" feature in the Preferences, which would save (and load) a file of SL Viewer settings on the Residents device. Firestorm and other viewers already have this Save/Load Settings feature and deserves to become part of the official SL Viewer too.

Some creators seem to be under the impression that even the smallest items need lots of 2k textures now that those are available (e.g. small jewelry items). It would be good if the viewer (and potentially the marketplace) contained some sort of tool similar to rendering cost that displayed data about the textures an item uses and put them in some kind of relation to the size of the item. Maybe also show the number of pixels the item actually uses on screen and what the maximum texture size is that mathematically even makes a difference at that size. Other ideas in this context would also include the overall texture impact of a build or the surroundings within draw distance, e.g. how many unique textures there are of each size within range, this might help optimize some stores that use too many high resolution textures in close proximity, overwhelming VRAM for people who don't have that much.

The fastest way to improve FPS is to reduce Display Distance. On older computers, this can be an immeasureable help. Firestorm allows both 48 and 32.

App will freeze every time i log in and i have no way of logging out to try again so get the circle of doom until after a few minutes it decides to kick in. so i have no idea if it is logging in or logged out and it is frustrating. so much for updates being faster and better.

Feature request to return you to your previous location if teleport fails. How frustrating it is when your teleport fails and then you get kicked out of the game. Do you guys even play your own game? This has been an issue since as long as I can remember.

On the region DRAGONMYST we have been regularly getting the following notice for more than a month. Resetting the region fixes if for a day or two, then it pops right back up again: We are sorry, Linden Lab has discovered degraded performance on your connection to the region you are on. You will need to restart Second Life and log into a new region for the next 30 minutes to an hour. We apologize for the inconvenience. When I get this notice my avatar is experiencing extremely limited functionality. As instructed, I am forced to relog to another region to correct the issue. Returning to DragonMyst does not correct the problem; the region has to be reset.

Hi, I would like to propose two ideas for improving the Texture Fast Cache system. The first is a simpler design while the second is a little more elaborate. Existing System The Texture Fast Cache currently works by saving a 16x16 or less texture to a 16x16 buffer along with a header information on the source texture information. IE Width Height #of Components (RGB=3, RGBA=4) Discard Level of the scaled down image This is stored in a fixed 1,028 buffer. It then writes raw image data to the entry, this is triggered when a new texture is being loaded after the first time it was loaded as part of the texture fetch system. The Fast Cache has a fixed size of 1024x1024 entries, but the Fast Cache file starts as an empty file and will keep expanding by appending to the existing file the new entry data. The data is read back when an existing texture is being loaded after either first login and load from a region, or after a region unloads and the textures are purged from memory and requested again from cache. The system goes through the process of creating a brand new texture to use for the 16x16 texture, then loads the actual target texture at the desired discard level. The file has various locks that protect the file. Proposal #1 I propose that we make the file a fixed size, pre-allocate the entire 1024x1024 entries and write out a zeroed out file to disk. Now there are two options I propose to give to the user. Disk Based (Memory Map) Texture Fast Cache Create a memory map file pointer to the file and directly assign the file pointer data to the actual LLRawImage so that you don't have to load in the data you can assign the texture data directly to the RawImage and not need to allocate or de-allocate the memory. This would save on some disk IO as well, reduce the amount of RAM being used and data being copied to load the 16x16 raw image. Writes to the file can be done directly by mapping the next entry to the next fixed pointer and writing the data to memory. The underlying system will handle writing the memory to the file system. The file size would be a little more then 1 GB on disk. Memory Based Texture Fast Cache Load the entire fast cache file into memory and give direct access to the fixed size data. There can be either a process that over a set period of time writes the data to the fastcache file, or after so may updates writes to the file. This would bypass the disk IO and virtual memory to disk writes in the background, but comes at the cost of system RAM being used to keep the fast cache in RAM. This would reduce latency of the Fast Cache. It would take up around 1 GB of system memory as well as 1GB of disk space. Choice 1 would require an updated LLAPR file which supports Memory Maps (already submitted as a PR) and possibly 64 BIT files. Proposal #2 This would be similar to proposal #1, where you have a memory mapped version and an memory based version. But in this case, I propose that instead of write a throw away 16x16 image that has to go through the same initialization process as the actual texture it needs to load, that we save the MAX_DISCARD_LEVEL texture to a a Fast Cache Body file and store the header for the fast cache in a Fast Cache Header file. The header would still store the same information, but in addition, it would store an offset into the Fast Cache Body to load the texture data. This way, the lowest tier of texture cache would be in ready to read format, and could be memory mapped upon creating of the LLRawImage and save on memory copies and decoding of the JPG2000 data as well as having the needed information for the texture already to go. This would also prevent VRAM fragmentation as we are not allocating and de-allocating 16x16 images all the time. The memory version of the same design would have 2 allocated buffers, the larger fixed size from the Fast Cache that is read from disk and a second where the data is stored in a vector that can grow over time, where once the system logs out, it will commit the Vector data to the Texture Fast Cache body data and header as well. This is partly due to the fact that each texture may have different MAX_DISCARD_LEVEL dimensions. Some textures are at Discard = 0 2Kx2K would need a 64x64 pixel body entry size, 1Kx1K would need 32x32, and 512x512 and lower would be 16x16 image. So the mixing of the sizes would need an offset stored in the header to do the calculation. One thing that could be done is have different fast cache files per MAX_DISCARD_LEVEL texture size IE 64x64, 32x32 and 16x16 image and store those in 3 different body's that can be referenced with the same header. Another option, would be to have a fixed 64x64 pixel entry size. The head would use 64x64 offset for the entry. fixed size for the entries,but some entries could be grouped together to make a Atlas like image so better utilize the space.