The code from the Magnum release channel has rolled to the main grid. That means, according to Simon Linden, we now have the new function llSetRegionPos() available across the whole grid. The existing function llGetEnv() gets the new return value frame_number. Plus a bunch of bug fixes. You can see them listed in previous Server News articles.
This release channel gets the performance enhanced server maintenance package. The big news is in the speed up of LIST handling functions.
This is the functions’ second time in a release channel, if I remember correctly.
For some time the Mini Map has been showing avatars at elevations above 1,000m as being below you. That has been fixed.
A problem with the Mini Map is in how elevation is conveyed to the viewer. It’s supplied by a process called Course Location Updates. The process only handles elevations between 0 and 1,000m. So, when you and other avatars are above 1,000m the map is unreliable as to who is above or below.
The code improves memory management and object updates. A crash problem with llList2List(), the improved version, has been fixed.
Le Tigre and Magnum
Both of these channels are running the same code as Blue Steel.
This is sort of out of place and off topic but, take your information from any reliable source you can find. Whatever, recent versions of the Lab’s viewer have memory leaks. The latest Development Viewers have memory leak fixes. The problems are at least partially fixed.
The main and Beta viewers are using the leaky code. If you are crashing and suspect a memory leak, change to the Dev Viewer. I’m on 3.2.9 (248680). I’ve used it for about a day and it seems to work well.
Some can still crash the viewer by taking about 20 high-rez photos. When you get the crash may depend on how much memory you have in your computer.
If you use FRAPS for your screen captures, you may notice it failing to work …some times. This happens when the memory leaks hit a certain point.
VWR & SH JIRA
In the JIRA we have projects. Bugs are assigned to a project. The trick is assigning your bug reports to the correct projects.
VWR is the viewer project and I think includes the Development, Beta, and main viewers.
SH is the Shining project. This is the one Runitia Linden is working with to fix the OpenGL compatibility issues and I suppose other render pipeline issues with memory and mesh. One would only place bug reports in the project if the are using the Shining Project viewer. The rest of us should be reporting viewer bugs to the VWR project.
SVC-7348 – moving_end() event executes on moving, script-rezzed physical objects. This fix is in the Blue Steel release channel. You can test it in the Blue Steel sandboxes. It is probably important to weapons makers.
SVC-7443 – Telehubs overridden if teleporting a friend/avatar to a region where telehub exists outside of the telehub area. Fixed.
SVC-7386 – Transaction failure due to Linden’s Internal error. Simon Linden hopes he has this one fixed. It has not made it to a release channel yet, may be next week.
Significant changes are coming to the region crossing process and how the Lab’s servers deal with it. Phase 1 has been in testing twice. From Week 4 news we know it was in the Blue Steel release channel. Its release channel, Blue Steel, did NOT roll to the main grid. The code with the crossing foundation changes was replaced with a different maintenance package. So, as far as I know the Phase 1 crossing code is back in the QA testing.
Simon said, ‘…the changes there are pretty ambitious – I don’t think they will do much for the crossing times, but eventually the lag caused to everyone else should get better.’
This function has been in a tuning phase. Griefers have decided it is a handy addition to their repertoire of problem making tools. The Lab is placing a throttle on the function. Meaning the number of times it can be used by scripts owned by the same person has changed.
This change has an effect on many businesses. The Lab understands that. But, the throttle is needed to provide the backend of the Second Life. The function has apparently been used to lag out the utility servers.
We are seeing some people bitching about the change how the change was implemented. Some one is complaining about how the Lab communicates. Shocking, huh?
Kelly Linden said a couple of things about it. One is the griefing issues were having a large impact on the system. Also, the limits are identical to the IM throttles.
Kelly says a limit is a burst rate of 2.5k gives/30 minutes per person per region. (That is a composite of statements, not a quote, so I may have it wrong.) Quoting Kelly, “2,500 per 1800 seconds should be the safe limit: this is for all objects you own in the region. … 10k sends from a single owner/region in 16 minutes is really not a rate we [the Lab] can support. … For our back end systems it IS a problem when you send 2-10 items to 10k customers in only a few minutes. … It has recently developed into a severe security and stability issue.”
Simon says, “We realize this change can cause problems, but it unfortunately had to be done. We had some serious system failures in the past few months due to the griefing problems.”
Some are reporting that they are hitting limits much earlier. It also seems the ‘per region’ limits may have some ‘per person’ affect from other regions. Some hit the limit at 2-gives/sec and in other regions at 8-to-10-gives/sec.
Whatever, those that use llGiveInventory() for their mass mailings are going to run into problems. We’ll hear blow back from those people as it is a significant problem for their legitimate uses.
Fred Allandale says he has had 1,500 mailing list kiosks on the grid set to send 10-gives/second running for 3 years. This throttle is breaking those. Fred is hitting the limit at 15-gives/sec. Kelly says that is a bug and is looking at it.
The llGiveInventory() function is being used to implement a mailing list process by users. The Lab did not design or optimize the Inventory System for that type of use. The Group Notice system was designed for a mailing list type function. But, SL users are not using it for their mailing list tasks. Which suggests something in Group Notices does not meet the needs of the task.
I have written about several problems with the Group Notices processes and the problems with large groups.
It has occurred to Andrew Linden that there is a significant and justifiable need for a mailing list system. Obviously one that works for these legitimate needs. He speculates about: Maybe we need a new inventory item type which represents a mailing list, to which people can subscribe.
Simon speculates on whether the new Direct Delivery system can be used to provide for the mailing list needs.
This mailing list problem is going to take some thinking on the Lindens’ part. We are going to hear all sorts of blow back and probably lots of rants from the poorly informed. It will also likely be some time before we have a usable solution.
In the mean time delivery of mailing list items is going to slow. We will have to figure out how that affects us and prepare.
If you use mailing list devices, you will probably find them stalling out. Talk with the people that made them. The temporary fix is probably going to be to turn down the send rate. One can also divide the lists up and send parts of the lists from other regions and other alts. It’s a pain. Thank your local griefer.