✨ Feature Requests

Note: I know this was suggested before and it's tracked. I know this will be merged. That's okay, I wanted to give more suggestions on implementation and answer "why" beyond that it would just be a nice feature. Problem: You don't want to see stuff made by a certain creator on the marketplace. There may be a variety of reasons for this. Here are a few examples. You have the shop owner in game block due to harassment, drama, or other personal reasons and don't want to accidentally give this person money. The vendor is selling rips. The seller has a business model you don't want to support. Maybe you don't want to buy clothes that are no mod, maybe they have shady business practices that involve over-editing their ads, or using AI on their ads resulting in false advertising. Maybe the seller's content makes you deeply uncomfortable such as selling adult products but the models scream childlike and you don't want to see that. The seller is flooding the marketplace with thousands of generative AI textures to make a quick buck, making it impossible to find high quality textures. This is a growing problem that needs urgent addressing. Solution: Allow us to block the shop and/or the owner of the shop. Owner might be better in case the marketplace someday expands to let a single user have more than one storefront. Or both. Blocking a particular product may also have its place. Implementation: Beneath the flag listing link there would be additional links: Block this shop Behavior: Browsing and searching omits all products from the store. Adds shop to a block list. They can be removed from block list if needed. Block this seller (<--- Alternative, or TBI if multiple storefronts ever becomes a thing.) Behavior: Browsing and searching omit all products from any and all products from the store. A popup that asks, "Do you want to block this person from your shop as well?" may be a good move in some circumstances. They can be removed from block list if needed. Hide Product Behavior: Omits an individual product from search and browsing. Unhide Product Behavior: Removes product from hide. How would you find a listing if it was hidden? Give people a checkbook to show hidden products in search and browse. By giving us the tools to better curate our experience with the marketplace you will empower users to find what they want without having to wade through things they don't want to see, increasing the likelihood of them spending money instead of getting frustrated and giving up on the search.

It would be nice to know exactly how long an already finished and completed object has been rezzed inworld for. "Rezzed Since" would be different to "Creation Date", as "Creation Date" only records the time and date of when a brand new prim or mesh was created. "Rezzed Since" would only apply to an already completed and finished thing rezzed out from an inventory. It would be a valuable tool in learning how long an item has been rezzed (or lost!) inworld for, as well as listing who it's last owner was. It should list the rez time, rez date and the name of the owner of the item. Understandibly, this feature would only work with objects rezzed after the feature was introduced to SL, as objects older than the feature could not be known ("Rez Date Unknown"?). Or is there a solution to this?

Some kind of cloth simulation would be great, I think everyone agrees on that. Except that it's computationally very expensive, and while it's practical in a game where you've only got one main character and care can be taken to avoid much simulation happening at any one time, SL needs to render up to a hundred (sometimes more) "main characters" at a time. There's already a feature request in for some kind of cloth simulation tracked here: https://feedback.secondlife.com/feature-requests/p/weighted-clothing-material-with-collision -- in the thread people have discussed some things like collision volumes to stop the mesh intersecting, which was always a problem with the old flexi solutions too. All these things would be great, but maybe there's a computationally cheap way we can at least get part of the way? People have tried things using spare bento bones and animating, but that doesn't coincide with actual avatar movements, so it's really no more than a gimmick. I admit this is a bit beyond my wheelhouse, but I had a crazy idea, spoke to a few people about it, and they seem to find it intriguing, so I'm bringing it here. I call it "Velocity Bones". Imagine we have an extra (or maybe a few) bone in the skeleton, which mirrors existing bones, but all motion is delayed . When you move your avatar, the velocity bone starts moving a second behind the rest of your avatar, and stops moving a second after it. When you play an animation, the velocity bones will animate as per their mirror bones, but start a second later. This gives a bone that rigged mesh can be weighed to, which will be where you just were a second ago, and catch up with you when you come to rest. For example, imagine a ponytail with the end of the tail weighted to this velocity bone. You move left, the ponytail will trail to the right. You stop, the end of the tail catches up with you. You jump down from something, it bounces upwards. You dance, the end of the tail takes a little time to catch up with the top of the tail, giving a basic simulation of inertia. This doesn't solve collision problems, doesn't allow for things being moved by wind, but otherwise could provide us with something akin to what people used to use flexi for with attachments. We could have a cape flowing behind us, that moves dynamically as we fly. We could have moving hair. Clever people might even be able to put a bit of reasonably convincing movement into a dress with it. Best of all, it should be pretty computationally cheap. As I say it's beyond my technical wheelhouse -- I'm not sure how practical it would be to split-animate a skeleton in this way. However people have been crying out for flexi mesh or something for years, and since the idea occurred to me I thought I'd throw it out there and see if it gets any traction.

