Anyway to get over the problem of linking real and phantom items for sculpties

Thanks for the clarification, Domino. From your explanation it makes sense that they would continue to use the Torus as the basic shape.

@Dekka.

Made an in-world example. Works like I said. The sculpt is flexi (and therefore phantom) and linked to a normal prim.

And yes, NORMALLY you cant make a sculpt flexi... but there is a trick to accomplish that

I will drop an example on you too if you dont believe me, just give me an IM in-world.

Tell.

* rez a box
* drag copy it to make a second one next to it
* set the second box (currently beeing edited) to flexi
* control click the first box to add it to the linkset
* Link them (ctrl-L)
* tag "edit linked parts"
* edit the second (flexi) box again
* change it into a sculpt
* done

The viewer will not show that the second prim is flexi or indeed phantom but:

The "flexi sculpt" in the linkset IS phantom now and the main prim IS solid.
I believe this solves the OP's problem: I linked a phantom sculpt and a solid prim.

If you set PathEnd to 25000, PathScaleX and PathScaleY to 195 it seems to make it phantom. Sent you some prims too

Thanks for that, cool tip.

Indeed Thanks for this one Mandy! Until now i only have seen scripted solutions, all of them using bugs or deprecated features. But i like your one best as it does not require a script.

But can we again be sure, that this is not yet another bug to be fixed at some time? On the other hand, bugfixing of that kind seems to have low priority. So it might be safe to use it

I would say... don't use this in no-mod products. Let people unlink their builds and make the doors phantom if they need to at some point in the future.

I just talked to Twist and he says a bunch of people were discussing things like this at Andrew's office hour. Twist made a simple script (and I added some checks in the changed event).

The script is usefull if you want this "TRICK" to be sticky. After taking the object to inventory and rezzing it again... it will fail (without the script).

But... using the script it WILL work!

This is what it looks like

// place this in any linked prim needing to be phantom

default
{
on_rez( integer start_param )
{
llResetScript();
}
state_entry()
{
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] + llGetPrimitiveParams([PRIM_TYPE]));
}

changed(integer c)
{
if(c & (CHANGED_LINK | CHANGED_REGION | CHANGED_TELEPORT | CHANGED_REGION_START))
llResetScript();
}
}

Oh, how bad. Now it has become yet another scripted solution... Can you tell if it is more safe to use this trick instead of applying llVolumeDetect on a child prim of a link set ? (see )

llRenderVolume?

Ups, that was a massive name mangling. I just came back from some experiments with Shadows in the viewer when i created that post and that RenderVolume stuff somehow kept stuck in my brain . sorry, i corrected my post above.

Oh.

llVolumeDetect is probably safer. Because they are planning on making flexibility on sculpties actually do something one of these days.

I don't understand how llVolumeDetect() solves the OP's problem, since it makes the whole link set phantom, and according to LSL wiki, it's only supported for scripts in the root prim.

The documentation says exactly:



It not explicitly says, that you may not apply it to child objects. So if you get adventerous and use it on a child object that child behaves like it where phantom while all other objects in the link set remain non phantom as before.

But i also got the warning that all this stuff is by no means officially supported, so i doubt that it is wise to rely on these techniques. On the other hand if this is the only chance to get a linkset with phantom children in it...

The SL wiki says It also says
That's incorrect or incomplete, if what you're saying is true.

The lslwiki.net article says
Evidently that's true only if the script is in the root prim.

It looks like both SL wiki and lslwiki.net are inaccurate or misleading.

In any case, thanks for the clarification.

I just tried this and it works really well, but does it have much of a script load?
It solves so many problems that I'll use it over and over, but I don't want to be shot down in flames for overloading the sim with lots of running scripts.

Thanks guys

Every script adds some server load, even if it's doing nothing (unfortunately).

I find that MOST of server script load is dormant scripts, even when no avatars are present (avatars often have a heavy load of dormant scripts due to resize scripts in every prim of attachments). So, it's important to consider this carefully.

However, the impact isn't severe until you have several hundreds of scripts.

Questions to ask: how many of your scripts are likely to run in a region?

If it's a script in every door and window of a building, well, that adds up, so it's best to combine that behavior with any other scripts that those would need anyway.

If it's just doors, then the number comes down considerably.

But if it's just for a main door, or a rather unique one, then don't worry.

The main thing is to think of a typical bad case and count the number of extra scripts. If it's several dozen, see if you can do anything to minimize that.

It's too bad that the property doesn't stay when re-rezzed! Otherwise, the script could do its business and delete itself (or not use a script in the first place).

HTH
Lear

Here's the math.

A script that's doing nothing takes about 0.002 milliseconds, or 2 microseconds, each time it's visited by the server. The server always gets at least 5 msec to run through scripts, per timeslice (physical frame). It's best if it can get through all of them in a frame or two.

Of course, some of those scripts will actually have something to do, and will use considerably more time. So you wouldn't want more than half the available time used up by dormant scripts.

So, you don't want more than 1,000 dormant scripts in a region.

Seems like a lot, but they sure do add up fast. But that gives you something of a baseline.

as far as i know the llVolumeDetect() trick only needs a script to set the flag. The script can self destroy after the job is done. So in that case no scripts are running at all in the ready made (prepared) build. (i have yet to confirm that a take to inventory and rerez preserves the flag).

Oops, I got a couple wires crossed. The flexi-sculpt trick was the one that didn't stick on re-rez.

If this method does stick on re-rez (and there's no reason to believe it wouldn't), then the script can delete itself. However, I suggest the same trick I use for particles and other properties that I'd like to be able to turn back on or modifiy if necessary: have the script set itself to not running.

But, yes, I heartily recommend one or the other: either have the script delete itself:

llDeleteInventory(llGetScriptName());

or turn itself off

llSetScriptState(llGetScriptName(), FALSE);

after doing its business.

Ok I just encountered a big problem with this script, I just sold my first item and got a disgruntled customer complaining the sculpt was just a sphere.
I've done a few tests with an alt and it seems the link to the sculpt map is destroyed on transfer of ownership.
I'm going to re-read all the comments to see if I missed something, but if anyone has an angle on this I'd be really grateful.
By the way this problem is using the script by Mandy Medusa.
I would be interested in seeing a script sample using the other call mentioned LLVolumeDetect

Might this be related to the server issues SL was experiencing earlier?

o_O WOT?

default
{
state_entry()
{
llVolumeDetect(TRUE); // this makes the prim "phantom like"
string me = llGetScriptName(); // here i retrieve this script's name
llSetScriptState(me, FALSE); // and here i disable the script
}
}

IMPORTANT NOTE: This method works only if the script is applied to the prim BEFORE it is linked to the linkset. Otherwise the whole linkset turns phantom.

- Place this script into the prim (simple prim or sculpty) which you want to be phantom.
- Link all parts together
- You can but you do not need to remove the script from the "phantomized" prim as the script disables itself.

To all of what i know this method makes the prim permanently phantom, so rerezzing or selling should NOT affect the state. It even keeps its phantomness when the linkset is copied or taken to inventory and rerezzed. So it looks like the script needs to run only once and the object and all future copies get its phantom property for ever...
And if you look at the edit box you see the prim is not marked as phantom although it behaves like phantom...