Pathfinding: llVolumeDetect(TRUE) and Land Impact changes

There are a couple of changes in the works relating to the forthcoming arrival of Pathfinding in Second Life.

llVolumeDetect(TRUE) Exploit

In the first, the use of llVolumeDetect(TRUE) to create partially phantom linksets will no longer work. Always something of a system exploit / hack, this approach has nevertheless seen widespread use across SL in buildings and vehicles. So much so that when it was discovered that the hack no longer worked in the Pathfainding test regions, it was initially reported on the JIRA as a Pathfinding bug (Pathbug-69).

However, as Falcon Linden points out in the “bugs” JIRA:

Thanks for your interest and passionate comments. First, let me address one of the root issues here: reliance on undocumented behavior that is known to be a bug. I realize that there are many cases of this in SL. I also realize that all of us, as game developers either in RL or SL, will do whatever it takes to implement a feature we want, even if that means exploiting known bugs or idiosyncrasies. The problem is that continued development of a platform (e.g., SL) often precludes backwards compatibility, particularly when systems have exploited “micro details” of the platform. 

Which is not to say Linden Lab is unsympathetic to the issue. Far from it; as in the same statement Falcon goes on to explain:

All of that being said, we as SL developers continue to try to preserve backward compatibility where we can. In this case, I have been able to find a compromise between new features and existing content. Here’s how it will work:

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.

This should address most of the concerns here. In the future, to create content where only some prims are involved in physics collisions, you will have to use the physics shape type feature.

Ergo, while the arrival of Pathfinding will herald a closure of the llVolumeDetect(TRUE) exploit / hack, LL are attempting to ensure that the impact of the closure in terms of content breakage will be minimal – if it is noticed at all.

Changes to Land Impact Calculations

Coupled to the above change is the announcement that Linden Lab is looking into changing how Land Impact is calculated as a part of the overall Pathfinding roll-out. Nalates Urriah was the first to break the news on the proposal, which  will bring a greater degree of granularity to Land Impact increases.

Under the current system, adding scripts to linksets can result in a sudden (and sometimes dramatic) leap in the Land Impact value. With the proposed changes, this will no longer be the case, with changes resulting from the use of scripts being more gradual. Speaking at the Simulator User Group meeting attended by Nalates, Falcon Linden explains the proposed changes thus:

[17:00] Falcon Linden: Changes to Land Impact that you’ll actually like for a change!
[17:01] Falcon Linden: We’re changing streaming cost for prims to be capped at 1.0 and we’re changing server weight to be: 0.5 * num_prims + (0.25 * num_scripts) but capped at num_prims
[17:01] Falcon Linden: so instead of going from half prim count to prim count by adding one script, it will be a more gradual change to encourage fewer scripts
[17:01] Falcon Linden: right now it’s not capped 
[17:03] Falcon Linden: okay
[17:03] Falcon Linden: here we go
[17:03] Falcon Linden: I have here a linkset of three distorted torii
[17:03] Falcon Linden: The two child prims are shape type NONE and the root is convex hull
[17:04] Falcon Linden: under the current scheme, its download weight is 13.7, its physics weight is 1.6 and its server weight is 1.5
[17:04] Falcon Linden: total LI 14
[17:04] Falcon Linden: under the new scheme, download weight will be 3, the other weights will be the same in this case, and the overall LI will be 3
[17:05] Falcon Linden: if I add one script to it now, the server weight will go from 1.5 to 3.
[17:05] Falcon Linden: In the new scheme it will go from 1.5 to 1.75.

It should be noted that the latter change is still very much a proposal, although it does appear that it is more than likely to go ahead, given it is beneficial to both Pathfinding and the platform as a whole.

With thanks to Innula Zenovka.

6 thoughts on “Pathfinding: llVolumeDetect(TRUE) and Land Impact changes

  1. These PE/LI changes make sense indeed. Hopefully they come to be implemented like that, The current system simply does not allow the use of the new physics engine features, like setting parts of a linkset to phantom.

    Like

    1. Falcon pretty much acknowledges that, and from what Nalates indicates, there seems to be pretty strong consensus on the changes. So fingers crossed!

      Like

  2. /*
    Phantom Linked Prim – Working on Pathfinding Sims 🙂
    How To Use:
    Finish building what ever your creating,
    Then The child prim you wish to be phantom slice it to 0.980 (just type 1 its quicker).
    Place the script inside the child prim, and take the build into your inventory.
    Rez the build and you should have a Phantom Child Prim.
    This will only work for copyable items (non-copy items will not be phantom on second rez)
    Hope this helps 😉
    Scribzy Daxter
    */
    default
    {
    on_rez(integer p)
    {
    llSetStatus(16,TRUE);
    llSetStatus(16,FALSE);
    llSetPrimitiveParams([PRIM_SLICE,]);
    llRemoveInventory(llGetScriptName());
    }
    }

    Like

  3. ughhh it removed part of the script on the prim slice,
    message me in world if you want a copy

    Like

Comments are closed.