Dialog is practically the only "advanced" way for a user to interact with an object. The alternative is using a HUD, but HUDs are heavier, non-standardized, and often require significant effort to develop. However, the llDialog function is extremely basic in its current state. That's why I’d like to propose the creation of an enhanced function—something like llDialogAdvanced—with the following features: Key/label buttons Colored buttons More than 12 buttons (perhaps 15 or 18?) Built-in pagination when there are more items to display Built-in menu and submenu system Built-in breadcrumb navigation for menus and submenus And please... buttons ordered from top to bottom, not the reverse order as it is now I truly believe this would greatly enhance both scripting and user experience. Currently, implementing custom pagination, submenu systems, and reordering buttons top-to-bottom is a common necessity, but each script must handle it separately. The results are far from ideal: just look at any furniture system with 100 to 150 animations categorized in menus and submenus—it’s always confusing for the end user. Colored buttons and breadcrumb would help a lot.

You can select multiple inventory items and right click to view their "Properties", in one nested Properties windows. I would like two options here: 1: Batch Name Search & Replace I have the need to change several script names from "somethingSomething -nWM other thing ThinglyThing" to the same name, but without the "M" in it. So to do a batch rename replacing "M" with "". 2: Batch Permissions Settings You already know what I'm going to say here...! One master set of permission checkboxes to set them all, and in the darkness bind them! (yes, i know this doesn't affect in-world permissions. but don't forget about body parts, system clothing, eyes, sounds, animations, scripts, eep things, physics....!!!)

Can we possibly get the ability to use Linden water, or its unique visuals, on surfaces such as a prim in the future? Existing attempts at prim water are decent, but all lack the distortion element provided by the Linden water which adds immersion and realism.

Problem 1: You have a multi-story building or multiple rooms within 20 meters of each other. You're going to hear cross-talk regardless of walls. This can make conversations harder to follow for RPers, and means that you have to spread sky platforms and such out more for privacy. Problem 2: If your sim is not sliced into plots, you may run into issues with users camming into private spaces, which can lead to all sorts of nonsense and drama. Solution: Similar to how reflection probes work, let us create a cube, scale it to fit a room, click a checkbox and make it behave similar to the "Avatars in this parcel can see and chat with avatars on this parcel" option on parcel control. User can choose "see" and "hear" separately. With this, sim owners can give users with private homes on their sims actual privacy, and can reduce confusing cross-talk between closely placed rooms and skyboxes can be put closer together for better efficiency.

To be able to attach rigged/non-rigged assets to a specific point on an animesh character/model as we do on avatars. For example - to be able to add fire effects to come out of a dragon's mouth as it moves around.

