Server Bugs

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.

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.

Happens in sim Boardoom everyone is disconnected from the voice server with error 2025-10-21T13:58:52Z INFO #Voice# newview/llvoicewebrtc.cpp(2629) LLVoiceWebRTCConnection::breakVoiceConnectionCoro : Disconnecting voice. This happens multiple times a day. it happened at 2025-10-21 07:58:52 SLT

Locations where this happened earlier this evening: Solang / Les Cigalons (near 155, 11) Rua / Old Cave of Rua (near 70, 12) Sequence: You're flying across a sim border. The land you're about to enter in the target sim has damage enabled. "Injured" noise plays. You die and are teleported home. This has happened to me several times over the last week. This is likely related to a highly repeatable bug in which a vehicle gets nudged by a few degrees (sometimes moreso) when going over a border. If you want to see that bug, try landing at Hollywood Airport in Santa Catalina, where the runways are very close to the edge. You'll often find the nose of your aircraft pointing in a slightly different direction after you've crossed the border. There seems to be some kind of spurious collision event that takes place, even if it's an airplane and not in contact with anything at all. The phenomenon doesn't always have the same magnitude, but the hysteresis of "nudging" seems to scale inversely with aircraft mass. I have a very small aircraft (motorcycle-sized) that can be thrown off by multiple tens of degrees. Larger aircraft seem less susceptible: something the size of a Cessna 172 might get "tilted or panned" by 15 degrees or less. Corroborating evidence: The "nudging" effect is readily apparent at low speeds, when the aircraft's kinetic energy isn't much higher than that of an avatar. Go over a border at 30 meters/sec, when the aircraft's kinetic energy is many times higher than that of an avatar, and the effect is less apparent. My guess would be that this is a race condition that occurs while linking the avatar to the seat on the airplane as the handoff completes: they collide with each other during the split second that elapses between bringing the avatar into the sim, and linking it to the seat. Now, does the avatar have to be non-phantom while this is occurring? Probably not. Avatar collision hull is useful on vehicles, but it's not so critical that you couldn't do without it for a moment on region handoff. As I recall, over damage land, collisions can injure avatars, and vehicles forward damage to avatars as well. So, if the avatar is colliding vigorously with the airplane for a split second due to this phenomenon, the avatar would take damage.

On 02-July-2025 I received a $13L charge for a mesh upload - however as a lifetime Premium Plus member I believe that as of Feb/Mar 2025 there are no longer charges for mesh upload for Prem+ members. I'm not going to lose sleep over $13L but I wanted to report this in case it is a bug/regression. I have attached a copy of the transaction row from my $L transactions screen showing the charge.