Rezzing sculpts: I can rezz it fine, but for my customer the same sculpt is "unformed"?

[Emma Krokus]

Hi guys :)

I would really appreciate some understanding as to what's going on here.

A customer contacted me to tell me that the waterfall scene she bought from me was not rezzing correctly.  

I rezzed a copy on my land and it looked fine to both of us, I could use the animation menu without a problem.  We went to her land, and to both of us the one she had rezzed, was all balled up.  I rezzed the build on her land, and it was fine.  I got her to buy the one I'd set down.

Now I just heard that when she was using the animation menu, the build I had rezzed for her, balled up!!!  Oh no!!

Does anyone know what's going on and what can be done to stop it, please? 

Almost bald now, Emma :) 

[Chosen Few]

Does the first one she bought have mod permissions?  If so, my guess would be she broke it, and didn't want to tell you.

It's also possible that something in the script messed it up.  Did you write the script yourself, or did you get it somewhere?

If the script is intended for animating not just the surface texturing, but also the sculpt shapes, then it would have to have the capability to swap the sculpt maps in and out.  If it disengaged the existing maps, but did not apply new ones, it's conceivable the sculpties might revert to the default apple shape.

Scripts can also change the stitching type.  If something is supposed to have planar stitching, but was changed to sphere or torus, it might look "balled up", as you described it.

[Innula Zenovka]

To develop Chosen Few's line of thought, lsl functions that involve reading the uuids of textures -- surface textures or those of sculptmaps -- behave differently according to whether the textures and object are full perms or not to the owner of the object containing the script.

I've been caught like this a couple of times -- things that work perfectly well for me when I'm making them don't work when I give them to my alt for testing.   I'm not saying this is what's happened but what you describe certainly would happen if the script is trying unsuccessfully  to read the uuids of sculptmaps that are full perms to you but not to your customer.    Without seeing the script, I couldn't be sure, of course, but that's what I would suspect.

[Emma Krokus]

Thank you, Chosen, for your speedy reply.

 

The build was mod, I saw her rezzing it and I saw the problem with all the copies that she rezzed.  I do not believe she broke it.

It contains no scripts that directly change sculpts.  There are scripts in there for animations (nPose), sounds, texture animation (water flow), light / bright / glow settings.  Could these contain any instruction that account for the problem?

I've not had a problem on my own land with it...

But I will now check all the scripts - just in case.

I really appreciate your input, Chosen - thank you!

 

Emma  

 

[Emma Krokus]

Thank you, Innula .

 

The build contained only sculpties build with the sculpt maps or with full perm sculpts from another creator and does not rely on UUIDs for the sculpts... The sculpt maps I used are full perm.

It's very kind of you to take the time to reply to my problem - thank you.

 

Emma  

[Emma Krokus]

I think I might have found the problem:  I was using a phantom child script for sculpties - once I removed all of these, my customer could rezz the build without further issues.  (I am so very grateful for her patience and courtesy during this palaver.)

So, thank you to Chosen and Innula, for getting me on the right track.  And I will be eternally grateful that  the whole build was just 17 prims ... 

Emma  

[Catwise Yoshikawa]

Guess I'm late here. Yes, was the phantom child prim script. I had the same problem with that ;-)

[Innula Zenovka]

It's because the llGetPrimitiveParams/llGetLinkPrimitiveParams calls can't read the sculptmap's uuid unless the object is full perms to the owner.

The phantom child workround I use when sculpties are involved -- which doesn't work if you need to switch between phantom and solid, and causes general strangeness if any scripts in the same object use collision events, but is otherwise perfecty reliable -- is simply to drop this into the prim I wish to phantom before I link it up as a child.

As I said, it shouldn't be used if you want to switch between phantom and solid, but otherwise it's ok.

 

default{	state_entry()	{		llVolumeDetect(TRUE);		llRemoveInventory(llGetScriptName());	}}

 

[Emma Krokus]

Thank you Innula - that makes perfect sense.  I do love a problem that not only resolved but also understood !!

Thank you also for pasting the work around script  - I have a couple of questions about this:

1.  am I to use this instead of the phantom child sculpt script or in addition to?  

2.  since it appears the script is removed after setting the prim, I am presuming that what it sets is a persistant prim property... would using a scrubber script remove this property also (I have been known to change my mind... hehehe).

Emma  

[Innula Zenovka]

Glad we were able to solve the problem.

Use the Volume Detect work-round instead of the phantom child script you've got, not in addition to it.

If you want to reverse the effects, I think -- from memory -- that turning the whole linkset phantom using the edit tools and and turning it back to non-phantom would remove all the effects of my little script (I know it unphantoms stuff if you do that, which is why I stress it's no use if you want to switch between phantom and non-phantom child prims, and I assume -- though I've not tested it -- that it also removes any lingering strangeness about collision events, if that's an issue).

If you wanted to be sure, I guess you could unlink the prim in question, use a revised version of my script to set llVolumeDetect(FALSE);  and then relink it.

[Emma Krokus]

Thank you Innula.

And thank you to everyone who took the time to reply, illuminate and share their own experiences in this thread.

You're awesome!

Emma