✨ Feature Requests

Simplify the calculation of Land Impact (LI) by eliminating all relevance of object scale on LI. It is highly confusing that the size of an object impacts its LI, especially when an object switches from old to new accounting methods, suddenly becoming much more expensive LI-wise than it was previously. Context Second Life has two methods of calculating the LI of content: "Old" style Basic prims with blinn phong materials are counted using the original LI method: 1 prim = 1 LI. "New" style (Mesh and Material Calculations) Mesh content and objects with new-style PBR materials use a newer style of accounting that takes many things into account, including object scale, download size, etc. Download weight Physics weight Server weight Display weight Solution Let's err towards simplicity here: Eliminate impact of scale on LI The goal should be that users should not be surprised when working with LI. Eliminating the scale from the calculation would mean that LI would not wildly vary based on the size of an object. This should make the accounting system much less variable and confusing. Links https://community.secondlife.com/knowledgebase/english/calculating-land-impact-r273/

Hiya everyone, i wrote some weeks ago already a feedback about the too high number of disconnects and crashes in SL and we got told during the round table meeting, that this will be fixed and LL is working seriously on this now. But all our sailors didn't stop thinking about the reasons of the disconnects and crashes as well and we are now very sure, that LL wont ever solve the problem with software changes. To explain why, we need to go some years back in history and and look at when the disconnects started to become a frustrating problem. LL moved SL to Amazon servers about 6-7 years ago, changed the crossing process for that and the disconnects began. During the 6-9 months test time i had minimum 10 crashes EVERY DAY and was very close to leave SL like a lot of friends did. It became less over the years, but NEVER stopped and a lot new friends start to leave SL frustrated. LL is doing a great job to make SL much more beautiful and exciting with new connected continents, much better graphics like PBR and many more things. That is like giving us a Porsche or Bentley to drive, but unfortunately they forgot to improve the roads as well and let us still drive on the dirt tracks with only 25km/h. This means for SL: Our sailors cut down the graphic parameters to a minimum, decrease DD and view angle to a minimum, reduce all their scripts in their active Avi to a miminum and more and more are using the old default Avi for racing to reduce the crash risk. And we thought for some times it would work, but it was a fake and the conditions didn't really change much. We talk a lot about our races after our races in our bar and the idea i want to write about now grew more and more. Our problem is the organization of the servers. There are about 5 regions on one server. They will be randomly new combined weekly with every rolling restart. That means for example region A, M, G, O, and W are this week on server 1 and next week the 5 regions can be on server 1, 5, 8, 15 and 20 and on sever 1 can be region H, D, P, Y and B. The regions are all different equipped and so the servers will work differently every week. In my last feedback i wrote, that we have in our race area regions, which are statistically worse that others and we crash there more often, but we didn't understand why that changes weekly. Now we know. I am not a server expert, but i am a shopping expert and i can tell you that shopping all your stuff in one big shop is much faster than to buy all in 5 differenmt shops. 5 shops can be a bit cheaper, but when time is my priority then i am willing to pay a bit more and can use the time i won for nicer things i enjoy more. Here is now our idea: Have neighbored regions like A, B, C, D and E on always server 1 and region F, G, H, I and J always on server 2... and so on. I don't have to change the server, when i cross from region A to B or C or D or E. Server changes happen a lot less, because i have neighbored regions on the same server and they don't get reorganized weekly new. I will win time for crossings and they will be much safer. if i still crash on some regions i can easier analyze the reason for that. I suggest to try and test this idea for example on a small part like Blake Sea area, if you need to test this idea on RC Channel first, because i think those regions should be all on RC Channel. Our racing community can support the tests in our race area, because that is all on Main Channel and there i will collect the feedback from our community for you. This will be a game changer and all your awesome work to make SL more beautiful can be used much safer and more. Isn't that a great feeling? Cheers Bianca♥

Schedule notice send in advance

