Senelya Bloodrose

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.

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); }

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

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?

Yea, I've tried some tests but they seem so inconsistent which is in line with the lsl wiki on memory on how the numbers are necessarily conclusive given the LL secret sauce. Thought maybe some might know but the info wasn't posted. Wishful thinking.

Yup, I just started trying to fine tune and optimize so will add that to my new mental check list. Hm that's really interesting. Though I'm not sure I fully grasp the concept. Does that mean all memory are allocated in 512 byte allocation blocks? If so, I would expect that the get used memory function would always be a multiple of 64KB (or 512b?). But I just tested and I get a non-multiple. I have seen that making modifications sometimes reduces memory, but other times it doesn't so I guess this could explain some of it. However, I think I'd need more explanation of what gets in 512b blocks and what doesn't.

Wow... when I disabled Running to test some stuff I guess it also unchecked Mono as well. I checked it back on and looks like the memory value is updating properly. Such a simple mistake, thanks for pointing it out! Saved me a lot of time debugging!

I'm hoping someone can may be explain if I'm not understanding some thing correctly. I've been trying to optimize memory for a script but the it's really confusing using llGetUsedMemory. I tried to do a quick, simple test where I had a global list variable and every time I touched the scripted object, it would add a randomized string to it and then print out the memory usage. What I found is that llGetUsedMemory just keeps returning the same value after adding several new list items. What am I missing? Are scripts auto allocating a big chunk of memory for my list and I'm not adding enough elements in my test to increase/reallocate/resize for more memory for the list variable?