#SL Server News Week 32

There isn’t a lot of news yet this week. I think everyone knows that Pathfinding rolled out to the main channel. You can find most of the information about Pathfinding in the SL Wiki: Second Life Pathfinding  Category. The new Pathfinding Tools are in the Beta Viewer.

It is unclear, at least to me, when those tools will roll into the production release viewer. There is no estimate when the third party viewers (TPV) will have all the tools. I expect the Linden and TPV’s to catch up this month.

Server Scripting August 2012

Simon noted Tuesday that the crash rate for Pathfinding (PF) regions had jumped up after the roll out. But, it seemed to be stabilizing and coming down. I suppose when one adds 5 times more regions the possibility of finding problems goes up five-fold too. Whatever, as of the time of the meeting the Lab was only collecting data and watching the system.

Today’s, Wednesday’s, roll out to the release channels has yet to complete as I write. So, I have no information on how that is going.

The Deploys thread has a number of posts complaining of problems. Some of the problems are region crossings. Until the roll out to the release channels completes the grid is still running different versions of the Havok physics engine. Crossing problems are expected in that case.

Vehicles are reported as behaving differently in various sandboxes in the main grid. I suspect the problem there, is from most sandboxes in the main grid having been moved into the Pathfinding Beta Channel. They may not get updated until Thursday. We can hope they are in the Wednesday roll.

There are more reports of problem vehicles. That is no surprise. During the PF Beta the Lindens were asking for example problem cases. They didn’t get all that many. Of those they got, the problems were in how the vehicles were constructed. Things like wheels being made from tori, which is counter to the best practices information the Lab has provided for years.

Since many older vehicles that were poorly made are not going to be updated, those drivers are now running into the problems for the first time as PF comes to their regions.

Disabling Pathfinding

A number of region owners have decided to disable PF in their regions. Some number of them have yet to figure out they need a PF Viewer to do that. However, once they do, PF will stay disabled through region restarts and server updates. The setting is stored with other regions settings in the region information stored by the Lab.

Some number of people do not understand PF and Havok are different things. Disabling PF does not disable Havok. Disabling PF does not roll back Havok. Once Havok updates to the new version, it is there to stay.

A number of region owners are disabling PF because of performance concerns. Even the Firestorm/Phoenix team put out an incomplete warning, which some consider misleading, regarding PF performance. Most don’t seem to understand or are not taking the time to explain how PF works in regard to performance. I have an explanation in: Second Life Pathfinding Performance and back in May in: #SL Pathfinding Update Week 20. (Scroll to the heading: Size of the Problem)

Until we have more information we won’t know how well PF is or is not performing. In the Beta test the regions were doing pretty well. But, they included a load of debugging code that was expected to degrade performance. Now that the debug code has been removed, or I suspect just most of it, the regions should be near the expected performance.

We’ll probably hear something from Andrew Linden on Friday.

Release Channels

According to the Deploys thread the release channels are to get new packages. Until Thursday’s Beta Server meeting or an update in the thread we won’t know for sure what happened.

Blue Steel & Le Tigre

These channels are to get an infrastructure update. The Lab is not saying what the update consists of. A few comments seem to indicate this is an operating or networking system update. Or it could include hardware replacement. The Lab announced they would be moving to new hardware.


This channel also gets an infrastructure upgrade. It is supposed to be one different from Blue Steel’s. But, the release notes have not updated so it is hard to now. I suppose information would be skimpy if it is mostly a security issue or a change in the software that rolls out the server updates.

Traffic Counts

We are hearing some people complain that their region traffic counts are off.

Traffic counts are done differently SL than they are on the web. The SL traffic count includes a factor of: time in the region. An avatar adds 1 point to the traffic count for every minute it is in a region. That is every whole minute. Factional minutes are dropped. An avatar can add 1440 points per day (24 hrs x 60 minutes = 1440 minutes). See: About Traffic.

Since PF just rolled out, it is getting the blame for inaccuracies in the counts. While I doubt anything in PF affects traffic counting the development process has been known to allow bugs to creep in and problem fixes to regress. So, it is not unreasonable to make the connection to PF.

SVC-8099The Traffic On The Land Is Not Showing Up Correctly In Search Places.

We haven’t seen much use of the HTML style of HUD. It would be nice to see the boring drop down dialogs currently used in the viewer give way to the new possibilities.

10 thoughts on “#SL Server News Week 32

  1. One reason, I think, why so few people make HTML huds is that so many people still use legacy viewers like Phoenix, which simply can’t see HTML on a prim. So unless, like Dari Caldwell with her [H]arsh lines, you’re prepared to make something that offers both HTML and llDialog huds, you’re stuck with llDialog if you want everyone to be able to use it.

    • I had not tried to use HTML on a prim in Phoenix. Thanks for pointing out that problem. Is it the same with Firestorm?

      • HTML on a prim is only available, as far as I know, in viewers based on what’s now V3. That is, everything but Phoenix, Imprudence, Cool VL and Singularity (though I think Henri said somewhere that he was planning to implement it in Cool VL at some point).

        It’s certainly available in Firestorm and all the other modern TPVs. It’s really the fact so many people still use Phoenix that makes it problematic for content creators. That’s not to disparage the other viewers; it’s just a statement of fact that, while it’s one thing to produce something you know (figures plucked out the air) 5% of your customers can’t use, it’s quite another to make something 30% can’t use.

        • In fact, a large part of the MOAP code is already in the Cool VL Viewer sources and just #ifdef-ined out. By adding a couple missing llprimitive source files, I could probably enable MOAP in just a few hours (with a few days to test and debug). So far, two things prevented/discouraged me from implementing MOAP:

          1.- Last time I checked in viewer 2/3, there was a sensible performance impact of MOAP (even when no MOAP objects are around) on the frame rate, and since I won’t use MOAP myself, I would hate to get a slower viewer for nothing… So, while I will perhaps implement MOAP in a near future, I will definitely have to make it switchable (which might make the port more difficult to code).

          2.- Very little people use MOAP: the only widespread use is for TV-on-a-prim, and even there, there are alternatives (parcel media) that make MOAP unnecessary.
          As for HUDs, you can code just as efficient mono-primitive HUDs as HTML ones, using textures and llDetectedTouchPos() (among other functions), so eher again, MOAP is unnecessary…

          • I’m not sure we can get the same functionality from prim HUD’s and touch locations. I make most of my new things using a touch location and LSL.

            But, Javascript could add some interesting possibilities. I have enough new toys to play with that I haven’t taken time to see how well HTML, Javascript, and LSL can work together.

            However, I yet to think of anything I could do with HTML/MOAP that I can’t do with Prim/Textures/LSL.

  2. “A number of region owners have decided to disable PF in their regions. Some number of them have yet to figure out they need a PF Viewer to do that.”

    Slightly incorrect.

    Pathfinding can be disabled using a console command run via the region debug panel, which can be accessed via any viewer, whether or not it is pathfinding-capable.

    However, as you say, whether this actually benefits the region other than prevent pathfinding characters from using it, is very open to question. I’m not at all sure Jessica has helped matters in putting out the Phoenix / firestorm blog post as written.

  3. I suspect many of the region owners are disabling pathfinding out of an abundance of caution. Why have something enabled when you do not need it, especially when it is new and bound to have issues (both with the feature itself and in how people use it). Once pathfinding has proven itself on the greater grid I suspect many of them will turn it back on. That is what I would do in their place.

  4. Pingback: Script limits enforced on no-script land? wtf? - Page 8 - SLUniverse Forums

Leave a Reply

Your email address will not be published. Required fields are marked *