Server Bugs

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 have searched for previous reports on this subject, but not found anything. Sorry if it has been discussed before. This is not recent, it has been around since I've been in SL. People complain about it, but why can't it be sorted out? If you fly or sail a vehicle solo though a parcel where vizibility has been turned off, nothing happens to the camera position that has been programmed into the vhicle. But if you fly or sail with a friend or friends all sitting on the same vehicle, then the programmed vehicle cameras get messed up as you enter, and as you leave the parcel where parcel visibility is turned off. As many estate islands have navigable water around them, and some estates (such as Tuarua Fiji) renting full sims, half sims and quater sims to residents, where some have vizibility on, and others have vizibility off, this is a real pain to sail though with friends on the boat. You have to reset the boat camera on entry, then reset it again on exit. Is there no fix to this issue that can be applied to the sime, or automated in the boat scripts? if there is something, I'd gladly add it tothe vhehicles that I build.

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.

This peculiar issue came about when I linked an extractor fan to mesh wall, the wall has an opening. Initially all seems well, however if you shift-copy the object the opening is now solid. If you right click, without even going in to edit it becomes open again. This behaviour also shows if you take the object in to the inventory and re-rez, plus I suspect it may explain why the build became mysteriously solid after the weekly rolling-restarts, again correct by merely right clicking. This issue occurs on both the latest release viewer and Firestorm beta viewer. The reason I suspect it's a server side issue is I believe that collisions occur server-side and, of course, llTargetOmega for a child prim should be a client-side viewer effect only. I have tested this with... Mesh>rotating mesh child object <<< occurs Mesh>rotating prim child object <<< occurs Cut prim>rotating prim child object <<< does not occur There is a temporary fix which I can apply to this build but not to others. If you perform a simple analyse, with default options, the behaviour goes away. Unfortunately I cannot do this with a significant amount of my other work as analyse produces an object that is unusable in its intended form and, of course, analyse is "optional" In all tests I have used an LOD3 mesh with a matching PHYS model. The code in the script was simply: default { state_entry() { llTargetOmega(llRot2Up(llGetLocalRot()), PI, 4.0); } } Incidentally, I also tested by putting in a 10 second timer, when the time event is triggered it fires the llTargetOmega and immediately the building becomes solid. And for one final test, I reversed this, I started with the child prim rotating and after 10 seconds stopped it and it was solid whilst rotating and walkable the instant it stopped: default { state_entry() { llTargetOmega(llRot2Up(llGetLocalRot()), PI, 4.0); llSetTimerEvent(10.0); } timer() { llTargetOmega(<0.0,0.0,1.0>, 0.0, 0.0); llSetTimerEvent(0.0); } }

I am a Premium member, but I got a message when I logged in yesterday that I had too many IMs and they were capped, even though I had only 29 Notices and 2 IMs waiting for me when I logged in. I would have been at my skybox in Morning Shire, where I usually log in. I didn't think to take a screenshot at the time; if it happens again, I will add that to this report.

I am consistently not able to open attachments from Group Notifications. If the group notification was sent while you were offline, this occurs. IF you are online and open the notification you just received, it will work as expected. Sometimes it will display that the object has been saved to my inventory, however it does not. You can go into the Group Notifications in the Group floater to open it that way as a workaround. This issue is present in all viewers I have tried, and research I have gathered from other third party viewer devs indicates this is most likely a server-side issue.

I crashed last week and all my scripted attachments got broken and turned to off position. I had to reset them and turn them on to make them work. No mod ones are unable to do this, so I had to replace them. Then after I fixed all that, not long after, this has now happened again on a disconnect during teleport. I went years without issues, so in theory this is a new server side bug that has appeared somewhat recently. I was on firestorm, but that shouldn't matter I don't think since the objects themselves are broken. I hope this is fixed because its very stressful to have to redo all my outfits every time I crash if this is how it will be going forward.

i maintain a set of extra root folders in my inventory - for example, Purchases, Events ... I was surprised to find that on the beta grid, they had all been moved into a root folder called My Inventory.

If you have too many folders in the root folder in inventory, it may cause login timeout in the viewer: request to https://login.agni.lindenlab.com/cgi-bin/login.cgi with inventory-skeleton option returns too much data (1.6Mb and 3121 folders in my case), and sometimes it responds very slowly (more than 40 seconds - default login timeout in the viewer). How did I know that? I intercepted request using mitmproxy and tried the same request using curl.