Server Bugs

Edited post with some further information. Some linkset data functions are slower than one would expect. I first noticed slowdowns on April 11th and looked in detail about it. It's taking some additional frames to do linkset writes in a region that is all but empty. I have a script to repro with results on top comment attached to this ticket as well as the regions I tested this in including RACore (Skill Gaming region), Rabbits Landing (Full Region), and Chicory Field (Linden Home Region).

After spending a certain amount of time in a region, the player enters a state where they can continue to remain in the region, interact with things in the region, and chat in local or IM indefinitely, but when they try to teleport out, cross a border, or certain other actions, it will fail and they will be logged out. This is a relatively old issue, and having spoken with Monty Linden about it, it appears (at least as I understood it) that the player becomes soft-disconnected from the grid, without disconnecting from the region they're in. What's different now (within the last month or two) is that the amount of time needed to be spent in the region to trigger this has vastly shrunk, from several hours, to as little as 5-10 minutes. As a result, more and more people are experiencing teleport and crossing failures and random logouts recently. Edit: This state can usually be identified early by alt-camming on something far away. While the surrounding regions already loaded will remain loaded, all regions beyond them will never load, even when alt-camming on something that puts them well within the view range.

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.

Summary: Users are incorrectly shown as offline to each other while actually being online and co-located. This results in failed instant messages and inability to initiate chat sessions. Description: Multiple users are experiencing an issue where avatars appear offline to each other despite being visibly present in the same region. This prevents IMs from being sent or received and causes chat session failures. In some cases, sending an IM will suddenly update the avatar’s status from offline to online, suggesting a delay or failure in presence/status synchronisation. Error Message Observed: "Unable to start chat session with (AVATAR NAME) The Session Initialisation has timed out" Steps to Reproduce: Two avatars log in and stand in the same region Observe that one or both appear offline in the friends list Attempt to initiate an IM IM fails with session timeout error In some cases, sending an IM updates status to online Frequency: Intermittent but frequent (reported by multiple users over several months) Impact: Prevents communication between users Disrupts social interaction and events Particularly problematic in live environments (e.g. clubs, roleplay, group coordination) Additional Notes: Issue occurs even between users on the same local network/IP Reported by multiple unrelated users across different locations Appears to be a server-side presence or messaging issue rather than client-specific Request: Please investigate presence synchronisation and IM session initialisation, as this issue significantly impacts core communication functionality.

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.

If you are offered a teleport, teleport elsewhere - and then accept the teleport, the viewer hangs on "Requesting Teleport..." for 90 seconds. Most times this causes a disconnect. With some testing: After this... if you try to tp to the destination region again you time out. If you tp elsewhere first, you might recover.

When you try to open a conference chat sometimes you get people that you’ve never spoken to in the left-hand column and none of the people that she wanted to chat to so you’ve got to add them individually. The people that already showing don’t get any chat. When you are in a conference chat, it breaks where you could type something and don’t see it and you have to teleport out of the server and teleport back and then it fixes it but only for a short time and then it happens again Sometimes you can’t create a conference chat at all When in a busy server people that are not there that are on your friends list either see you as off-line or you don’t see them and if they try to message you it tells them that they’re off-line and you don’t get the messages until you re-log and then you get flooded with the messages that people have sent you

Following this closed thread: https://feedback.secondlife.com/ldpw/p/there-should-be-no-instant-autoreturn-protected-land-anywhere The root of the problem is that failed region handoff often unsits avatars from vehicles, OR it breaks the sit camera + controls so that they have to stand up and re-sit in order to regain control of the vehicle. When the vehicle is over a no-entry parcel, it's returned within seconds, even though the auto-return time may be minutes long. This is a common setting in water sims that were put there specifically for vehicle navigation, so you can see how this behavior is at cross purposes with the intended use of the sims in question. It's also confusing to users to have a visible setting that is functionally meaningless. It was suggested in the forums that this is for gray goo mitigation. I propose two possible solutions (either/or): Gray goo works by recursively self-rezzing objects. Track how many generations have passed since the object was rezzed by an agent. (Call that "telomeres," same idea.) If that number is 0, then don't instant-return it over no-entry land. If an agent was seated on the object when it entered the region, then it obviously isn't gray goo by itself (there is no realistic way to do "gray goo" if each object has to have a "rider") so don't instant-return it over no-entry land. #1 is more robust, but also somewhat more difficult if you want the information to cross sim borders. #2 is probably easier, as the information lifecycle is single-region. Either solution would mean that the autoreturn time would be accurate, and that vehicle operators would stop being repeatedly penalized for region handoff bugs.

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.

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.