When I do llSetLinkPrimitiveParamsFast, sometimes not everything updates for me

[Sara Nova]

Usually this happens when I'm changing large numbers of prims at once, e.g. with LINK_SET in a large linkset. Like I'll change the color, but a few of the prims get stuck on the old color. What's annoying is that calling llSLPPF an additional time with the same color (or whatever parameter) doesn't get the rest of them; I assume from the server's perspective it already changed to that color so it doesn't send an update. What I've found works as a workaround is to change it to an almost-identical but still different color the second time, e.g. 0.99*color.

Interestingly, sometimes when changing scale in this way, the numbers that appear in the editor dialog update properly, but the actual size doesn't appear to update until I make it update again by changing the numbers and changing them back.

This only happens when I do it via a script, not with manual edits.

I know this is a clientside effect, as it'll catch up if I teleport somewhere or relog, and I showed someone else just now to test and she said it looked correct for her. I am using Firestorm; I don't know whether she is though or if that has anything to do with it. Also I've been getting a message saying my HUD uses a lot of texture memory; is that known to cause the issue I described? Or is there something else that's known to cause it?

Thanks.

Edited February 11, 2020 by MyAlt4099

[Wulfie Reanimator]

The issue is caused by object updates not reaching your viewer -- a connection quality problem. For me, it only happens with manual edits, never SLPPF.

I don't think you should concern yourself with clientside problems as repeating the SLPPF even with slightly different color has no guarantee of working any more than it did the first time. It's not making any fewer changes after all, the problem might just be in other prims this time but the color difference is lesser so you don't notice it. But there's no way for you to predict which prims have the problem and those prims WILL vary from other viewers experiencing the same problem.

[Sara Nova]

Whenever I'm on SL, I'm connected to an access point in the same room as my laptop. And I have a pretty good Internet connection. What could be causing connection quality issues? Do you know of any way to prevent this from occurring?

Why would it happen with manual edits? Aren't those applied immediately by the client, without waiting for an update from the server? Or do you mean then it's later updated, and you find that not all your edits went through?

And yes, I know the second SLPPF could have the same problem. But it at least minimizes the chance of it occurring, as odds are at least one of them will work, and if the colors are similar enough, it doesn't really matter which one.

 

[animats]

Oh, so llSetLinkPrimitiveParamsFast uses unreliable updates. That should be documented.
Second Life sends update messages either as "reliable", which get retransmitted a few times before giving up, or "unreliable", which don't. Properly, the only "unreliable" messages should be ones that are regularly superseded by later messages, like move updates. (ImprovedTerseObjectUpdate, which tells the viewer something moved, is the main legit unreliable message. Can you put a color change in an ImprovedTerseObjectUpdate?) But apparently more than that is sent in "unreliable" mode.

Try SetLinkPrimitiveParams, without the "fast". That's supposed to be synchronous.

If you're doing this to animate something, don't.  Use texture animation. Much lower overhead; it's all viewer side once started.

[Gayngel]

I find using SLPPF in a loop instead of doing every prim all at once produces better results but of course you have to tolerate your object changing colour prim by prim over a few seconds rather than all immediately. If you can live with that caveat then try a loop.

It may of course just be the sim you are trying your script on is very laggy so try it on a quieter region.

Edited February 11, 2020 by Gayngel

[Sara Nova]

2 hours ago, animats said:

Oh, so llSetLinkPrimitiveParamsFast uses unreliable updates. That should be documented.
Second Life sends update messages either as "reliable", which get retransmitted a few times before giving up, or "unreliable", which don't. Properly, the only "unreliable" messages should be ones that are regularly superseded by later messages, like move updates. (ImprovedTerseObjectUpdate, which tells the viewer something moved, is the main legit unreliable message. Can you put a color change in an ImprovedTerseObjectUpdate?) But apparently more than that is sent in "unreliable" mode.

Try SetLinkPrimitiveParams, without the "fast". That's supposed to be synchronous.

If you're doing this to animate something, don't.  Use texture animation. Much lower overhead; it's all viewer side once started.

I'd rather not have to refactor/rebuild all my scripts that use SLPPF to compensate for SLPP's inherent synchronous delay. Is there any way to avoid that?

If I report that bug (where it uses "unreliable" messages) to the Linens, is it likely it'll be fixed reasonably soon?

How would that result in the numbers in the Scale boxes updating, but not the prim's actual size?

(And yes, I know blankets and towels have no ability to fix bugs in Second Life. My autocorrect just felt like being funny, and I figured I'd let it. XD)

 

[Wulfie Reanimator]

1 hour ago, MyAlt4099 said:

If I report that bug (where it uses "unreliable" messages) to the Linens, is it likely it'll be fixed reasonably soon?

Assuming it was considered a bug, it's not likely it would be changed anytime soon. Few things are.

Whether or not a type of update should be reliable vs unreliable is a matter of technical debate and trade-offs. It may be intentionally left this way.

6 hours ago, MyAlt4099 said:

Why would it happen with manual edits? Aren't those applied immediately by the client, without waiting for an update from the server? Or do you mean then it's later updated, and you find that not all your edits went through?

I don't actually know, but my assumption from simple observation is that the things you see while changing (dragging) the color in the edit window are updated client-side, but only after you press OK or Enter, your viewer will send a "hey update this object with this color" packet to the sim and basically ignore/discard your local changes until the sim calls back with "hey this object is now updated with this color." Edit: Or, I guess the updates are just sent live and this happens, using 1000 prims:

llSLPPF has the same problem when there are more than one full linkset (500 prims exactly) trying to change color at the same time. (I used a listener in each linkset.) I saw no artifacts when I only had 250 prims changing at once. It's very much a volume/connection thing.

Edited February 11, 2020 by Wulfie Reanimator