There was lots of interesting news at this week’s meeting. Check these things out.

Roll Outs

Surely by now you know the main grid gets new server software Tuesday morning. The Release Channels get new software on Wednesday. This week the main grid got the the Server-Maintenance update running on Blue Steel.

Data Collection

The Lab is doing lots of analysis of the regions to find bottlenecks and problems. This roll includes new data collection features. One of the more confusing and hard to find problems is labeled TimeWarp. The Lindens think they have found the problem, at least where the problem resides. The additional data collection will provide more information on many aspects of the Second Life servers and reveal more about the TimeWarp problem (more on that later).

Unexpected Prim Return

The addition of Land Impact costs has created some surprising situations where region prim limits are hit and prims get returned. Changes made by scripts can change object shape and trigger a Land Impact value and trigger returns.  A feature has been added to the Linden Scripting Language (LSL) to anticipate such changes and prevent them. I think the idea is to return an error message in the script error channel rather than allow the change and trigger returns. Nice idea.

Land Impact Costs

This is going to be a fact of life in Second Life. The grid now has new server side coding to help reveal the resource costs of things in SL. As the viewer is updated we will be able see and understand more of the Land Impact (LI) costs and how changes affect the costs.

People are starting to figure things out in regard to LI. A person in one of the threads in the forum describes how he stumbled on a way to reduce the Land Impact cost of the homes he builds by a factor of 10, thus making large object builds with mesh advantageous. At some point I’ll figure out how that works.

Crashes and Stuff

I think every Server Maintenance update includes fixes for crash problems. This one does too.

More region crossing fixes are included. I think these are mostly about vehicle crossings but I’m not sure.

A number of fixes are mesh related.

llCastRay()

This feature has made it to the main grid. I am currently confused about this item. I think llCastRay() is only enabled in the Release Channels. However, the Deploys post on the forum seems to indicate the roll was to the main grid. But, from the meeting information I think it is only on the release channels.

For those that have been waiting for this feature this is good news. I doubt the feature is going to have as much effect on weapons as I initially thought. Whatever the case, it can now be tested.

If you have a neat use of llCastRay(), let Oskar Linden know.

llRemoteLoadScriptPin and llGiveInventory

SVC-7283 is a fix for problems with both of these functions. That fix has made it to the Release Channels on main grid. Each channel is a bit different. Blue Steel has the fix and last week’s server fixes. Le Tigre has the fix and new server fixes. Magnum has the fix and changes/fixes for the permission system and simulator configuration system. This means any testing should be conducted in all three.

Placing the fix in all three channels is unusual. Oskar says there is some risk in placing a rushed fix in all 3 channels. The project heads of the projects involved decided the risk is worthwhile. The idea is that whichever release channel rolls to the main channel next, this fix goes with it.

The risk is that if the fix fails, all the other fixes fail and nothing roles to main channel.

Those regions affected by the problem have been moved into the release channels. So, this week and over the next couple of weeks we will see some shuffling of regions in and out of the various channels to restore equal distribution. Magnum is a bit large for this fix and a Kelly Linden test. The problem with shuffling is that some regions may have to be restarted twice. We can expect some people to be annoyed.

Permissions

Lots of work is being done to test all the possible permutations for the permissions system.  There are about 1,000 permutations to test. The idea is that with the testing system well done, future problems like the llGiveInventory one can be avoided. The current smoke testing did not catch this problem. Future smoke testing will have a better battery of tests for permissions.

An example of one permutation, or combination, is: a full perm prim with no copy prims inside of it.

PRIM_PHYSICS and llSetPrimitiveParams

Two or three people have reported that llSetPrimitiveParams now has a problem in the release channels.

Secret Projects

Yes, there are secret projects and they are secret. :/

Oskar just likes to tease us. But, he does says there are secret projects that are unannounced. Coyot Linden says some of them are awesome. So, we can speculate and wait.

TIMEWARP

This is a problem that has been around for months, verging on a year. This problem appears and disappears. It has been a confusing  problem and difficult to diagnose. So, it has remained.

TIMEWARP manifests as a simulator stalling for 30 to 60 seconds. The logs and all reporting simply stops and then resumes. Everyone in regions on that simulator are logged off the system. The problem has been followed into the Linux kernel. On the ADITI grid the Linux OS was upgraded and more tracing and logging added. The Lindens think they are getting a handle on the problem.

One of the significant problems is the current update process is for updating the simulator software, not the Linux operating system. Since the update has the possibility to fail and take down the simulator the fix and the process to roll the new Linux OS out need to be tested very well.

It seems that in addition to the simulators the subsystems are also being upgraded. Lots of time and money have been spent on this fix.

We should see the fix roll to a release channel soon. I am guessing weeks.

Oh… and there is no truth in the rumor that simulators hosts are changing to the Facebook App Engine. SL will remain 3D.

 llSetKeyframedAnimation

See llSetKeyframedAnimation. (Be sure you look at the discussion page too) This feature was discussed and open testing announced last week. Falcon was hoping to get it live in a couple of ADITI regions last week. As best I can tell that did not happen. There are now two ADITI regions with the feature active. Visit: “Sandbox – Bispinor” and “Sandbox – Weapons testing“.

The wiki has an example of how to use this new feature. The idea behind it is to proved better elevators, trains, buses, and other things that move in Second Life. Avatars will NOT have to sit on objects to move reliably.

In platforms like Unreal and CryEngine I think the same idea is labeled movers.

Falcon is dealing with time constraints. So, several issues with the feature are not going to be fixed before roll out. So, when reporting bugs know anything other than a Show Stopper is unlikely to get fixed.

To be classed as a Show Stopper bugs should either; break existing content, be a misfeature that would stop future enhancements, or make the feature unusable for the intended purpose.

Add behaviors not listed in the wiki to the wiki article. There are features and behaviors that Falcon has not had time to document. Thaaasssaa feature not a bug…

Report bugs in the JIRA’s scripting project.

There are known issues. The wiki says:

There are a few bugs in the avatar animation system that may cause strange looking animations to play when standing on a moving platform (e.g., walking in place, feet-at-pelvis). We hope to fix these in the future, but doing so is out of scope for this feature.

Oskar says he will send an email in the mailing list and post in the forum. I found this thread this morning: llSetKeyframedAnimation() getting closer. I don’t see an Oskar post in the thread, yet.

One of the things to consider with the use of this function is that it uses, or incurs, a Land Impact cost. It seems the idea of script limits is being implemented in a way few have anticipated. I think this foreshadows the future for Second Life. We will likely see more new things that factor in the Land Impact measure of resource consumption and incur additional cost for scripts.

‘Additional’ may be inaccurate. Just as we are finding that Land Impact costs for efficient mesh builds is reducing cost, we may find that there are similar efficiencies in scripting. However, we may only see them as less lag and better performance. It will be some time before we know.

Kelly Linden doubts all new LSL functions will have an LI cost or make things dynamic and trigger an LI cost. I suspect those that create or increase the server’s workload will incur a cost.

Speed – there is a speed limit associated with this feature. I don’t understand how this works and have yet to play with this feature. So, I guess a rail-gun is out.

Summing Up

This has been an interesting week and hints reveal there are new things coming. I think we are starting to see how some features will use the new Land Impact and Resource Consumption system.

Some old problems are nearing resolution. A round of stabilization and fixes after the mesh release is completing. People are working on new projects.

Things are moving forward.