Server Bugs

We did 11 races in January with all together 96 racers and have about 7-12 racers per race. A race takes normally max 40min. But there was not a single race in January all sailors finished without disconnects or thrown off the sail boat on crossing sim boarders The region "Depace" is the worst sim in the last weeks. We crash there most of the times either on the crossing into Depace or out of Depace. It happens as well when someone sails alone there. There is not much underwater stuff that needs to be rezzed long. So there is no actual reason for these crashes there. Check the sim Depace first and seriously and don't just look at some general parameters or values. Do a serious check including server address changes and all those things. The other sims start getting the same issues more and more. So the whole area is worth to be seriously checked. and i talk about all these sims: Stodierski, Mautte, Paltiete, Mon Bayete, Degrand, Sarante, Petaccio, Rexach, Betacourt, Feraco, Repaci, Castrum, Palmerston, Rafeiraga, Valdivian, Couse, Gerache, Collhaytah, Port Pawtee, Maris, Conwy, Port Gonnornertnert, Quimadra, Depace, Lavaca, Val Encia, Benach, Coull, Oprince, Getachew, Wyrldmaker, Corpening, Geffers, Costagliola, Cottier

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.

Sectigo have migrated their certificate issuance to Public Root CA's. Since that change, calls to in-world HTTPS services from sites using a new certificate are rejected with a 499 error.

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.

This old bug is still present, despite claims to the contrary. See the attached picture. Nude and broken avatars are on display for many minutes.

Sim to Sim / Script to Script Emailing is failing with this error: mailtolsl@mail-in-agni-2.secondlife.io > (expanded from < 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com >): Command died with status 11: "/opt/linden/indra/tools/mailglue/mailglue --grid=agni --system=lsl". Command output: DBD::mysql::db do failed: Data too long for column 'script_id' at row 1 at /opt/linden/indra/tools/mailglue/mailglue line 492, <STDIN> line 136. DBD::mysql::db do failed: Data too long for column 'script_id' at row 1 at /opt/linden/indra/tools/mailglue/mailglue line 492, <STDIN> line 136. Unable to get task mail presence from http://localhost:12040/service-proxy/task/5243fc88-9820-3f0a-649c-eb5d4f803003 < 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com >/mailhost The email is a simple subject of: "123" to rule out any weird text strings or anything with no body text at all and sent to: 5243fc88-9820-3f0a-649c-eb5d4f803003@lsl.secondlife.com (prim key) The Servers should not be failing like this. AI Breakdown of the error: Breakdown of the error message DBD::mysql::db do failed: Data too long for column 'script_id' DBD::mysql: This refers to the Perl database driver for MySQL, a database Linden Lab uses for its services. Data too long for column 'script_id': This is the core problem. The email system tried to save a value into the script_id column of its database, but the value was too long for the column's defined size. at row 1: This indicates the error occurred on the first row of data it tried to write. Unable to get task mail presence from http://localhost:12040/service-proxy/task/ ... This is a secondary error resulting from the first one. Because the initial database write failed, the mail system couldn't get a confirmation (task mail presence) from the internal service running on localhost (the Second Life server itself). Thank you for looking into this. I really need LSL email to work for my system

Land Impact overload after Rolling Restart October 21 2025

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.