Peebee McMillan

Perfect solution, thanks for this, Rolig! Using your last example in the state_entry will let me use those lists anywhere further in the script to manipulate only those specific prims. That's exactly what I needed. I don't need dialogs for this project, but good to know that would work too. And I don't need any more than 3 of those lists, so my hair is hopefully safe. But I figured this method beats setting SLPPFs on 50+ selected link numbers with PRIM_LINK_TARGET ... And god forbid, I'd have to unlink something afterwards and the link order changes. That would definately be more dangerous hair wise. Even though I'm sure there's also a solution for that, but honestly I'm much of a novice with LSL. Anyway, thanks again for your effort, you've helped me a lot. And I will use the code formatting next time, I didn't see that sneaky little icon. Best greetz!

Thanks a lot Rolig, that gives me an indication what I'd have to do. Now I may need to expand, just to make sure I'll be able to use it like that. I will actually need to generate more than one child name list and then later use those lists in SLPPFs in a listen event. Lets say some of the children are "dumplings" some are "pasta". Can I generate lists for each and use them later like this (again figuaratively): ---------------------------------------------------------------------------- listen(integer ch, string obj, key id, string msg) { if (msg == "reddumpling") { llSetLinkPrimitiveParamsFast(...gDumplingLinks...,[Do stuff]); } else if (msg == "greenpasta") { llSetLinkPrimitiveParamsFast(...gPastaLinks...,[Do other stuff]; } } ---------------------------------------------------------------------------- Sorry for the code in plain text, I have no clue how to get those code fields you're using. :smileyindifferent: Thanks again for thoughts!

Hellos out there! I've had no luck finding a solution in the depths of LSL Wiki and pretty much any other LSL source I know, so I thought I'd give it a shot here. I'm trying to find out how to do this: llSetLinkPrimitiveParamsFast( ... on all child prims named "dumpling" in this linkset ... I assume there would have to be some indexing of the linknumbers and linknames beforehand (in state_entry? Maybe in a list?!), but I can't piece together how that would work. The above pseudo-code line is just figurative to indicate what I want to do, I know it wont be that simple. :smileyvery-happy: Any thoughts are muchly appreciated! Greetz, PeeBee

Nooooo, this isn't a fight, as far as I'm concerned! :smileysurprised: Actually it's just exchanging thoughts and opinions on the subject. :smileyhappy: One can't fight about opinions, cause everyone has their own. It's just conversation. If it came across as anything else: Mea Culpa! I hate hostility in forums, that's why I hardly ever post. :smileywink:

Phil Deakins wrote: I did say "Unless you have a compelling reason" If a TPV enhances someone's experience then use it. It's my opinion that they don't enhance the experience of most people who use them, and that they only use them because they've been told they are better, which they're not, unless a person just happens to want one or two of the little extras they provide. I use Singularity with my alt, solely because it can display the older profiles, and also because it's so easy to get the key of an objects. Most people wouldn't find things like that an enhancement to their experience. I use the LL viewer for me (my main). That way I'll always be ahewad of the rest with any major fixes and changes - such as the bug in this discussion I don't agree with every statement in there, but ultimately it boils down to the fact that we are fortunate enough to choose between different viewer technology approaches and their diverse functionality and features. Anyone is free to choose for themselves, according to their individual needs and preferences. Wheither a viewer has been suggested to someone or not, doesn't change the fact that there's a free choice. And what is "better" is very subjektive to the individual. But ... and I can't help myself, but point this out ... If one observes both JIRA threads, it was a Firestorm Dev who found the solution to the bug in question here and provided LL with it. Nyx Linden even showed appreciation for the "legwork". So again, the headway is subjective as well. But I can appreciate that LL works so closely and amicably conjoint with the big TPVs. More great minds make better results. :matte-motes-wink:

As stated in both JIRAs, the issue is (was) not restricted to Firestorm, but a general code error in the avatar_lad.xml file, which is used in all viewers. Nyx Linden explained, that it was an error which has been distributed to TPVs within the code update package for fitted mesh. LL has corrected the bug in it's latest maintenance viewer, Firestorm will have it fixed in it's next bugfix release. Other TPVs will most likely do the same. There's also no reason not to use any of the third party viewers, if it enhances one's personal SL experience. :matte-motes-grin:

That is good news SaraCarena! I don't follow the LL release notes as I am an avid Firestorm User. And there is no 'resolved' status update on the JIRA as far as I can see. However, in the Firestorm JIRA report (which initially got this issue to the attention of the FS & LL devs), it has been indicated that a fix will be implimented in the next Firestorm release as well. :smileyvery-happy:

Hi Tarina. That was my very first question and attempt to fix it, too. But it's not a problem with worn mesh or the LOD settings. It's the male AV itself. The issue occurs no matter how high or low LODs are set. We've tried it from minimum to maximum on all LOD settings (Objects, Avatar etc). The problem is slowly occuring all over the blogs and JIRAs. It's a cross-platform, cross-viewer thing. Most likely server side. For all who are interested in following this, here's JIRA links to the issue on LL and Firestorm: https://jira.secondlife.com/browse/BUG-5537 http://jira.phoenixviewer.com/browse/FIRE-13312

I sincerely hope this issue will get some attention soon, because in my opinion this is severe. Again, it's not an issue with rigged or non-rigged mesh clothing. This should not be confused. For some reason the AV itself looks different to others, than it does for oneself. It effects the chest portion of any male AV and as I just discovered, the forehead portion too. It's not an obvious issue/bug, cause naturally you can't see it yourself. And it's on both the LL viewer and Firestorm, so it's apparently not a viewer issue, but related to mutual viewer code or LL servers, I'd say. The new AV rigging for fitted mesh comes to mind .... As Maxwell said, content creators will get slammed with support requests and possibly unjustified negative reviews on Marketplace. This could be a disaster, if there's no fix any time soon.