Server Bugs

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.

Strange but repeatable behavior when an avatar cannot enter a parcel but a vehicle can. Avatar gets knocked off the vehicle and is left sitting in midair, unable to walk or stand.

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

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.

When traveling across regions by sim crossing and then detaching an item from our avatar, it often happens that we lose a whole bunch of items that suddenly detach, leaving us half naked and with some body part missing. This involuntary detachment of items from our avatar is very frustrating, it's an obstacle to exploration, and it discourages investment in SL especially on the mainland. I've been told that wearing multiple items on the same attachment point can triggers this problem at a server/region level, but nowadays it's impossible to have only one object per attachment point. Strangely, it seems not everyone experiences this problem with the same frequency, if at all. If this issue has already been raised and addressed, please excuse me. For me, it's terribly bad. I no longer dare to travel by sim crossing, and I get a knot in my stomach every time I detach one of my worn objects.

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.

Greetings. I've been having a problem for several months, and before throwing in the towel, I sent a ticket to Linden Labs asking for help. They don't know what the problem is and asked me to post my problem here with as much information as possible, so here it is: I place my boat (TMS) Aurora on the water to sail in Blake Sea from the Devolin Mal sim. I sail in a straight line through the Bleacher, Albach, Spyglass, and Swash sims. I make a right turn away from the edges and enter the Buckle sim. Then, in the Swab sim, I crash and get disconnected. This doesn't only happen in that sim; I crash in different sims at random, and when I come back online, the sim is fine and online. A few days ago, it happened in the China sim, and last week in the Crows Nest, Cattewater, and Norwegian sims. It's even happened to me that I sail around the lighthouse and Sirens Isle, and when I return to sims that were fine, I see them down. Location of my last crash http://maps.secondlife.com/secondlife/Blake%20Sea%20-%20Swab/192/255/33 This is happening with the official Second Life viewer and Firestorm. I always do a clean install when I upgrade to a new version. My PC Configuration: Video Card: RTX 2060 12GB Processor: i5-12400 RAM: 16GB (2x8GB) DDR4 Motherboard: ASUS Prime B660-PLUS Storage: Western Digital 1TB WD Blue SN570 NVMe Internet: Fiber - Download 761 Mbps - Upload 767 Mbps Any suggestions? Thanks in advance

Description: In 2025, an old bug is back. Edited a script in an attached object, hit Save over 150 times, compilation was successful. After teleport or crash, script reverted to an older version (1.8). Hours of work gone. Details: Object was attached (not rezzed). Multiple manual Saves, confirmed by compiler. After teleport or viewer crash → changes lost, script rolled back. This bug had been fixed years ago. It’s now back and happening again in 2025. Affects attached objects more often than in-world ones. Severity: Critical for developers. Fix needed: Asset save sync on attachments is unreliable. TP or crash = data loss. This should not still happen after 20+ years. WTH — I worked 2 hours HARD for nothing due to your stupid glitch. We're in 2025, and you still haven't fixed teleport issues? 23 years later and TP still sucks. Seriously?

Remove a person from group. Send out a group IM. They are still able to access and send group ims.

In a previous server version, llGetAnimation() would never return "Standing" while a pushed avatar was still moving, unless stuck against a wall. But now it does. To reproduce, put this script in an attachment: default { state_entry() { llSetTimerEvent(0.2); } timer() { llSetVelocity(<14, 0, 0>, TRUE); llOwnerSay(llGetAnimation(llGetOwner())); } } This script previously would print a mix of "Walking", "Running", and "Striding" while moving, and "Standing" if stuck against a wall. But now it also sometimes prints "Standing" while still moving normally