Help with storing prims in lnkset as grouped list items

[Wakizashi Yoshikawa]

Hello everyone, can anyone help me with the following issue I'm having

I want to map the prims in the linkset based on their groups, and later do something with those grouped prims. For example:

In a linkset there are prims 2,3,4 with Name(or description doesnt matter really) A. There will be also prims 5,6 with Name B, 7,8,9,10 with name C and so on. So I want basically to output the result (llOwnerSay, llSay doesn't matter) in the following manner

a:2,3,4@@b:5,6@@c:7,8,9,10 (where a is the group name, then list of prims in the group and last part is lets say group separator for easier parsing later(?))
(because of the unknown length I'm not sure that strided list would help here, correct me if I'm wrong)
Where the name of the prim will be unknown, as well as number of linked objects in the corresponding group. How can I group them by unique name of the prim name?

To avoid raising XY problem here is what I'm trying to do. Since most of the texture/color changer scripts are already using name/description for their work, I need to map the prim groups and spit out the result in chat. 
The user can put that in notecard and I will read it later from script, store it and later do things with the prims of each separate group (toggle visibility, colors etc). That way the user can map the prims, and gets the result for the notecard config, and later use his hud scripts which will occupy name/description properties...

I cant wrap my mind around it honestly so any help will be appreciated.

[KT Kingsley]

You could take a look at the LSL JSON functions which are a useful way of storing complex (by LSL standards) data structures.

Or you could make what I'll call a "variably strided" list (there's probably a formal computing name for this, but I don't know it), where each group consists of a group name, the number of items in that group, and the items themselves:

["A", 3, 2, 3, 4, "B", 2, 5, 6, "C", 4, 7, 8, 9, 10]

So to find the items in group B, you'd use llListFindList to find the index of ["B"], then index + 1 will tell you how many items there are, and the items will have indices of index + 2 through to index + 2 + count - 1.

[Nova Convair]

From your description a notecard is completely unnecessary. It's very easy for a script to manipulate all childprims with the name "A". And it's dynamic and adapts immediately to all changes without creating a new notecard.

To generate your notecard:

- loop through all prims
- for every prim: primlist += [name,link#]
- primlist = llListSort(primlist,2,TRUE);

now you have a list like: A,2,A,3,A,4,B,6,B,7, ... ,object,20,object,21 ... whatever
loop through that and for every name change add a @@name: to a string 

 

[Wakizashi Yoshikawa]

17 minutes ago, Nova Convair said:

From your description a notecard is completely unnecessary. It's very easy for a script to manipulate all childprims with the name "A". And it's dynamic and adapts immediately to all changes without creating a new notecard.

Not when your other script overwrites the name/description in its process, or I have misunderstood it so you meant the first time script is run?

Also not following the bottom part especially when I have no idea about the names to begin with (yeah, I can make them static and say "name prims groups as A,B,C etc) just wondering how would I know the name change?

[Wakizashi Yoshikawa]

20 minutes ago, KT Kingsley said:

["A", 3, 2, 3, 4, "B", 2, 5, 6, "C", 4, 7, 8, 9, 10]

So to find the items in group B, you'd use llListFindList to find the index of ["B"], then index + 1 will tell you how many items there are, and the items will have indices of index + 2 through to index + 2 + count - 1.

Thanks for the JSON functions, I seriously need to check the updates considering that I have been idle for some time, and as I explained, the group names so to call them are variable (but would probably be smarter to make them constant to avoid unknown needle in a haystack)

[KT Kingsley]

As you say, the group names could be anything. Your script would need to run through the prims in the link set and for each name,

• check whether it's already in the list
• if it is
  • use llListReplaceList to update the counter item
  • use llListInsertList to add the link number into the group
• if it's not
  • add the name to the end of the list
  • add the counter, 1, to that
  • and add the link number to that

[Qie Niangao]

21 hours ago, Wakizashi Yoshikawa said:

21 hours ago, Nova Convair said:

From your description a notecard is completely unnecessary. It's very easy for a script to manipulate all childprims with the name "A". And it's dynamic and adapts immediately to all changes without creating a new notecard. [...]

Not when your other script overwrites the name/description in its process [...]

That's something you generally want to avoid anyway, so why is this other script changing those?? For that matter, it's risky to rely on the name or description of links in a modifiable object unless the whole point is to respond to user settings of those attributes. Without knowing what this whole application is trying to do, I'll just ignore that.

I think @KT Kingsley has you pointed in a good direction now, but just in passing: I wouldn't use JSON for something like this; the data structure is simple and shallow and there's no benefit to all the baggage that comes with JSON. I's a good thing to learn about, just not useful here.

One function you may find useful in generating the desired output from these lists is llGetListEntryType(). In this simple situation you could instead try to typecast each element and test whether it worked, but calling the function seems tidier to me.

[Wakizashi Yoshikawa]

Because every single texture hud that I have seen out there (meant for designers who don't want to create their own huds for the sake of simpliciy without going into a debate how responsive reading notecard is on every single hud click) write some data in description/object name? And I can add my stuff on existing description, but highly doubt that other script will parse it properly after that (almost certain it wont). 

So to avoid storing my settings, and thinking if they will ever be overwritten by some other script (or appending the settings would break other scripts) I figured to read them for notecard (no need to leave script +mod) and store the list that way... 

Edited December 13, 2019 by Wakizashi Yoshikawa

[Qie Niangao]

Oh, okay, I misunderstood. It's not that your script might use links' name and description fields to store anything itself, but rather the concern was that these other scripts will come along later and contaminate the basis for your script's sorting of links into classes so there needs to be somewhere (a notecard) to make that classification persistent. Of course that's fragile to modification by the user relinking in a changed order, but maybe that's not a problem here.

[Wakizashi Yoshikawa]

Yeah, maybe I didn't explained why I don't work with descriptions/names, so no worries. And yeah, relinking can be the issue obviously, but thats not my top concern for now. Thanks for the input Qie