Very simply put, I want to glue an avatar or object to an animated bone and have it inherit position, rotation and scale from the bone. Ideally with an offset. Probably guarded behind a permission request like PERMISSION_TRIGGER_ANIMATION. This would enable a whole lot of cool interactions with animesh. My specific use case: I make drivable animesh robots/mechs, those are animated heavily, with all sorts of layered animations. The pilot has to be animated in sync with it, but that creates problems when the vehicle has any kind of combined animations (e.g., bouncing walk + torso twist to the right). You can't smartly layer these at runtime without conflict, and making one animation for every possible combination quickly makes the animation count explode. Other things enabled by this wishlist feature: Picking up people or objects with a mech hand or moving any object seamlessly (gtfo cargo transport, anyone?) To be clear, I don't need scripted bone weights, even just a simple way to specify a constraint on an object or avatar that glues it to a bone would be swell. (The actual reported transform of the object/avatar would probably be simply be the same position as the root of the object that it's glue to)

It is now more crucial than ever to address the default point lighting and spotlights in Second Life, given the introduction of PBR materials. The point lights will always pass through walls, regardless of the presence of reflection probes. This has been the case and has not been rectified to this day. The number of spot lights is restricted to two. Once that limit is reached, they cease to cast shadows or function correctly, they will behave as point lights and will also pass through walls. This impedes the ability of both creators and consumers to accurately illuminate a scene in a manner that is both consistent and visually appealing. Furthermore, I recommend that the lighting and render engine of Second Life undergo a comprehensive overhaul before the inclusion of features such as Displacement maps. This will ensure that the lighting in scenes is consistent and provides a more realistic experience than it currently does. Additionally, global illumination should be incorporated into the rendering process. This is similar to the default setting in the majority of contemporary games, which ensures that any object, from the most basic cube to the most extravagant home available on the marketplace, appears visually appealing. And it ultimately grants us creators more autonomy and eliminates the necessity of baking textures to replicate the global illumination effect, which we still have to do, if we want a realistic looking scene, even with PBR materials and reflection probes. And also is the reason why creators chose to advertise their objects using Renders, instead of Ingame screenshots, which is deceptive, and should be unnecessary. The following images illustrate the information I have provided. I created a simple scene that consisted solely of white walls and a white ceiling, with a blue floor and default PBR materials. However, the blue reflectivity of the surfaces is unappealing when a light is introduced. In contrast to the second image, which illustrates the same scene in Blender with global illumination and accurate rendering, the light is distributed more evenly and realistically, thereby enhancing the efficiency of the materials. This is the proper approach, as it eliminates the need to bake scenes. And as simple as this structure is, it looks visually appealing. I am concerned that the displacement maps will present the same issue, or even worse, in the current engine. This is not an appealing appearance. The first image with the rocks is what i am expecting. The latter image, which depicts the building, demonstrates the appropriate rendering of a displacement map. Before incorporating any additional features, such as displacement, parallax, HDRI, or any other feature, first, please enhance the lighting engine to ensure that any scene, regardless of its creation, is rendered in a visually appealing manner by default. This will give Second Life a more contemporary appearance and make it more user-friendly. I am confident that the playerbase would be extremely grateful. And likely people would return returning from competitors, such as VRchat. Which has a modern engine, being that it uses unity. In conclusion: Modern texture mapping methods necessitate a modern engine that is capable of rendering them accurately; otherwise, they are merely a form of deception that will not cause any significant changes.

Many times our items are returned to us as a coalesced group and then, sometime later, we can't find a critical item in our inventory and suspect that it might be within a coalesced group but have no ability to do a simple search to find that missing item- without having to rez multiple different coalesced groups trying to find the missing item. There should be a simple way to search inventory from within the inventory window to locate an item that is a hidden part of a coalesced group. If a global coalesced inventory search is impractical, there should be a way to right-click on a coalesced group to easily view a listing of the names of all of the coalesced items within that group without having to rez anything.

This has been the case from the beginning. On a standard prim, the maximum hollow percentage is 95. This leaves a shell that is simply TOO THICK. Please, please change that arbitrary 95 to 99. It will make a big difference in viable objects and build attractiveness.

As its known that most users in second life cannot afford land. Premium users, free users, new users, old users. It was told years ago the cost of land, sims, homesteads, would come down by being hosted on the Amazon Cloud Service. It can cost around three hundred US dollars per month to 'own' your own sim in second life. This is not a small cost whatsoever. Some other virtual platforms (Roblox specifically) operates almost like second life with it's land building but the difference is it's cost and customization. It's free and very customizable, although chunky. I feel like owning a private place for you to go to is wonderful, or even somewhere to open your own shop or more. I feel like making it more affordable would be even better to bring more income and users to SL, as well as new locations. A lot of places I used to go to have closed down due to the cost of running or even renting a sim. I feel that cutting the costs by either half or even 25% might be helpful in bringing in new locations with better affordability. (Math might not be correct or accurate.) (The price was times 25% so it'd be a reduction) Type: Full Region Parcel Size (m²) 65,536 Price: $349 (25% cut would make this $87.25) (New price 261.75) Maintenance Fee (monthly): $209 (25% cut would make this $52.25) (New price 156.75) Skill Gaming Region Parcel Size (m²) 65,536 Price: $600 (25% cut would make this $150) (New price $450) Maintenance Fee (monthly): $345 (25% cut would make this $86.25) (New price 258.75) Homestead Region Parcel Size (m²) 65,536 Price: $149 (25% cut would make this $37.25) (New price 111.75) Maintenance Fee (monthly): $109 (25% cut would make this $27.25) (New price 81.75) Please forgive me if the math's wrong. It isn't one of my best skills. But the point remains that things just aren't affordable. So if we do the percentages correctly, it can be more affordable to users and friendlier for wallets overall.

I suggest an enhancement to the Bakes on Mesh (BOM) system by introducing an opacity option for BOM layers. As a designer, the current limitations of BOM force us to add additional mesh layers, particularly for makeup applications. This increases mesh complexity and necessitates the use of complex HUDs. Enabling opacity control on BOM layers could eliminate the need for extra mesh layers, thus optimizing mesh complexity and enhancing overall performance. Additionally, this would allow for greater flexibility and creativity, as BOM makeup layers wouldn’t be limited to one or two mesh layers (depending on the number of mesh layers created by a designer). With the recent introduction of 2k BOM textures, the capability to adjust blend modes directly on BOM layers would be highly beneficial for both designers and users. It would offer more customization options and improve the user experience. It would positively impact the creative community and contribute to a more streamlined and efficient design process.

Gesture chat spam in crowded areas is very disruptive and problematic for screen readers and translators. A simple toggle should be added to the viewer that filters chat instantiated by gestures from local chat.