✨ Feature Requests

The inventory window offers a simple option for filtering by date range (days) but does not display a date when an object was added or purchased. It would help if a timestamp was shown that indicates the appearance/creation (e.g. folder) in the inventory. Perhaps this column could also be made sortable (ascending / descending sorting). Similar to file browsers of operating systems.

Inventory sorting is an annoying but universal chore for any resident who wants to stay organized. When thinking about how I avoid the same issues in other file management systems, one of the biggest boons to keeping on top of data organization is being able to choose the location an incoming item is saved to. Imagine that, when an unpacker HUD sent you a folder, instead of simply hitting "accept", you had a new menu that let you select which folder it unpacked to. Right now, all new folders simply go into "Inventory", but what if you could tell it to put that folder into "Objects->Home->Furniture and Decor->Chairs and Sofas"? Your item would immediately be sorted directly into the place it belongs so you could find it later. You could then have that folder appear in a "recent places" list for easy access the next time you needed to unpack a similar item. Maybe you could also pin favorite folders, for instance "Body Parts->Cosmetics" could be pinned if you know you buy a lot of makeup layers and unpack to that location often. This could also be used to help creators keep their items more organized when working on new projects, as the same menu could be used for bulk, material, and mesh uploads. Being able to see "recent folders" and select your project folder would help immensely with keeping product related files together. This should be an option that could be toggled, either in the "accept/decline" or upload menu, or in inventory settings. Some people won't want to be pestered each time they acquire something new, but I know it would certainly help me, and many others as a major quality of life improvement.

Objects should be returned to inventory or at worst lost & found. At the moment the object is lost from inventory entirely after the rez attempt

Would really love additional Outfit folders - which could have the suffix renamable so we can separate our outfits into bodies, or themes, such as Halloween, rather than having hundreds and hundreds in one big folder. Would also be great to be able to click on the thumbnail pic and get a larger image.

Reinstate creation of sub-folders in Outfits. This was allowed until fairly recently. People end up with a large number of outfits in a single list and cannot classify them by type, color etc.

As we know, we have had the ability to link together multiple prims, mesh objects. I would like to see an expansion of this fuction but with BOM layers, specifically, with tattoo layers and or same type bom layer (except for those limited by 1). ✦ Why of this? Sometimes, it's just tired to look up for a layer and go wear layer by layer to make a precise preset, I firm believe that this will help to have a more optimization organization of the tattoo layers that we wear, for example: I got X product which its a makeup up kit, it contains Eyebags, Blush, Lip Gloss, etc. I have already wear and tint the only layers that I wanted to wear, my "ideal combo". ✦ How it could works? From the inventory or even the apearance tab, I select all the layers that I want to turn into one with the "combine layers" button. Then, a new window appears as if I were going to create a new tattoo, this could be a new type of layer even, same proccess, to name it. Maybe there can be also a confirmation of all the layers that I have selected to be sure that everything is all correct. ✦ Notes and limits Information extracted from Second Life Wiki Link and Limits • Due to limits, you can only link up to 256 prims > Not sure how many layers could be able to combine. • In addition to having the same owner, each of the prims must have modify permissions as well as compatible copy-transfer permissions > Obviously owner only can, and only layers with modify permissions. • Max. # of clothing layers - 60 (I believe is 62 now?) including alpha, tattoo, shoe base, physics, socks, gloves, undershirt, underpants, shirt, pants, jacket, skirt > The weight of the new combine layer should be the same for all the layers it contains, respecting the standard and limit of layers to wear.

