Server Bugs

There has been consistent chatter about this in various aviation/driving groups for weeks. Full regions don't have this issue.

When Parcel Avatar Visibility is disabled/Privacy is enabled, avatars located in neighboring private parcels or Linden Homes become visible at distances greater than approximately 500 meters. This has been observed in both Bellisseria and mainland regions. The avatars appear in Firestorm's radar (often at long distances) as red bold text in the range section, and zooming to them reveals that their avatar is rendered even though Parcel Avatar Visibility is enabled and they are located on a different private parcel. Expected Result: Avatars located outside the parcel should remain hidden regardless of draw distance. Actual Result: At approximately 500–1000 m, some avatars are rendered and become visible despite parcel privacy settings. Environment: Firestorm 6.6.17 Firestorm 7.2.4 Second Life Official Viewer (used for comparison) The official viewer cannot increase draw distance beyond 512 m, making it difficult to reproduce there, while third-party viewers supporting greater draw distances expose the issue. Steps to Reproduce: Stand on a parcel with Parcel Avatar Visibility disabled. Use a viewer capable of draw distances greater than 500 m. Set draw distance between approximately 800–1000 m. Locate neighboring private parcels or Linden Homes more than ~500 m away. Observe whether avatars become visible despite the privacy setting. Additional Notes: Reproduced in both Bellisseria and mainland. The issue appears to begin around 500 m. The behavior may be intermittent, with some avatars rendering while others do not.

Both group chat and IM failing to initiate. I mostly experience it in Firestorm Social Island (simhost-0be97bd680c67540a.agni), as do the rest of the team. Starting an IM with someone else will work most of the time and every once in a while end up with a popup stating "Unable to start a new chat session with Username. The session initialization is timed out". Group chats will either fail silently or give the following message inline: "Second Life: You are the only participant in this IM session. Your message is not being broadcast at this ti2me." Tested on Second Life Release 26.1.1.23806384790, Alchemy Beta 7.1.9.2516 and Firestorm 7.2.3.80036.

This happens intermittently, in any region, where an object won't rez and the attached message appears. Most of the time rezzing in a different spot in that region ends up working, but on one occasion a whole region was giving this error when trying to rez. Multiple people affected.

A year later and it is getting worse. It happens nearly every trip in my boat. I have identified three ways this happens on a region change. I suspect that they are different manifestations of the same underlying cause. Unsit, where the boat does rez in the new sim and continues on its way while I am thrown overboard and end up on the bottom. My boat (Machichaco by Isard) detects this and sends me a message with it's current SLURL, allowing me to TP to it, resit, and take control. This used to be the most common form of failure. Loss of control. I remain sitting on the boat but it is no longer responsive to my inputs. The boat (and I) continue in the new sim, moving along the previous velocity vector in a phantom state, passing through buildings and land. If the velocity had a vertical component we may end up flying up at an angle, or submerging. I think this is the viewer extrapolating on its own. Catapult. The boat does NOT complete rezzing in the new sim but I do. Since the boat no longer exists, it does not send me a SLURL message and it does not end up on somebody's land where it would eventually get returned. As in case #2, my avatar continues along the previous velocity vector, often up into the sky (sometimes hundreds of meters up). I can follow my progress on the Map but I notice that the viewpoint and the avatar location are not together. I can see myself off in the distance as we fly away. Eventually, either a timeout or reaching the far side of the new sim, I am suddenly jerked back to two sims back, standing on the sea bottom. I can walk forward and backward but unable to turn. At this point I can TP back home but on arrival, the inability to turn continues. This case is happening a lot now. Examination of the log for case #3 (collected at 2026-06-03T02:16:14Z) finds many suspicious WARNING messages which may provide clues. I was proceeding West along an open corridor in the Blake Sea area: Norwegian, Japan, Irish, China. Caribbean. Speed was about 11 knots. (Entry to Caribbean is where case #3 happened.) Each of these warnings appear multiple times. I was using a non-mesh avatar with no scripts other than a Navigation HUD that was logging sim crossings (88 kB), and the boat control HUD (64 kB). There is, in at least case #3, no logging of actually entering the new sim. requestExperiences : Capability query method not set getCapability called before caps received for GetExperienceInfo stageAfterCompletion : HTTP request 0x7f6205a56c10 failed after 0 retries. Reason: Forbidden (Http_403) onCompleted : Possible failure [Http_404] cannot POST url ' https://simhost-0353d13a62153db1f.agni.secondlife.io:12043/cap/defd51df-3e5d-1671-81f7-5d5f44b87a5e ' because Not Found onAssetLoadComplete : Error getting material asset data: Asset request: failed (-1) process_agent_movement_complete : agent_movement_complete() with NULL avatarp. parserWarning : Failed to parse parameter "sd[order]" The "Statistics" window shows that UDP traffic continues as before with a sim ping time of 134ms. This looks like a combination of race conditions and the new sim simply not responding. I note that setting Draw distance to just 32m increases reliability considerably but it is very boring because the whole point of these trips is to look at the scenery pass by.

This is an intermittent issue, happening all over SL at various times, to random people, where renaming a notecard results in the permissions to break where you can't even view them anymore. This has been ongoing for a couple of months now, and is subject of lots of conversations in our groups.

Objects physically crossing between parcels of different ownership on mainland causes the object to not be detectable by sensors, raycasts, scripts, becomes invalid uuid It fixes itself when edit moved, or sat upon. Sometimes the object in the glitched state can disappear from rendering entirely. Cannot return the object from a parcel while in the glitched state. RLV cannot even force sit you even by uuid. Collision event still picks up a uuid.

There have been long-standing issues with land leveling tools being left out on regions for too long, which causes performance problems that often require a region restart to resolve. While a restart is only a short-term solution, this has been a known issue for quite a number of years now. I believe it is time for Linden Lab to look into this again and implement a proper fix for a permanent resolution. It would be very much appreciated. Thank you, Mark

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.

I first became aware of this when I noticed my aircraft weren't going into "taxi" mode on landing. It was hard to chase down the origin of this behavior, but I eventually discovered that a script containing collision_start()/land_collision_start() event handlers was being TURNED OFF on region crossing... but only on rare occasions. I might cross 20 borders without this happening, or even 50 or more. It seems like it's more likely to happen in certain areas, such as the stretch of sims starting just south of Santa Catalina and continuing east across the Blake Sea to that giant four-sim airport in the Norwegian area. I suppose if they're homestead sims, that could explain why that particular area seems more susceptible to it. That has been by far the most reliable place for reproducing this bug. I grepped all of the scripts in the whole object for llSetScriptState() calls. There are none. (No reason there would be in the first place.) I found that removing an llSleep() call just after a collision_start() event caused the rate of the script halting to be greatly reduced. I theorize that the chain of events is something like this: Vehicle crosses sim border. Occasionally, this causes a spurious collision_start() or land_collision_start() event. (This happens well up in the air, obviously, so it isn't a "real" collision. Probably a race condition between the vehicle and avatar entering the sim in some stochastic order.) Something about the invocation of llSleep() when the vehicle is still actively being handed off fritzes something in the simulator; and it responds by halting the script, OR by failing to return control after llSleep()'s time has elapsed. Whatever the cause, the script's "Running" checkbox is disabled, and it is quite inert.