Texture offset and face color not always updating in viewer

[xigaro]

TL;DR the viewer is not realising/showing linked prim textures/colors have updated

I've written a simple word game with 4x4 tiles for letters as linked prims. I use llSetLinkPrimitiveParamsFast() to set texture offset and/or face color of each tile (the root prim doesn't change color or texture, if relevant).

My beta-testing friends live on quite a packed sim and they're running into problems - the viewer doesn't always show the new texture offsets or color changes. Sometimes it is instant, sometimes it takes 3-5 seconds to show, other times it doesn't show at all.

The script is definitely setting them fine. If they right-click the object then all the texture offsets and face colors seem to instantly update to their correct versions. We can't recreate the problem on other sims (tried about 6) but I know the troublesome sim has a lot of animated textures, particles, etc going on constantly. We were all testing in Firestorm.

My script doesn't hammer changes. It makes 16 texture offset updates and 16 color changes at the start of the game, approx. 120 color updates over 180 seconds, and a final 32 updates at the end of the game.

Is this a problem anyone else has come across? I'm stumped for a solution!

Thankies

[Innula Zenovka]

What viewer are they using?   I don't know if it's relevant, but the latest pathfinding viewer code seems to have introduced some issues with items not updating when they should -- e.g. VWR-29466 and VWR-29562.   The fix for VWR-29431 (which I always thought was expected, though sometimes irritating, behaviour) seems to have messed up visual updates something horrible.

[Qie Niangao]

Well, the OP says "We were all testing in Firestorm." I certainly would try the current issue Linden viewer first, to avoid chasing ghosts, but I suspect something has been going on with propagation of object updates -- and for that matter, object visibility at all, since about a month ago, before the Pathfinding stuff started getting on the main grid.

Just as a possible kludgy workaround, I might try the old trick of forcing a changed (but invisible) llSetText() on the changed objects, to see if the resulting object update appears, and forces all the other changes to appear, too.  Even if that works, however,if everything was working fine at one point without the forced object update, this would indicate a change that needs attention.

[xigaro]

Thanks for your replies Yes four of us encountered the problem all with Firestorm (various versions). I've just tested with the official viewer and have the same problem although it felt less pronounced - delayed rather than not showing at all. Hard to test with such an intermittent bug though!

I will try your suggestion of forcing updates with invisible hovertext. It's a shame as I have one script controlling 17 objects, now I will need 17 scripts. I was proud of my efficient scripting But efficiency is useless if the object doesn't work. Will let you know how I get on.

If there are more ideas in the meantime please let me know!

[Rolig Loon]

You shouldn't need to abandon the one-script approach.  You can use PRIM_TEXT in your SLPPF function call to create a dummy hover text.

[Innula Zenovka]

I missed the "all testing in firestorm" bit, but even then, there's people using Firestorm  4.1.1.28744 (released back in July), 4.2.1.29803 (briefly released August 26th, and certainly suffering from problems, which is why it was withdrawn almost immediately) and 4.2.2.29837, which fixed the llTargetOmega problems that were so apparent in the previous version.

Just to clarify, I don't think Pathfinding is responsible for these issues, but I do think that changes to the viewer code that were made with Pathfinding in mind have caused a lot of graphics issues.   I see Marine has rolled back some of her recent changes to her viewer because of this.

I've got lost with who is using what version of LL code at the moment.  What I do know, though, is Catznip hasn't updated lately (which I was getting impatient about but I'm now rather relieved) and, whatever version of the Official Viewer it's based on, it's a version that was made before the changes to the code that's causing all these headaches in other viewers.    

So it might be an idea to see what the objects look like in Catznip.   If they're behaving as they should if observed in Catznip, that would suggest to me it's a viewer issue, though probably one that affects a lot of people. 

 

ETA  I've just confirmed that, while VWR-29562 (the one that broke all the doors) is still there in Second Life 3.4.0 (264194) Aug 30 2012 14:38:24 (Second Life Beta Viewer), the trick with llSetText fixes it.

[xigaro]

Oh my, Rolig to the rescue again

I've just finished the 17 script version and it feels very sluggish to play. I'm glad there's a better way! No word from my beta testers yet (no news could be good news...) If the invisible hovertext fixes the issue then I'll be sure to use PRIM_TEXT in the function call, thank you

[Ackley Bing]

I am also having this problem with a HUD I am developing.

Using UUIDs to display people's profile image on the hud, the texture loads partially (blurry) and never finishes loading. The llSetText trick doesn't seem to work in this case.

Is there another trick or do I have to wait until Linden Lab finishes with it's Project Shining? http://community.secondlife.com/t5/Tools-and-Technology/Project-Shining-to-Improve-Avatar-and-Object-Streaming-Speeds/ba-p/1583465

[Qie Niangao]

Sorry, I don't know any tricks to get textures to finish loading. It's not quite the same problem because in that case the object update has been sent and the texture has started to load, it's just not completing. FWIW, the blurry texture load thing for a specific texture is something I've recently encountered for a few textures, across multiple sessions, but it was something only I saw, and was fixed by the old "clear cache and relog" cliche. Of course, if multiple people have the same problem with the same texture, that would be something else.

[xigaro]

Thanks everyone for your help and suggestions So far we haven't encountered the bug with the hidden hovertext approach.

I have taken Rolig's suggestions and wrapped them into a function which seems to work very well for the game- I hope this is of use to you. Simply use this function instead of llSetLinkPrimitiveParamsFast() - hey it's quicker to type too! - and you should be bug free.

It checks the list of rules and applies hidden PRIM_TEXT if your rules don't apply PRIM_TEXT already. If anyone can think of a simpler or more efficient approach please reply

 

slppf(integer link, list rules){    /* Attempts to fix viewer texture/color update bug  */    // Check to see if hovertext is being used already    integer i = 0;    integer hovertext = 0;    for (;i<llGetListLength(rules);++i)    {        if (llList2Integer(rules, i) == PRIM_TEXT)        {            hovertext = 1;        }    }    if (! hovertext)    {        // Append invisible hovertext as fix        rules += [PRIM_TEXT, (string)llFrand(1000), <0,0,0>, 0.0];    }    // Apply rules    llSetLinkPrimitiveParamsFast(link, rules);}