Sometimes (and sometimes often) you want the user to create a structure of folders and sub folders when opening a product box. This feature request describes how it can be realized. First when opening a box there will be additional option "open all" in the context menu which triggers this feature. Second to create a proper folder structure, the creator must prepare the product box for this, by following the rules how the servers will unpack the product box: The product box is a link set where each prim holds the content that will be in a certain folder. The content of the root prim is unpacked into a new folder with the same name. The description of the root prim is ignored. This new folder is the root folder of the unpacked structure. If a child prim has no content or no name or no description (or the standard "no description" as description) it is ignored in the process. When a child prim has content, a new sub-folder with the same name is created and receives the content of the child prim. The name of the sub-folder is the name of the child prim. The description of the child prim names the parent folder of the created sub-folder. When there is no folder with this name, the sub-folder is created inside the root folder. When there are more then one folder with this name, any of them is used. Alternatively when multiple child prims have the same name and the same description, their content can be merged into one sub-folder. For example we want unpack into such a folder structure: 📁 Teleporter System 📁 applications 📁 walcable 📁 sitable 📁 touchable 📁 examples 📁 misc To do so we create a set of 7 prims (each with content): The root prim will have the name "Teleporter System" and any description. The child prims "applications", "examples", "misc" will have "root" or "~" as description (any name not listed here) to place the folders inside the root. The child prims "walcable", "sitable" and "touchable" will have "applications" as description to place their folders inside this folder. Done. Now the server will be able to unpack the whole folder structure. Additionally it will be also great to have a way for scripts to unpack into a folder structure. For this there could be a new command llUnpackLinkset(key target, string name, integer options) which will (if the recipient accepted) give the folder structure as if they opened the product box in the way above. Target is the recipient to receive the content, name is used to give the root folder a different name. Options would control if no-copy items should be included in the given content and if the script itself should be excluded. The function would, like llGiveInventoryList give the content only if the target is present. But unlike this function also be able to give no-copy items in folders. Edit: Also it can be useful sometimes to create empty folders in the process. To achieve this, we can use unsaved notecards (which having the null asset key) as the only folder content, the notecards will be not given but folders created.

I've a large amount of content that I'd like to have access to on my alt. Things like clothes, like vehicles and the sort. Having to rebuy these items can be costly, especially if I like to create different accounts for personas and the sort. We could solve this by allowing users to designate up to two (given the current 3 accounts/user restriction if memory serves) accounts to have access to a 'master' inventory, much like how the SL Library is accessible. That being said, I can hear the lamentations of creators and the sort already, though let me posit this: To which percent of your sales are from people making alts? I doubt it's very many. And as for the legal and other concerns, I posit this: require residents report alts to Linden Lab, and make that a pre-requisite for being able to share inventory, along with having to agree that this service is for only the use of one legal person, and providing access to inventory to another person can be grounds for both accounts to be banned. I'm even for the idea of making this a premium feature. Furthermore, I'd suggest that 2FA be a prerequisite for alts accessing inventory unless access is in a NC/NM/NT configuration on 'guests'.

With massive inventories in the >> 80k items range, especially for older residents, there are a lot of folders that are basically stuff a resident does not use frequently. Stuff you would move to the attic in RL. This slows down searching and finding items and causes UX issues when the inventory UI slows to crawl or search is super slow. Examples include pristine copies of items only kept as backup in case the active item breaks down. Legacy stuff that fell out of fashion, but is too good to simply delete. Tons of other things. It would be useful to mark such folders with some "attic" or "archived" category to get them out of the way. Those items should not show up in the default inventory list, should not be found by the default search and should be treated as basically non existant unless explicitly requested. They should not be wearable or attacheable in that state. Those attic / archived items should be de-prioritized for inventory loading. The inventory could be considered fully loaded for all important purposes even with all archived items still missing. This would speed up initial avatar loading in some cases. The items should also not simply be display filtered but put in an entirely different structure (maybe extra tab in the UI) to have performance gains in search and browsing. A bit like those infinite chests in games, where all the loot gets put thats not useful but still worthy of keeping.

Having a clean, sorted and searchable inventory is key when you have been a resident for a while. And the inability to change names (or even create aliases and change THEIR name) makes that quite difficult. It would be very helpful if even NO MOD items could allow for changing the name of them, while retaining every other aspect and property as unmodifiable.