Mesh in linkset breaks llSetLinkedParametersFast - set sculpt

[LauraTarnsman]

I have an application (a board game) that uses an array of sculpts (pieces). As an option, I allow the user to change from one style of pieces to another. I do this by using llSetLinkPrimitiveParamsFast(PRIM_TYPE...) to swap out the sculpt maps. This worked perfectly until I introduce 1 mesh prim to the linkset. (I know animation using sculpts and meshes is a sore point with LL, and this build does not attempt to do animation).

When I link the mesh prim into the linkset, the PRIM_TYPE function quits working. Resetting a sculpt map on a non-mesh prim in the linkeset from the LSL function no longer has any effect, although the sculpt map can be manually edited using the edit tool with "edit linked items".

Is this process "borked" by the LL fear of animation abusers? Is there a workaround? Or (hopefully), have I just made some silly mistake?

Laura

[Dora Gustafson]

1. Mesh has not been given a PRIM_TYPE, it is not defined in that respect, so you should not consider it a full prim
2. There are a number of things you can do manually but not in a script

   ( projector texture and parameters can only be managed manually)

I can not comfort you or give you a work around only say that we have some rules and limitations we must adopt to

Very often the rules and limitations are not written anywhere so we have to test the limits ourselves

:smileysurprised::smileyvery-happy:

[LauraTarnsman]

Thank you for the reply, Dora! 

And I do want to carify that I am not trying to change the sculpt map on a mesh prim... just the sculpt map on a sculpted prim, which has already worked in the past, but which quits working when I add a mesh prim to the linkset. Somehow the linkset seems to have changed how it behaves as a result of linking in this one additional prim because it is a mesh prim.

[Dora Gustafson]

Is the llSetLinkPrimitiveParamsFast(PRIM_TYPE...) addressing the mesh at anytime?
If it loops through  all the prims or use LINK_SET to address all prims, it will.
LINK_ALL_OTHERS and LINK_ALL_CHILDREN also addresses most of the linkset.
Also the link order will change when you link in a new prim.

Since the mesh has no defined PRIM_TYPE I wouldn't address it
I wouldn't know what to expect

[LauraTarnsman]

Great points!

I "register" all the prims in the linkset by matching the linknumber to the prim name at the beginning of the script. So the llSetLinkedPrimitiveParamsFast call with "PRIM_TYPE" is going only to the sculpted prims in the set by linknumber, and not to the mesh prim. When the mesh prim is linked in, the command fails, but when it's out, the command works.

Another interesting figment is that when I link 25 prims together, if one of them is this particular mesh prim, it ups my land impact to 27, while the unlinked total is 25. Linking a mesh prim actually causes a 2-prim increase in impact over the unlinked total of the same prims.

It is my suspicion that this LL land impact accounting with mesh conveys some new properties to the linkset that disables programmatic sculpt map swapping within the set. The land impact accounting is one thing that seems to connect the linkset issue with the presence of mesh prims within the linkset. If linking to a mesh prim does change the rules for the other prims in scripting, it would be good to gather the details of the changes and add them to the LSL Portal.

You put it well, that we must "test the limits ourselves". However it's good to be able to run things by others who may have similar experiences both for new ideas and as a sanity check! Thanks for your thoughtful answers!

 

 

[Rolig Loon]

By coincidence, Cerise Sorbet just left a comment in an old thread this morning that has relevance to yoiur question.  She said...

A mesh prim will return [PRIM_TYPE_SCULPT, NULL_KEY, 5]

A constant has not been assigned for this subtype. This is a read only value. Meshes differ from the old sculpted prims in that a UUID cannot be set and keep the object as a mesh.

So, if you are looping and testing for PRIM_TYPE_SCULPT, you will apparently scoop up mesh as well.

[Cerise Sorbet]

---

LauraTarnsman wrote:

Is this process "borked" by the LL fear of animation abusers?

Yup. It was left working for link sets without any mesh to keep legacy builds from breaking. If there is mesh in there it can be reliably recognized as new work, and bye bye UUID flipping.

Is there a workaround?

Nope. You can use the same tactic we use for meshes, which is to link in multiple sculpts and flip their alpha values, but of course that's not quite the same.

[Qie Niangao]

Oh for pity's sake.

Well, if we're stuck with this, who understand's Strife's wiki templates enough to get a suitable caveat documented so it shows up everywhere it needs to?

Or would it be easier to just link in another permanent feature request jira for this to revert? (But I also don't know how to make a jira that everybody can see anymore.)

[arton Rotaru]

I cannot confirm that sculpt map UUID swapping does not work with a mesh in a linkset. It works flawlessly for me.

[Cerise Sorbet]

All right, there is a workaround, but I'm not sure I'd want to rely on it.  If the script calling llSetLinkPrimitiveParams* lives in a mesh prim, PRIM_TYPE_SCULPT changes are silently eaten.  If the script is located in a non-mesh prim, it will be propagated.

 

[LauraTarnsman]

Thank you THANK YOU! Yes, the script with the call to the llSetLinkPrimitiveParams switching the sculpt map did live in the mesh prim! I can move it to another prim and try what you suggest. Crossing my fingers - won't be inworld to try it until tonight.

Dang this forum is good!

[LepreKhaun]

---

LauraTarnsman wrote:

...

Another interesting figment is that when I link 25 prims together, if one of them is this particular mesh prim, it ups my land impact to 27, while the unlinked total is 25. Linking a mesh prim actually causes a 2-prim 

increase

in impact over the unlinked total of the same prims.

...

---

This is because while they are unlinked, or linked together w/o the mesh object, they fall under the "old" accounting of one prim = one LI. As soon as you link a mesh object into the mix, then everything within the linkset falls under the "new" accounting. When that happens, the greater of the Download, Server and Physics Weights determines the Land Impact of the resulting object.

[LauraTarnsman]

A final report and clarification on this item, and a big thanks to all who helped solve it.

Arton was correct in that it was not the presence of a mesh prim in the linkset that broke the PRIM_TYPE call to llSetLinkePrimitiveParams, and Cerise hit the nail on the head, that the call failed to change the sculpt map because it originated from a script in a mesh prim, even though the mesh prim was not the target of the sculpt map change. Moving the script to another prim and making the same call succeeded, so problem solved. The only inconsistency in LSL is that the function call to flip sculpt maps is silently disabled based on the type of prim hosting the script rather than on the type of prim that is the target of the call.

Oh well, that's something we can live with, once we know how it works. And thanks again to the great sages on the forum here!