Prim count per resident

[petMelite]

Hello to all,

my problem is as follows:

* There is a non-parceled sim. 

* There are more than 100 residents rezzing items on it.

* I would like to know how many prims some of these users are using.

I have tried the following and excellent script that is mentioned here, in the examples section:

llGetParcelPrimOwners - Second Life Wiki

It gives LI instead of prim count, but ok, numbers are close enough

This example, due to LSL limitations, only counts up to 100 residents, and sadly not the ones that I would need.

I understand that this is a hard limit due to LSL limitations and can not be avoided, but...

Does anyone know how llGetParcelPrimOwners chooses what 100 residents show?

 

According to my tests...

* they are not chosen ramdomly each time you run the script (it always shows the same ones).

* Distance of the owner prims to the object that contains the measuring script is NOT a factor - I have tried to run the script at different places - always the same owners are showed.

* Number of prims is not a factor (I see owners with 600, 400, 6, 2, 1 prims... but others with 500, 72 are skipped - so it is not that it shows the people that uses the most or the least prims).

* Residents username is also not a factor (I see people whose name starts with an A and a V... but others that start with P are ignored - so not alphabetic order).

Does anyone know how llGetParcelPrimOwners chooses what 100 residents show?

thanks in advance and best regards,

[Qie Niangao]

In a quick test with only four prim owners, it sorted them alphanumerically by UUID of the owner.

It's not clear how you'd use this information, though. Seems to me the easiest solution is to divide up this region into a bunch of parcels until they're each safely under 100 rezzing residents. The only other alternative that comes to mind is an exercise in sensor probes that would be unbearably tedious to script (but it wouldn't be too surprising if somebody sufficiently OCD already did a version of that). I suppose a bot could scrape the Object Owners table in About Land, but I'm not super confident that would ever list more than 100 residents either. Maybe somebody has a better idea.

[petMelite]

Thank you very much Qie Niangao,

you are totally right, the script looks for prim owners starting from the lowest alphanumerical UUID and stops when it has reached the "magical" number of 100.

In my case, it lists from UUID  "06f..." to UUID "b90..."

Any owner with a UUID higher than that is not listed.

And you are right again, I don't see how to use this info. I can not change the UUIDs or the way that llGetParcelPrimOwners works.

It is strange that it stops at 100, seems a number picked randomly, instead of 128 or 256 or 512, which are powers of 2 and therefore much more "computer" numbers, but well...

I had the hope that the order were something i could use, such as "who was the last one in rezz an item" or "who has the prim closer to the item with the counter script" but i have not had luck.

Maybe some day the llGetParcelPrimOwners  function will be updated to something more useful, i dont see why it stops counting at 100.

Yes, the best and simpliest would be to divide the region into parcels but sim owner is against that.

Anyway thank you very much for your quick and exact answer.

Best regards.

[Logan Elf]

The 100 limit is probably a pragmatic choice to limit the size of memory required for the return list. According to https://wiki.secondlife.com/wiki/User:Omei_Qunhua a key uses 102 bytes in a list, so returning 100 keys is using a whopping 10K of heap. 

I can't see that limit changing any time soon, so probably what's needed is a filterable version of llGetParcelPrimOwners, where you could specify the minimum and/or maximum prim counts. No idea if it is feasible for the simulator to return such a list in a timely manner (and unfortunately a dataserver event can only return a string).

[Lucia Nightfire]

In the 10 years I ran sandboxes, I never saw more than 100 concurrent prim owners on any one parcel.

This sounds like a 0 autoreturn time "problem" to me.