Server Bugs

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.

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

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.

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.

Recently I keep getting individual instant messages and sometimes even teleport requests sent to the mobile app only, even though the app is not running and I am logged in with a desktop viewer, which is receiving previous and later messages. Missing messages mid-conversation extremely disruptive, in particular when organizing or providing support. This might be related to the sender having connection issues or going offline. Weirdly the message is still received by the server, but not delivered, despite the recipient still being there.

Steps to reproduce Go to any region. Crash the viewer in a way that it doesn't properly send the logout message. Attempt to log back in. May take a few times, but once you get it, it's hella annoying. The issue Once the bug is triggered, the agent in the region will eventually disappear, especially so if the agent tries logging back in. Once the agent does log in, the region will refuse to grant capabilities to the agent (Login server passes the simulator address and seed caps, but the seed cap will return 404). This will last for more than 15 minutes where the agent is unable to log into that region. Work arounds To just log in: Log into any other region (Home, etc). To get back into the region: Log into any other region. Enter the region that you crashed in (Sometimes this may have a stalled TP which results in a disconnect). (Observation) Observe that no mesh loads, as the capabilities are returning 404 for the region. Log out (Gracefully!). Log back in (Capabilities will now be granted in that region because of the graceful log out). Live reproduction On the region Fractal: Crashed at about 2024-05-17T23:54:08.666700Z Logged back in (to fractal) at about 2024-05-17T23:55:00 (Estimate because cant query the timestamp cube) (Capabilities borked) Logged back in (to home) at about 2024-05-17T23:56:15 (Estimate) Teleported into fractal at about at about 2024-05-17T23:56:45 (Estimate) (Capabilities borked) Logged out at about 2024-05-17T23:57:45 Logged back in at about 2024-05-17T23:58:15 If you are unable to reproduce this, I would gladly reproduce this issue on a specific region and provide timestamps. Error log (From viewer) 2024-05-17T23:55:04Z INFO #AppInit#Capabilities# newview/llviewerregion.cpp(317) requestBaseCapabilitiesCoro : Requesting seed from https://simhost-06639c25759dd162e.agni.secondlife.io:12043/cap/1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e region name region id 00000000-0000-0000-0000-000000000000 handle 649811372272128 (attempt #7) 2024-05-17T23:55:04Z WARNING #AppInit# newview/llstartup.cpp(1511) idle_startup : Failed to get capabilities. Backing up to login screen! 2024-05-17T23:55:04Z WARNING # newview/lltoastalertpanel.cpp(195) LLToastAlertPanel::LLToastAlertPanel : Alert: We're having trouble connecting. There may be a problem with your Internet connection or the Grid. You can either check your Internet connection and try again in a few minutes, click Help to view the Support Portal, or click Teleport to attempt to teleport home. 2024-05-17T23:55:04Z INFO # newview/llworld.cpp(327) removeRegion : Removing region 151296:256512 2024-05-17T23:55:04Z INFO #AppInit# newview/llstartup.cpp(3131) setStartupState : Startup state changing from STATE_SEED_GRANTED_WAIT to STATE_BROWSER_INIT 2024-05-17T23:55:04Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(413) stageAfterCompletion : HTTP request 0x589aebdf6180 failed after 0 retries. Reason: Not Found (Http_404) 2024-05-17T23:55:04Z WARNING #CoreHTTP# llmessage/llcorehttputil.cpp(275) onCompleted : Possible failure [Http_404] cannot POST url 'https://simhost-06639c25759dd162e.agni.secondlife.io:12043/cap/1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e' because Not Found 2024-05-17T23:55:04Z INFO # llcommon/llsdserialize_xml.cpp(424) parse : LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:cap not found: '1e31ed80-9ac3-336c-ff8b-a26c82f6dc9e' 2024-05-17T23:55:04Z INFO #AppInit#Capabilities# newview/llviewerregion.cpp(330) requestBaseCapabilitiesCoro : Aborting capabilities request, reason: returned to login screen