Jump to content

Child prim phantom issue.


StarSong Bright
 Share

You are about to reply to a thread that has been inactive for 3820 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hi All,

I have a great little script i can put in a prim in a linkset to make that prim phantom.  But I need to do it the other way around.  I have a 70 prim object where i ONLY need three of the prims to be solid - and all the rest of the prims need to be phantom.  Is there a script i can put in a *phantom* linkset to make just those three solid?

I tried setting the phantom ones to prim type none and then prim on the solid ones (one of which is the root prim).  but my object went from 70 prims to 128 boom.  That will not do, as it is overprimmy to begin!  The root prim does not have to be the solid one, i could change that.  But what i do NOT want is to have to have sixty odd scripts in the silly thing in order to have all those other prims phantom.

Doing this in two pieces is a real problem, it needs to be linked.  Is there a way to put a "make this here prim solid in this otherwise phantom linkset" script out there?

 

Any help is greatly appreciated. Thanks for reading!

StarSong

Link to comment
Share on other sites

Not... sure what you mean. Never known LI to change with primitives, regardless of prim changes.

You said 'prims' in your posts, are you using primitives? Or are you using mesh?

Maybe it's just something I've never seen. I'd certainly expect the physics to weigh very heavily with this implimentation as it sounds - the LI gain would be a punishment inflicted by the sim due to the heavy use of simulator resources when calculating collisions.

Link to comment
Share on other sites

There is a little script you can drop into individual prims in a linkset to make those prims and only those with the script in phatom while the rest of the linkset stays solid.  What i need is the inverse, to be able to set the whole linkset to phantom and have a script that would make three little prims solid.

Link to comment
Share on other sites

string uuid = ""; // Put the sculpt maps UUID here.  This will allow the script to reset without problems. (Should a user decide to reset it)makephantom() {    if (llGetLinkNumber() < 2) return;    llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX, 0, <0,1,0>, 0, <0,0,0>, <1,1,0>, <0,0,0>, PRIM_FLEXIBLE, TRUE, 0, 0, 0, 0, 0, <0,0,0>,PRIM_TYPE,7] + [uuid] + llList2List(llGetPrimitiveParams([PRIM_TYPE]),2,2));}default {    state_entry() {         if (uuid == "") uuid = llList2String(llGetPrimitiveParams([PRIM_TYPE]),1);        makephantom();    }    collision_start(integer n) { makephantom(); }    on_rez(integer s) { makephantom(); }    changed(integer c) {        if ((c & CHANGED_LINK) || (c & CHANGED_REGION_START)) makephantom();    }}

 

Link to comment
Share on other sites

[EDIT: Indeed, that is a variant of this old kludge... except that's not supposed to work anymore (and was always a bit flaky).]

Unless there's some fresh magic of which I'm not aware, I think the current approach is indeed to use the "None" physics type for all child prims that are supposed to behave as phantom, and either "Prim" or "Convex Hull" for the solid ones, including the root. Generally, there's not much Land Impact penalty for Convex Hull (and for unscripted, non-sculpty prims, often a benefit). If, on the other hand, they need to have physics type "Prim" and it causes Land Impact to blow up, then those prims probably need replacing with Mesh.

Link to comment
Share on other sites

'kay so, what your script does is this:-

  • Sets the link as a prim box/cube.
  • Makes it flexible.
  • Sets it back to being a sculpt.

Looks like that invokes some kind of a hack, flexible prims have weird collision boxes already and sculpts can't also be flexible, so that's probably where the phantom comes from. (Still guessing obviously.)

The trouble with this method is that - like you've discovered - it'll only work for individual link objects. Setting the whole link-set to phantom wouldn't work because you can't use an equivilent hack to create collisions with a link-set explicitly set to phantom. 

I imagine the LI increases because of something to do with casting a PRIM_TYPE_BOX as PRIM_TYPE_SCULPT... I haven't tried this.

Puzzling!

Link to comment
Share on other sites

- You can only set the whole object to phantom or not phantom, no half things.

- The script you have was a hack that was used to set single linked prims to phantom. It's obsolete and is not supposed to work anymore.

- You can transfer your object to the LI system by setting it to convex hull.
     - The root is always convex hull in this system and can not be set to none.
     - The child prims can be convex / none / prim
     - Your Land Impact can go up or down if you do that - depends on how the object is built

convex is a simplified collision shape and has no holes.
none means no collision shape and it will behave like phantom
prim will use the collision shape of the original prim - depending on what that is it can "explode" your land impact.

If the prims are simple and not too big then each one will count for 0.5 LI so your overall LI will get lower in this cases. Not in the OP's case it seems.

 

Link to comment
Share on other sites

The flexible=phantom trick is still very useful, without being any sort of hack.  It only works for individual prims because only individual prims can be flexible.  The trick is to make each prim that needs to be phantom into a flexible prim with maximum stiffness so they don't ever flex in practice.  Not great if you're moving the whole set around much but works well on static objects (I use it for water in pools).

Presumably though it's the flexible attribute that increases the LI so much (haven't checked it out recently so I can't tell).

Link to comment
Share on other sites

http://wiki.secondlife.com/wiki/PRIM_PHYSICS_SHAPE_TYPE

 llSetLinkPrimitiveParamsFast( LINK_ALL_OTHERS,            
    PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_NONE ]);

