Issues with llSetLinkPrimitiveParamsFast

[Senelya Bloodrose]

I was just wondering if anyone knows more about the inner workings of llSetLinkPrimitiveParamsFast. I was told that this should be used because it was async and performed faster to do updates in bulk rather than using the equivalent calls. I currently have a snippet of code which iterates through all the faces of a linked mesh to change the texture on it.

So after the script runs, I don't see anything changes to the mesh even though it should have a new part of the texture showing. However, if I right click on the mesh, the changes get reflected like it did some sort of texture refresh when I did that.

I've read there are some caveats about using something like llSetLinkPrimitiveParamsFast with connection issues and things, but it doesn't seem like that. Has anyone dealt with this sort of issue and how was it resolved?

[Quistess Alpha]

Probably an issue with you specifically not receiving the update packets due to a loose connection.

Are you setting all the faces to the same texture? If so try:

llSetLinkPrimitiveParamsFast(Link,
[  PRIM_TEXTURE, ALL_SIDES, texture, <1,1,0>, <0,0,0>, 0.0 
]);

otherwise:

llSetLinkPrimitiveParamsFast(link,
[  PRIM_TEXTURE, 0, texture0, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 1, texture1, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 2, texture2, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 3, texture3, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 4, texture4, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 5, texture5, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 6, texture6, <1,1,0>, <0,0,0>, 0.0,
   PRIM_TEXTURE, 7, texture7, <1,1,0>, <0,0,0>, 0.0
]);

or so. If you have multiple links you can even string them together in the same call with PRIM_LINK_TARGET.

Edited December 29, 2022 by Quistess Alpha
no final ',' darn picky LSL.

[Senelya Bloodrose]

I don't really understand like how a connection would cause updates not to happen. Is it because I'm making too many calls? My original code is something like this:

list lLinkNum = [2,3,4,5];
integer iLength = 30;
integer iIndex = -1;

while(++iIndex < iLength)
{
    integer iLinkNum = llList2Integer(lLinkNums, (iIndex / 8));
    llSetLinkPrimitiveParamsFast(iLinkNum, [PRIM_TEXTURE, iIndex % 8, sTexture, sRepeat, sOffset, fRot]);
}

Basically there's 30 faces spread across 4 meshes (3 meshes have 8 faces, and the last has 6 faces for a total of 30). So in the example above, I'd be making 30 calls pretty quickly in a while loop. I've tried refactoring the script to build a list of all the face change rules, making it only 1 call per mesh ( so total of only 4 calls). Then I tried using the non-fast version of the call to try synchronous calls. Also added sleeps of 1 second to try and slowdown the calls thinking maybe call were overriding each other. Unfortunately I still get this weird behavior where no textures change until I right click the mesh.

I never saw this issue a few months back which used similar code, but now it's a rare exception that this updates properly. I'll see if I can have a friend look at it while the script is making change to see if it's just me, but it's just so odd. But then again, SL performance over time seems to be just getting worse and worse with consistency and how it loads on the screen (broken animations, invisible meshes, infinite orange clouds of smoke).

 

[Qie Niangao]

Firstly, you don't even need four separate calls to llSetLinkPrimitiveParamsFast() to address the four different links; that's what the PRIM_LINK_TARGET parameter is for.

But that's more FYI than significant; the whole point of using the -Fast version instead of ol' timey llSetLinkPrimitiveParms() is that the -Fast version avoids a built-in 200 millisecond delay between calls. Grouping all the parameters for all the links into one parameter list increases the likelihood that they all get executed in the same simulator frame, but with no built-in delay between calls, it's very unlikely it would ever matter that the separate links may update in sequential frames if each link is updated in a separate function call.

As for not seeing the updates that have already taken place, that's possibly a result of network glitchiness but whatever the cause, you may have some luck forcing an object update packet by setting its hovertext, even invisibly. Shouldn't matter what function is used to set the text, but I'd (superstitiously?) use a separate PRIM_TEXT call to llSetLinkPrimitiveParamsFast(), just once for the whole object, to a different text string each time.

If that doesn't help, you may want to try a different viewer because a "right click" effect must be the viewer forcing itself to update its representation of the object to values the script updated long before on the server.

[Quistess Alpha]

45 minutes ago, Qie Niangao said:

"right click" effect must be the viewer forcing itself to update its representation of the object to values the script updated long before on the server.

I'm not well-versed in viewer internals, but anecdotally, "Right-click 'updates' the object" seems common to most (all?) viewers. My main experience with it is that right-click "removes" ghost clones of an object that might remain after llSetRegionPos()ing the object to a different region.

[Profaitchikenz Haiku]

1 hour ago, Quistess Alpha said:

"Right-click 'updates' the object" seems common to most (all?) viewers.

Yes, and furthermore, to prove it's a viewer effect and not a server one, I see this in several opensim instances, including a couple of standalones on my LAN, so that even rules out network issues.

[Qie Niangao]

2 hours ago, Quistess Alpha said:

I'm not well-versed in viewer internals, but anecdotally, "Right-click 'updates' the object" seems common to most (all?) viewers. My main experience with it is that right-click "removes" ghost clones of an object that might remain after llSetRegionPos()ing the object to a different region.

Agreed. I'm no viewer expert either, I'm just guessing that if the OP's problems are getting worse as claimed, it may be that the viewer configuration is b0rked in some way that wouldn't carry over to a different viewer. More likely the network, granted, but some viewers expose plenty of configuration settings to screw up network behavior, too.

