Server Bugs

HTTP warnings

When creating a new group notice, the Subject input accepts up to 64 characters, and the Message input box accepts up to 512 characters. These are faithfully relayed in their entirety when the notice is sent. When viewing past group notices using the group inspector, the title's length is counted toward the length of the total message and must be under 512 bytes to be shown in its entirety. A max-length Subject and max-length Message will be 576 bytes in length, truncating the Message to only the first 448 bytes. (I think there may be a linebreak added in there too, eating up even more of the maximum length.) As someone who regularly writes fairly lengthy group notices, this is incredibly annoying and has bugged me for years. I'm guessing based on the nature of this bug that this is a database field that is too small rather than merely a UI problem. It might also be a protocol problem with how the group notices are sent when the viewer queries them. If fixing the backend is infeasible, I would prefer to have the input box shortened to 447 bytes, to prevent problematic user input. (I'm sure someone will come along soon proposing that Premium subscribers should be able to send longer messages. That elitist brainrot should be a separate feature request. This is a real bug that has been around since the dawn of time and seems like it should be easy to fix in several different ways.)

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

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.

Teleports between regions will sometimes (but fairly frequently) fail, causing the viewer to timeout and disconnect. I will try and log when and where this happens, and update where possible. This is what I have so far: User: Quinn Elara 7/12/2024 - 14:55 GMT / 06:55 PST, FROM REGION "TOKYO ZERO" 7/12/2024 - 15:25 GMT / 07:25 PST, FROM REGION "Vanilla Bae" Format: dd/mm/yyyy

CONTACTS Friends list on/offline still unreliable after a whole year

Even though scripted agents are blocked with a checkbox on the region estate settings. There should be a second checkbox that allows ConvAI bots in even when the prevent scripted agents checkbox is set. That way region owners can keep scripted agents out but allow ConvAI bots to visit. Update: Alternatively, a "Capabilities" concept could be provided for scripted agents. This would be similar to how phone apps have to declare which features of the phone they need access to, and then when users install an app they can decide whether they want to continue installing and allow those capabilities. In other words, you'd still only have 1 checkbox on the estate management for allowing or disallowing scripted agents. But, then there would be button that opens a separate dialog if scripted agents are allowed, that displays a series of checkboxes for the region estate manager to decide which kind of bots they would allow. By default all these checkboxes would be enabled until the manager unchecks them and hits apply. Examples of capabilities; tracking users, conversational (convai), land/group moderation (e.g. smartbots), etc. I guess the only concern would be, bot owners could lie and declare the wrong capabilities and there'd be no way of LL to know. Whereas mobile device companies are able to scan the code during compile-time for usage of certain API. I'm not sure how to really solve that, unless LL has a TPV-like gatekeep registration process where only certain companies are allowed a specific capability, e.g. smartbots are known to only do land/group moderation and are trusted so they'd automatically get access to providing the moderation capability, and convai bots LL is providing are already trusted to only provide conversational responses when prompted so they'd receive that capability. Also, possibly LL could require that the code for their scripted agent be on github and presented for review, to verify capabilities. If a company has a proprietary scripted agent and refuses to allow reviews of the code, then there could be a Capability called "Unreviewed / Proprietary" and that category is understood to mean that LL has no way of knowing what the scripted agent is up to, but at least the region managers are able to decide if they want to risk allowing those or optionally then disallowing them but allowing others that have declared their capabilities and were code reviewed. Regardless how it is implemented ultimately, having this as a separate dialog and set of checkboxes would provide for more types of bots to be whitelisted based on capability. Whereas my previous suggestion above was a specific checkbox only for convai and didn't take into account the vast variety of other types of scripted agents available.

I am a founder of a group called + Pandemonium + (secondlife:///app/group/78f0ac10-5b9e-a797-7871-bbbb7a3e542a/about) Some of our members are having strange symptoms whenever they are trying to start group chat. Symptom 1: This group member was once ejected, but rejoined. eversince, this group member is unable to join group chat wtih the following message: error message: "Unable to start a new chat session with + Pandemonium +. Please close and reopen the conversation, or relog and try again. image: https://ibb.co/tmGZdyB I checked this group member's setting but I don't find anything suspicious that would prevent him from chatting: image: https://prnt.sc/sJgIqydPYsmc I am also curious if the person may have been muted from speaking in Pandemonium Group Chat, but there is no way I can Allow or Forbid Chat in the group unless I see his name on the group chat. In order to investigate this issue, here are things I have tried to see if he can start group chat. The problem is, this is also happening to some other people. Resident having this issue for example: a0a62489-3ff1-4fd6-9fe1-d32f1ed23934 Cleared cache, and completely reinstalled the application. result: still having the issue Tried to teleport to different regions and started the group chat: result: still having the issue Happening on both Firestorm and Standard viewer Symptomp 2: This group member is experiencing sudden conference chat opening in seperate view whenever he starts the group chat. image: https://gyazo.com/d8f5e1b73e45e53dc09cf8fa23ac39a2 As you can see from the picture, this conference chat suddenly opens up whenever he tries to start the group chat. Note that he has an officer ability. oddly enough, this is what he sees on his group window: https://gyazo.com/2bec64109519cc90a05772208d5dcc5e resident having this issue for example: f98d4ce6-8d1f-49bc-8342-d8cf86b718c1

Chatting with people and all seem normal (no idea you missed messages), then I get the IMs which match the what would had been said around mid conversation delivered at a later time when relogging (or even in email with the setting enabled).