There are some interesting threads appearing in the SL Forum.  Most of the most outraged are people that don’t follow events or know the history of history of Second Life™. There are a few us trying to help those people. But, if they keep their heads buried in what they are doing and only in their primary interests, we can’t do much for them.

If you’re reading this blog and/or Inara’s Living in the Modem World, you are pretty well informed. I think we provide more news than you can get from the SL Forum and Blog. This morning I saw Inara’s: Pathfinding overview. It is a good overview/summary of Pathfinding.

The Problem People

Many of the vehicle makers have used a hack to create lower Land Impact vehicles and to get around other limits. Now they are crying about vehicles using those hacks being broke. I guess they did not include a script updating process either. I use DCS2 and UCE game meters and they send me a new boxed meter whenever they have updates. It is an easy process for them and me.

The thing about using hacks is the Lab doesn’t support them. They also regularly warn people and consistently say not to count on hacks. It is true that some hacks are eventually incorporated into to SL and others are just worked around by the Lab. But, they make no promises in those regards. So, one might think those smart enough to build with hacks and making a choice to use them would be smart enough anticipate future problems. But, that may be overly optimistic on my part.

History shows that changes in the Havok Physics Engine causes problems for vehicle makers. It would seem vehicle makers would be in the middle of any Havok upgrade making sure things worked. A number of vehicle makers do get involved in beta projects like Pathfinding. I do notice they are now the ones providing help to those lamenting the failure of their vehicles.

I have far more empathy for the customers of broken vehicles than I do for their vehicle maker. I also have no doubt the ‘makers’ will be blaming the Lab for their problems. My hope is they learn something constructive.

For most of us it is a simple matter of learning who is an experienced builder BEFORE we buy… I said ‘simple’, not ‘easy’.

Goofy Expectations

We often expect things to be different than they are in reality. I can’t imagine a human that hasn’t been surprised when reality bit them in some way. I find this happens most often in the parts of my life where I am least knowledgeable.

Many people seem to have no clue that Pathfinding as implemented in SL is a first. Even the Havok people are watching to see how it goes. Dynamic Pathfinding as implemented in SL has NEVER been done before and as such drew comment from Havok.

Never has any game maker allowed users to have real time editing of the Navmesh or even in game modifying of the Navmesh while building things. We are doing cutting edge tech. Expect problems.

Those that think all the problems should have been solved before release simply don’t understand software development at the cutting edge.

The Fix

I saw a thread where Innula Zenovka was helping out. She provided some good information and a script to help with the problem some vehicle creators have gotten into.

She quotes Falcon Linden:

1. If a linkset uses the hack and also uses new accounting (aka mesh accounting or land impact), the first time it is rezzed on a Pathfinding sim the hacked prim will be set to physics shape type none. Since the linkset already uses new accounting, this will not negatively impact land impact (in fact, it might reduce your land impact). It may affect a small amount of content that relies on link number of higher numbered prims in collision events by way of llDetectedLinkNumber()
2. If a linkset uses the hack and does NOT use new accounting, the relevant prims will be modified such that they collide only with the terrain. Other than that, behavior should be unchanged. This may impact some land vehicles that previously had hacked phantom prims which did not collide with the terrain.
3. No new linksets can be created that use the hack, and any linking or unlinking event (other than seating an avatar) will remove the hack on existing content.

In another post she provides a script saying (I’ve edited for clairity):

According to Falcon Linden’s comment on PATHBUG-69 of 21 April, this should remedy itself automagically the next time you rez one of the aircraft.

If it doesn’t, the remedy is to convert the whole linkset from prim physics type prim to convex hull (on the features tab) and then to use edit linked parts to convert the sculpties you want to [be]phantom to physics shape none.

I recommend doing it this way round because, if you leave any prims as prims, the LI [Land Impact]risks going through the roof.   But changes to the LI accounting system introduced to accommodate precisely this problem mean that, so long as everything’s either convex hull or none, the LI should be no higher than it was before and may even be lower.

If you simply need to convert all the child prims in the linkset that are sculpties to phantom, this should do the trick:

//converts whole linkset to convex hull and then converts all child sculpties to PHYSICS_SHAPE_NONE, effectively phantoming them

default
   {
   state_entry()
      {
      llSetLinkPrimitiveParamsFast(LINK_SET,[PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_CONVEX]);
      integer max = llGetNumberOfPrims()+1;

      while(max-->1){//don't try to convert the root to PHYSICS_SHAPE_NONE
      if(llList2Integer(llGetLinkPrimitiveParams(max,[PRIM_TYPE]),0)== PRIM_TYPE_SCULPT){
         llSetLinkPrimitiveParamsFast(max,[PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]);
         }
      }
      llRemoveInventory(llGetScriptName());
   }
}

 Just drop it in, and it will do the conversion and remove itself.

You can find out more about the history and suggestions for fixes in: PATHBUG-69 – llVolumeDetect(TRUE) is broken.

PATH-483 – (Not publically visible). See Maestro Linden’s post in PATHBUG-69, which explains this JIRA item. Watch for both 69 and 483 in release notes and other Linden statements.

Summary

Second Life is a place where people learn 3D modeling, scripting, and other aspects of virtual world construction. Many are completely new to the ideas many of us now take for granted. For instance having an easy upgrade or repair path.

The idea that doctors have to keep up with their profession is pretty well known. That citizens have to be informed about political issues before voting is pretty well accepted, if not practiced. Life in SL is no different. So, I suppose creators will always be somewhere on the learning curve. That means that we will always have people running into walls and making mistakes. That is life. The problem is in how we handle the mistakes, accept responsibility for them, learn, and move on …or… skip the learning and blame others.