Or… possibly both server and viewer are doing exactly as expected, but the interest list associated with the viewer doesn't include the object at the time the update happens, then when the view is directed at the object it doesn't reflect the update.

[Senelya Bloodrose]

Thanks everyone for the tips.

I tried some more experiments with using PRIM_TARGET_LINK, updating invisible hover text, clearing my viewer cache. The results are still pretty bad and unfortunately when I sell a product, it's not going to matter if it's the viewer or SL's fault as it's on me to make sure it works.

I may have actually stumbled onto a really odd solution in hopes that someone in the future might find this useful. So I noticed that if I change the color of the face via PRIM_COLOR, it does force a texture reload. I guess changing hover text doesn't require a texture redraw, maybe some smart optimization on the server side. Now the question is how to make the transition not to jarring. After running the texture changes, I save the current color/alpha of the first face. Then I make a call to update the color to black with a transparent alpha. Now the next and final step would be to revert the color/alpha I originally saved.

Now here's where it becomes interesting, if I make a back to back call to change the color then revert, the texture does NOT reload. However, if I add a sleep in between, the results seem to be pretty consistent and now my textures update properly. Below is a snippet of code I use. I would love to know if this helps anyone else who has encountered a similar issue. A confirmation would be great so that others can refer to this.

If anyone has found a better, less cost intensive solution, I would love to hear still.

    if (iLinkNum != 0)
    {
      	//Save original property of one of the faces of the link
        list lRefreshParam = [PRIM_COLOR, 0] + llGetLinkPrimitiveParams(iLinkNum, [PRIM_COLOR, 0]);
        //Change it to a transparent face.
        llSetLinkPrimitiveParamsFast(iLinkNum, [PRIM_COLOR, 0, ZERO_VECTOR, 0]);
        //Without this sleep, the texture isn't forced to reload for my testing.
        llSleep(.1);
        //Revert the link face back to it's original color.
        llSetLinkPrimitiveParamsFast(iLinkNum, lRefreshParam);
    }

 

[primerib1]

On 12/29/2022 at 3:59 PM, Senelya Bloodrose said:

I don't really understand like how a connection would cause updates not to happen. Is it because I'm making too many calls? My original code is something like this:

list lLinkNum = [2,3,4,5];
integer iLength = 30;
integer iIndex = -1;

while(++iIndex < iLength)
{
    integer iLinkNum = llList2Integer(lLinkNums, (iIndex / 8));
    llSetLinkPrimitiveParamsFast(iLinkNum, [PRIM_TEXTURE, iIndex % 8, sTexture, sRepeat, sOffset, fRot]);
}

Basically there's 30 faces spread across 4 meshes (3 meshes have 8 faces, and the last has 6 faces for a total of 30). So in the example above, I'd be making 30 calls pretty quickly in a while loop. I've tried refactoring the script to build a list of all the face change rules, making it only 1 call per mesh ( so total of only 4 calls). Then I tried using the non-fast version of the call to try synchronous calls. Also added sleeps of 1 second to try and slowdown the calls thinking maybe call were overriding each other. Unfortunately I still get this weird behavior where no textures change until I right click the mesh.

I never saw this issue a few months back which used similar code, but now it's a rare exception that this updates properly. I'll see if I can have a friend look at it while the script is making change to see if it's just me, but it's just so odd. But then again, SL performance over time seems to be just getting worse and worse with consistency and how it loads on the screen (broken animations, invisible meshes, infinite orange clouds of smoke).

 

You probably need to check with other viewers as well if the slowness in updating is a viewer problem or an SL problem.

For me, FireStorm has been and endless source of annoyance and problems I've removed it from my computer and use other viewers instead. Things that I originally attributed to SL (e.g., orange smoke that take up to 10 minutes or more to rez) suddenly cease happening.

Next, I don't know if it will help, but have you considered building the list per linkNum first and *then* feed the whole list in one go to llSetLinkPrimitiveParamFast? That will greatly reduce the number of function calls taking place.

[Senelya Bloodrose]

49 minutes ago, primerib1 said:

Next, I don't know if it will help, but have you considered building the list per linkNum first and *then* feed the whole list in one go to llSetLinkPrimitiveParamFast? That will greatly reduce the number of function calls taking place.

I did try this as well, grouping all the rules by link num and also trying to do a single call on a group of links using PRIM_LINK_TARGET. The problem still persists unfortunately. In some ways it's good that the worst happened because I wouldn't want to sell something that appeared to be non functional to a buyer.

(NOTE: I'm bolding this next paragraph because I hope it helps someone in the future looking for a solution.)

As a follow up though, I found a much older post about SLPPF that basically showed calling the function twice with a sleep in between fixes the issue. It's similar to my code snippet in my previous post except you don't actually need to do anything fancy like changing a property of the prim. What I ended up doing was putting a loop around my block of code which iterates twice. The first pass wouldn't do anything and at the end I put in a llSleep(.01) and the second pass would actually force it to appear on my screen.

I'll also note that my friend was watching as I used the script to change the texture and they said it reflected properly, but they're also like 2 release behind on the FS version. I THINK this issue is mostly isolated to me, and while I could also change viewers or try to do a complete reinstall, ultimately no one's going to want some that doesn't work regardless of where the error is.