Server Bugs

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.

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.

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.

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.

Conference Chats

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

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.

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.

Internal scheme identifier "slcap://" is leaked in PUT and PATCH requests to AISv3 endpoint

A friend periodically places full-perm textures in an object that she owns to which she has given me modify rights. The object is not locked. My active group is the same as the object's group. Her intention is that I be able to take copies of the textures. It worked perfectly for a long time, but for the last several months I cannot take copies. I can open the content tab of the edit window and try to drag a copy to my inventory, and it fails. I can open the texture, and the Copy to Inventory button is available (not grayed out). When I click it the texture closes and no copy appears in my inventory. Since I can open the texture, I can easily copy it by capturing a copy from my screen, so there is no security advantage to my being unable to copy it. In addition, since this used to work, I think it is unintended behavior. I cannot imagine a use case in which someone would want to give mod rights to someone else but wouldn't want them copying full perm contents of unlocked objects.