Mesh levels of detail (LODs) are an important part of keeping the world of Second Life (and other 3D software and games) from becoming too graphically demanding on the variety of devices that run it. Different LODs are selected to be rendered by the viewer based on distance from the camera, scaled with the appropriate LOD distance factor in graphics settings. The problem: Creators are penalized with higher upload fees for creating proper mesh LODs, and users are penalized with higher land impact for using those meshes on their land Mesh involves two costs, upload fees and land impact, which affect both the creator and the end user. Many mesh creators upload their creations with great detail on the highest LOD, but then cripple their lower LODs to as few triangles as possible to reduce these costs. While this results in higher quality mesh compared to a mesh made with proper LODs at the same costs, it also increases the processing power needed to render the scene and causes the mesh to crumple or almost completely vanish when medium or lower LOD is rendered, most notably on lower-end PCs. This problem and workaround have irreversibly damaged our ecosystem, and for years now creators have crippled their own creations and told users to raise their graphics settings to compensate. With SL21B going on right now, and a recent Firestorm viewer update that automatically changed graphics settings on first launch, I saw a handful of shops with signs telling Firestorm users to raise their object LOD distance factor to maximum. This is not a good solution. There is also an ongoing bug in Firestorm that complicates this problem. When moving the camera around in Firestorm, objects worn by avatars (including the user's own avatar) sometimes remain in lower LODs even when moving the camera very close to them, and this requires the user to right-click the incorrectly-rendered avatar and reset their mesh LOD. Suggestion 1: Upload fees and land impact should be based on the LOD with the highest byte count To encourage use of proper mesh LODs, both the upload fee and the land impact (download weight) should be based on solely the highest byte count of the LODs provided, instead of the weighted average currently implemented . Suggestion 2: Restructure upload fees to encourage correct use of LODs For each LOD, the general guideline is that the triangle count should be roughly 25% to 50% of the next higher LOD. The upload fee and land impact should not increase if the byte count of each LOD is less than half (or one quarter?) of the byte count of the LOD above it. The upload fee and land impact should remain unchanged from the current implementation otherwise. Suggestion 3: Penalize misuse of LODs Conversely, the upload fee (but not the land impact) should be increased if the uploader is deliberately crippling LODs to try to game the system. Crippled LODs are obvious when the triangle count of the highest LOD is in the (tens of) thousands but medium and lower LODs are two digits or less, with the expectation that users will raise their graphics settings in order to see the mesh as the creator wants it to be seen.

Currently we can't update animesh size and have to upload multiple versions of the mesh in different sizes, and upload all animations for each size. I did some research in the viewer's code, and it appears to me that it's extremely easy to add a feature to adjust the global size of an animesh by modifying the llcontrolavatar.cpp file. Here is the current setGlobalScale() function: void LLControlAvatar::setGlobalScale(F32 scale) { if (scale <= 0.0) { LL_WARNS() << "invalid global scale " << scale << LL_ENDL; return; } if (scale != mGlobalScale) { F32 adjust_scale = scale/mGlobalScale; LL_INFOS() << "scale " << scale << " adjustment " << adjust_scale << LL_ENDL; // should we be scaling from the pelvis or the root? recursiveScaleJoint(mPelvisp,adjust_scale); mGlobalScale = scale; } } And here is a modified version that currently takes into account the X size of the main prim: void LLControlAvatar::setGlobalScale(F32 scale) { if (scale <= 0.0) { LL_WARNS() << "invalid global scale " << scale << LL_ENDL; return; } scale *= mRootVolp->getScale().mV[0]; if (scale != mGlobalScale) { F32 adjust_scale = scale/mGlobalScale; LL_INFOS() << "scale " << scale << " adjustment " << adjust_scale << LL_ENDL; recursiveScaleJoint(mRoot,adjust_scale); mGlobalScale = scale; } } Note that I replaced mPelvisp by mRoot because using mPelvisp does not correctly adjust the animesh's movement during the animation." It works wonderfully. Of course, this modification as it stands could affect many existing animesh objects, so we need to add a parameter to the object, 'ANIMESH_SCALE_FACTOR', which would be set to 1 by default, adjustable via script and by manual editing of the object. We would then have something like this: scale *= mRootVolp->getAnimeshScaleFactor; Here is a gif, you can take a look, the 4 dogs are all the exact same animesh, I only changed there main prim X scale : https://gyazo.com/de2dc2904bcb4e6b8737514aa7db7d2c