Maestro Linden

Hi MB, there was a performance bug in last week's Magnum version which could cause some of the symptoms you describe: https://jira.secondlife.com/browse/SVC-7011 / SVC-7009. If you still see performance issues with the new version, could you please file a Jira report about the problem?

Hi Adrienne, it looks like your group role title was truncated badly, with a 2-byte character being sliced in half, resulting in a corrupt character. This is a known bug. I've fixed your case, so you should be able to login now.

Hi Arielyn, I believe you're seeing fallout from this bug: https://jira.secondlife.com/browse/SVC-7004 Essentially, last week's simulator on Magnum was undercounting the number of prims on a parcel, so it was possible to rez many more prims on the parcel than would be possible otherwise. When the SVC-7004 fix went out this morning, parcels which were overloaded returned their excess objects. We're sorry for the stress caused by this bug!

Hi Void, I haven't heard of a bug about region status reporting. If there isn't already a Jira issue about this problem, could you make one? For what it's worth, I had a script run llRequestSimulatorData() with DATA_SIM_STATUS against a remote region just before it rolled, and it appeared to report the states (up -> stopping -> down -> starting -> up) correctly, as the sim restarted. So far, it looks like today's deploy of Second Life RC LeTigre will get promoted to the main channel next week.

Hi Hitomi, are you still having issues accessing the Magnum Sandbox regions? My Tester is able to TP to them, and some other avatars are also in those regions. Perhaps you tried to TP to them just as they were rolling?

Hi Innula, the fix for SCR-66 is currently in Second Life RC LeTigre 11.05.11.229644. This fix will probably be on all regions in 2 weeks, barring any unexpected changes or bugs.

For reference, there was a widespread outage this morning: http://status.secondlifegrid.net/2011/05/11/post1292/

Hi Argus, it looks like van Eyck is in the RC LeTigre channel, which skipped the server version with this physics bug. I suppose it's possible that a horse in a neighboring region (like "Nick Rhodes", which is in "Second Life Server") escaped from its skybox pen and flew/fell into your store. For what it's worth, the main issue I saw with the Amaretto horses is that they walk about 3x faster than normal.

Due to physics issues with certain objects, such as Kardargo's karts and the Amaretto horses, we will undo the original fix for SVC-5880, which entered the "Second Life Server" channel today. A new server version has been built, which removes the original SVC-5880 fix, and also fixes a crash mode related to object deletion. We plan to deploy this new version to all 3 server RC channels tomorrow morning. The other two release candidates hit some last minute issues during beta testing and missed the deadline for RC. In case anybody wants to check out this week's RC before tomorrow's deploy, it can be found on Aditi (the 'beta grid') right now, with version 'DRTSIM-55 11.05.03.228703'. This server version on the following regions: Aegean, Adriatic, Azov, Badnarik, and Dore.

Hi Astarte, are you still seeing the problem? I just tried to TP to "Raptors Reef", and arrived in the region successfully. It appears that the sim has been up for just over 5 hours.

Hi Pauline, there actually are some big object derez performance improvements in mono2performance 11.04.26.227666, compared to what's been on RC LeTigre this past week. This version is lined up for tomorrow's RC LeTigre update. Object rez performance has only improved modestly since last week's mono2performance build; we are still working on it.

Yes, LeTigre is getting moved to the same server version as "Second Life Server". We saw a bunch of (previously unseen) Mono-related crashes in certain regions, which were almost certainly caused by the mono2performance upgrade - this prompted the rollback.

Hi Zena, are you seeing the "UThread Injection" error when saving any scripts (even a default 'Hello Avatar' script), or are you only seeing it with certain scripts? If the problem only applies to certain scripts, could you send me a copy of an affected script? Otherwise, if all scripts are failing to compile, which region(s) are you seeing the error in?

Hi Ayesha, my best guess about your texture loading issue is that HTTP texture fetching somehow got disabled after you TPed, causing the viewer to use the legacy UDP fetching method instead, which is slower. The official 2.5 and 2.6 viewers have viewer metrics logging which could prove or disprove this theory (by providing details about how texture assets were fetched), but I don't think Phoenix 1.5.2.977 includes that feature. The Magnum RC channel has had the "Estate Transfer Limits" project for the past few weeks, which shouldn't affect texture asset fetching (the changes are mostly for preventing IMs and object transfers for 'special' accounts). This project was promoted to the main channel this morning, so it would be interesting to see if your texture fetching speed issue goes away or becomes more widespread.

There were some questions on the server-beta mailing list about the impact of the inventory changes on Bluesteel. This was my reply, in case anybody here wants to know: While the new BlueSteel RC server accepts gzip encoding, the current release viewers do not take advantage of this. A viewer-side change to request gzip encoding will hit viewer-development sometime soon. That said, there are fewer "moving parts" to inventory fetching in the new BlueSteel RC version, so fetching inventory using the newer Inventory API should be more slightly more reliable than before. As with earlier server versions, you will need to use a viewer that supports the new capabilities (FetchInventoryDescendents2 etc.) in order to access the newer Inventory API, such as viewer 2.5.1 or later.