you could put this script in the root, and change the linkset

 and  then go back and change only the 3 you need solid with

 llSetLinkPrimitiveParamsFast( 3,        // this will change link number 3...make a loop / list to do more than one
    PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_CONVEX ]);

 

...root prim has to have a shape of PRIM or CONVEX tho :)

Link to comment
Share on other sites


Xiija wrote:

 llSetLinkPrimitiveParamsFast( LINK_ALL_OTHERS,            

    PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_NONE ]);

you could put this script in the root, and change the linkset

 and  then go back and change only the 3 you need solid with

 llSetLinkPrimitiveParamsFast( 3,        // this will change link number 3...make a loop / list to do more than one

    PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_CONVEX ]);

 

...root prim has to have a shape of PRIM or CONVEX tho
:)

Careful, lists must be bracketed at both ends:

 llSetLinkPrimitiveParamsFast( LINK_ALL_OTHERS,            

   [ PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_NONE ]);

and

 llSetLinkPrimitiveParamsFast( 3,        // this will change link number 3...make a loop / list to do more than one

   [ PRIM_PHYSICS_SHAPE_TYPE  , PRIM_PHYSICS_SHAPE_CONVEX ]);

 

@OP:

As soon as just one prim is set to none, the entire linkset it's within goes to mesh accounting. This will usually affect the Land Impact one way or the other, lowering or raising it according to a number of factors. In general, sculpties do not fair well in these circumstances.

 

If the download cost is driving your LI up when you're switching to PRIM_PHYSICS_SHAPE_NONE, which is probably the case if there are sculpts involved, there is little to be done since there are no tricks to get around that. To see what is driving the LI, click the More info link in your edit menu to open the Advanced building floater.

 

If you see that the download weight is higher than the server and physics weights, your only option would be to split out sculpts into a separate linkset and keep them within the legacy prim accounting, such as setting them all to phantom.

 

If, however, it's the physics weight driving your LI, try setting those three prims to convex hull instead of type prim. That may alleviate the physics burden but you may find the "hole filling" aspect of it unsuitable. Alternatively, separate out your three prims and set everything else to phantom, though that would give you two linksets, which may be the only way to go with this after all.

 

 

Link to comment
Share on other sites

Thanks to all who answered.  After tinkering endlessly I gave up and left it two linksets.

 I did find an elegant solution though.  i have EZ-Rez-It! (which is free and awesome) and I put it in the shadow prim (unlinked from the rest) and it is the rezzer.  So users can rez the shadow, turn how they want, and then rez.  It only adds three scripts to the whole thing and then all they have to do is just shift the bottom prim and everythign follows suit.  

One single prim would have been more elegant but this will have to do. I am tired of putzing around with it.  Again, thanks to all who took time to respond.  :cathappy:

Link to comment
Share on other sites


steph Arnott wrote:

Sorry this off topic, what does KLUDGE mean?

A kludge is a workaround or algorithm that works but is not very eloquent. It's usually used for something that, though working, will be hard to maintain, understand or change because it consists of parts that are ill-suited for the task or poorly put together. In other words, practically any down-and-dirty solution thrown together without much thought.

  • Like 1
Link to comment
Share on other sites


steph Arnott wrote:

Sorry this off topic, what does KLUDGE mean?

http://en.wikipedia.org/wiki/Kludge#In_computer_science

Peter objects that it's not "any sort of hack" but I think the trick with flexi (or equivalently, llVolumeDetect) operates well outside the "contract" for those functions and is at best unsupported. On the other hand, LSL functions don't come with contracts, only folklore and some observed behaviour of unspecified generality.

  • Like 1
Link to comment
Share on other sites

An added note of warning for the hack method of making those prims phantom.  Everyone's right its not supposed to work anymore, but even if you do have objects that you get it to work in, or you have objects you made before it stopped working, there is a danger.  If it is working in a linkset and then you give it away or sell it, and the person changes the linkset in anyway (add a prim or remove a prim from the linkset) then the all of the hacked prims in the linkset will loose their phantom ability and b solid again.

Separate link sets or the new physics types are the two ways to do it.  Save yourself headaches and forget the hack exists.

 

Just my 2 cents.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3820 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...