Jump to content

Mesh in linkset breaks llSetLinkedParametersFast - set sculpt


LauraTarnsman
 Share

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

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

Recommended Posts

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

Link to comment
Share on other sites

  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:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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!

 

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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!

Link to comment
Share on other sites


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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3621 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...