Server Bugs

When a user sets up an automatic email reply (e.g., vacation responder or canned response in Gmail) for incoming Second Life emails, the auto-reply is incorrectly addressed to an Amazon SES bounce/proxy address (something like xxxxxxx@amazonses.com ) instead of the original Second Life IM gateway address ( username@im.agni.lindenlab.com ). As a result, the auto-reply never reaches the sender in-world, and the original sender receives no indication that their IM triggered an out-of-office or automated response. Steps to reproduce (Gmail example): In Gmail, enable “Canned Responses” / Templates (Labs/Settings → Advanced). Create a new template with your desired auto-reply text. Create a filter that matches incoming emails from @im.agni.lindenlab.com (or specifically the Second Life IM address). In the filter actions, choose “Send template” and select the template created in step 2. From another Second Life account, send an in-world IM to the avatar whose email has the auto-reply configured. The IM arrives as an email → Gmail sends the canned response automatically. Observe the “To:” address of the sent auto-reply: it is an @amazonses.com address, not @im.agni.lindenlab.com . Expected behavior: The Reply-To or the effective destination should preserve the original @im.agni.lindenlab.com address (or provide a correct Reply-To header) so that auto-replies from users’ mail clients are delivered back into Second Life as IMs. Impact: Users who rely on out-of-office replies, support bots, or automated responses cannot inform senders that they are away or that messages are being handled automatically. This breaks a long-standing and heavily used feature of the email-to-IM system. Thank you for looking into this!

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