Server Bugs

When a script is deleted from object contents, the object's server weight is not reliably reduced according to the (updated) calculation at https://wiki.secondlife.com/wiki/Mesh/Mesh_Server_Weight as it is when a script is added. So in order to get the correct server weight reflected in the Land Impact, it may be necessary to remove _two_ scripts and add one of them back. This can be observed manually, but to simplify testing and demonstrate that it's a server-side effect, here's a little script: report() { list details = llGetObjectDetails(llGetKey(), [ OBJECT_PRIM_EQUIVALENCE , OBJECT_SERVER_COST , OBJECT_TOTAL_SCRIPT_COUNT ]); llOwnerSay(llGetObjectName()+" consists of "+(string)llGetNumberOfPrims()+" links, having " +(string)llList2Integer(details, 2)+" scripts for a server weight of " +(string)llList2Float(details, 1)+" and total land impact of " +(string)llList2Float(details, 0)); } default { state_entry() { llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, [ PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE , PRIM_LINK_TARGET, LINK_ROOT , PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX ]); report(); } changed(integer change) { if (CHANGED_LINK & change) llResetScript(); if (CHANGED_INVENTORY & change) report(); } touch_start(integer num_detected) { report(); } }

Voice is dropping out very frequently now multiple times per hour

Since September 5th, our players have started reporting that their fishing rods break and become unresponsive. The main script, which relies on the touch_start event, no longer triggers. This issue resembles a stack/heap error, but in this case, no errors are reported by the simulator or viewer—unlike typical stack/heap failures. Memory exhaustion is also unlikely, as this script has functioned correctly for over 10 years without issues. The problem occurs in the following scenarios: * When players teleport between regions * Occasionally during active fishing * Some players report it happening upon login while they log in wearing the rod (as attachment) The issue affects many players, but not all, which suggests that the problem is not caused by our scripts or the fishing rod itself. We have been unable to determine why the same fishing rod behaves differently: for some players it breaks, while for others it continues to function normally as it has for years. Around 30 - 50 total players affected so far since September 5th. Aprox. about 7% of our players have been affected.

Note - I once thought this was a Firestorm Viewer problem, so I downloaded SL viewer per their request guidelines. It has happened with SL viewer too. At times, I don't receive an IM from someone, so they call me out in local. I try to IM them to correct it - and I question if they can see my IM. I see that they are responding, but then there is no message. I have finally caught this whole transaction in screen shots. I don't have trouble with local at all. I have tried to re-log and it sometimes still does not correct the issue. The issue is also very random. Some days it does it and some days it does not. I have noticed it on two different PC's too - both running up-to-date Windows 11. I just recently downloaded the newest version of Firestorm release, hoping it would clear up. But it just did it tonight (11.15.25)

It is quite understandable if the 10,000 limit applies to the objects we are taking combined/deleting/returning as we might rezz the same at some point and cause overload to the server but applying 10K limit to the content of the objects is quite hard to work around, especially when we are dealing with objects with large content. I had noticed this error appearing but I never really thought about finding the limit till yesterday. When I was trying to return a house, including its furniture, so it would be easier to rezz at the new spot, I had to keep reducing my selection until it was down to 12 objects! It was then I felt doubt; it's probably not the objects themselves but the content of the objects that is causing this issue, as I was able to select almost everything else worth thousands of prims at once and return. Upon further testing, I found that the furniture pieces I was trying to return had approximately 800-1000 animations in their content. As we all know, there are many furniture creators who include thousands of animations in their products and with this limit it would be almost impossible to delete/take/copy a bunch of furniture at once. I am aware of the possibility of using the return option with both land and region tools to avoid this limitation. However, when we wish to rebuild something at a different location or create a backup there is no real alternative in this situation. I kindly request LL to bless us with a workaround or reconsider how the limit is applied to make things easier for serious builders and those in service sector. Thank you for your time and attention

Teleports between regions will sometimes (but fairly frequently) fail, causing the viewer to timeout and disconnect. I will try and log when and where this happens, and update where possible. This is what I have so far: User: Quinn Elara 7/12/2024 - 14:55 GMT / 06:55 PST, FROM REGION "TOKYO ZERO" 7/12/2024 - 15:25 GMT / 07:25 PST, FROM REGION "Vanilla Bae" Format: dd/mm/yyyy

Basically. Crouch, then turn around (or briefly tap a movement key), and your avatar will often start drifting. AFAIK, this is an issue with server physics, hence posting it in server. Players in our games are currently forced to manage this random drift by pressing the arrow keys while crouching behind cover, which is very annoying. This issue has always been present for as long as I can remember. Granted, it's a minor annoyance, but I figured you should at least be aware of it.

Many of the groups I am in are getting hit with people spamming in chat with scam links, slurs, harassment, etc. but you can't ban the user because they make their comment and then leave the group. They re-join later and do it all over again. You can only ban people from a group while they are in the group. Not only that, but often this constant leaving and re-joining seems to confuse the group member list so they don't come up even when they are in the group chat making comments again, so you still can't ban them. Please make a way to ban people from a group regardless of if they are in it or not. We've also had incidents where we do ban people and the exact same account is somehow still coming back in chat after being banned. This is getting ridiculous. It's happening every day, multiple times a day, in groups all over SL. We need a way to get rid of them from our groups quickly and permanently. Yes, there is an option to ban members from the group by lookup. Is is not working. They are still getting in group chat.

This is separate to the related export issue that I have raised ( https://feedback.secondlife.com/server-bugs/p/terrain-export-is-badly-encoded-quantised-leading-to-significant-resolution-loss ). It seems plausible that it could be related to https://feedback.secondlife.com/feature-requests/p/remove-lossy-compression-from-terrain-heightmap Generating a precise height map that complies to the specifications defined on the LL wiki does not result in the expected results upon import. This makes it impossible to plan a proper terrain layout with any degree of confidence. Given that OpenSim correctly and accurately imports the data as per the SL specification it means that those people using a local installation of OpenSim to test and prepare regions for use in SecondLife are going to be very disappointed. Repro steps: 1) Find a raw file for a flat terrain (e..g 20m) I can provide example files but Canny is too frustratingly lame to accept them as attachments. 2) set water to the same level 3) note that the land is not at the same level as the water. Secondary tests. 1) Import a linear ramp. (can be generated using my terrain tools) https://github.com/beqjanus/terrain-tools 2) Note that it is far from linear

See blog post https://www.blogger.com/blog/posts/8863246996882687669 for a longer write up. tl;dr version is... The terrrain files produced by the SL server when exporting terrain are not properly encoding the height, resulting in coarse quantised terrain. It would appear to choose to encode only the height value (R channel) leaving the G channel untouched. This means that the resolution of the land exported is limited to whatever value happened to be in the G channel at the time of creation/import. Untested repro steps, as I have no access to SL regions with terrain rights. My terrain tools should be usable but they do try to minimise the G value for any given height. The attached 20m-Q4 file is encoded to R=80, G=32, meaning that the minimum G step is in their 1/4 metre, so it should still be visible with a sharp gradient. 1 start with an empty region 2 load a flat terrain RAW file, if possible use one with a G channel suitably high to demonstrate the issue, 120 would be a good starting point. 3 in SL manipulate the terrain using the inworld tools, adjus the strength of the tools. 4 create a mount with a slow smoother gradient that is shallow enough and wide enough that the stepping should be obvious. For a G value of 120 a smooth mound of diamater 10m and height 10m should give ample evidence 5 see the smooth land in SL 6 bake and export 7 re-import explected results a stepped pyramid instead of a smooth mound.