The main channel got the Le Tigre code Tuesday. The Critical Operating System (COS) updates are being made to the main grid. It is not possible to know which regions are running on COS updates. The COS is an upgrade to Linux. So, it is matched to the hardware not a region. As regions restart they may move to different hardware. More about that further along.
This new function was enabled in Le Tigre last week. The code has been rolled to the main channel this week. I am assuming it is now enabled across the main grid.
Maestro says they are still working with SVC-7289 – llCastRay() returns RCERR_CAST_TIME_EXCEEDED on small parcels. They are messing with the llCastRay() settings. Following the changes, the minimum parcel size needed to do llCastRay() (excluding attachments and vehicles of course) will be 496m^2. That’s only in full regions though. In a homestead, the minimum will be more like 2100m^2, because they have very little available script time.
Some of the timing gets complicated. Regions have a script time pool resource. It seems avatars also have a personal script time pool. See SVC-7290 – llCastRay() used in a rezzed object continues to subtract cast time from the parcel time pool instead of the agent time pool after an agent sits on it and will continue until it has changed parcels. Maestro says that is expected behavior. Maestro goes on to say:
Attachments and vehicles use an avatar’s resource pool and really that’s all an avatar’s resource pool is for. A ‘vehicle’ is an object that you were sitting on that crossed a parcel, so a static sofa will use the parcel pool, but a flying sofa will use your avatar’s pool, in most cases. Well, I guess that won’t be the case if the region is just 1 huge isolated parcel. [paraphrasing] A vehicle isn’t a ‘vehicle’ until you visit another parcel while sitting on it, according to how script/URL/castray resources work.
Currently the avatar pool is 50 µs. Maestro says that will increase to 200µs in the near future.
llGetMass() – llGetMassMKS()
The new llGetMassMKS() has made it to the main grid. (That link will hopefully work someday.)
This new function also made it to the main channel. See llSetPrimitiveParams ().
The set and get of this function made it to the main channel. See llSetPhysicsMaterial().
Over a dozen bug fixes are in the update. llAvatarOnLinkSitTarget(), llSensorRepeat(), and llSetLinkPrimitiveParams() fixes are included.
A new package made it on to Le Tigre. It has mostly to do with your SL Inventory and the SL backend support. This includes moving many if the services from an older system to servers running support for the new Inventory API calls. This should make SL Viewer versions 2.5.1 and newer faster. Third Party Viewers (TPV) based on 2.5.1 code and newer should also see an improvement. Of course for now, you do have to be in Le Tigre regions for it to work.
Also requests for bulk inventory updates and removal of inventory items are moving over to use the HTTP protocol. This is supposed to make purchased item delivery more reliable and will be needed for the changeover to Direct Delivery.
The old code for the old inventory system has been removed. My first question is, has anyone using 1.23 tried to login to a Le Tigre region and update inventory? I suppose it will work.
I asked about whether this upgrade would affect apparent and real inventory loss. We can speculate that it will reduce apparent inventory loss. But, as to real inventory loss no one knows or can even speculate. Tracking real loss stats is almost impossible. As Pauline Darkfury pointed out, if the system knew an item was being lost, it could do a recovery and avoid the loss.
This release channel will keep the Faster Scripts update. Presumably the code from the Le Tigre update has been added to Blue Steel. The newly combined server maintenance and Fast Scripts will test for this week.
There is no information on what upgrade was rolled to Magum. Presumably it is running the same code as last week with the Le Tigre update rolled to the main channels.
As of week 40 this new feature has been renamed and is now enabled on several regions in ADITI. The regions are: Chief, Ahern, De Haro, ImmaculateKapor, Rosedale, Sandbox – Bispinor, Sandbox – Weapons testing, SkyBeam, and Turing Isle. These regions are also running Havok 2011.2.
The upgrade to Havok 2011.2 is coming. For now it is on the ADITI preview grid. This change should make no changes in SL. We should see things continue with any bumps. Andrew Linden is not so optimistic. But, he does think they will get all the bumps out before the update rolls to the Release Channels.
The primary reason for the upgrade is for Path Finding, as announced by Rod Humble.
If you are into testing Havok the rules are the same as for Havok 2010, which are explained here: Havok 2k10 Beta Home. Also Falcon Linden is aware of a problem with the llSetKeyframedMotion() (note the name change) relating to what happens when you select it while the animation is paused. That bug is really a problem with Linden selection code and won’t be fixed for this initial release. But, other than that, Falcon believes it now works more or less as expected.
Much of the work in implementing Havok 2011.2 is code clean up. For Havok 4 several hacks were needed for problems in Havok. Those hacks are being removed. There is some discussion about the hacks in the Server-Simulator-Scripting group.
Some cleanup items are in regard to Havok 1 tree collision bodies. Havok 4 got some other hacks to handle special cases around trees. Any special cases are a programming problem. So, the removal of Linden tress has been considered. I doubt that is going to happen. But, how trees work is probably going to change a bit. How they snap to the ground or not is a likely change.
This week the operating system upgrades or kernel upgrades have been in progress. These are to fix what is known as the TimeWarp problem where a server stalls for 30 to 60 seconds knocking all users in the regions running on the server offline. It appears to the user as a server crash.
TimeWarp was first noticed about a year ago. It was also about then they decided it was not a simulator crash and made tracking tools to learn about the problem. By March 2011 they had decided it was hardware. It took considerable time to eliminate hardware issues. The next possible source of the problem is the Operating System.
The upgrades are being made in small batches and requires reimaging the server, which is time consuming. It seems much of the current progress has been cautious and slow. So, only a small percentage of the servers have been reimaged, like 30 or 40. Oskar and Coyot expect it will take another couple of weeks to complete the upgrade as things will speed up. Other than a minor problem or two that has been resolved, things are going pretty well.
Coyot says the ossm ops team is doing the upgrades. So, it proceeds rack by rack, not by channels. Oskar says there is no way from outside LL to tell which servers have been upgraded.
Once all the servers are upgraded, hopefully the problem will be fixed. If not, the search for the bug moves back to the simulator software.
You may remember that Kelly Linden needed a large number of Homesteads moved into a release channel to fix a problem impacting script performance. This week those Homesteads were being redistributed to other release channels and the main channel.
On Monday Falcon did 3 rolls to move all but 100 of the homesteads out of Magnum channel. Twenty-five went to Blue Steel and 25 to Le Tigre. The rest were moved back to the main channel.
If you have a region that was in a release channel because you wanted it there and it got moved out, contact Falcon Linden.
Jira SVC-7343 – llMinEventDelay
SVC-7343 – This bug that has made it to the main channel is an unintended consequence of another fix. A programming trick for better performance in LSL scripts is to count on the minimum delay time for events to control script action timing. It makes for more efficient scripts. The recent change in some function delays and performance improvements have messed up scripts dependent on event timing. A good example is bullets.
Pauline Darkfury said, ‘It’s product breaking due to people using it as a rate limit on control events (to reduce lag), and assuming the rate limit will actually be enforced (not an unreasonable assumption).’
Mæstro Linden says they have no word on that JIRA yet, but they are aware of it. He thinks they’ll try to fix it in the next maint-server release. That would put the fix reaching the main grid on the 10/18 roll out.
Kelly Linden says he has it fixed. But, will have to check out the Moving_End_Event. That still leave the 10/18 as the roll out time.
Maestro is working with Kelly to get this fix into a release channel next week, 10/12.
800m Ban Elevation
Many residents have stores and other things above 800m. When they ban someone from their parcel the ban is only effective up to 800m. That is going to change soon. The limit will go from the 800m elevation to the max possible elevation, which should reduce griefing problems.
This change does NOT affect no entry zones. It only affects people in parcel ban lists.
Oskar’s 100th Office Hour
This week was Oskar Linden’s 99 Office Hour/User Group meeting. Next week are hoping to think of something fun to commemorate his 100th meeting. At the least we can wear formal attire.