How many copies in Inventory?

[Rolig Loon]

I didn't realize until this evening, but there seems to be a limit on the number of copies of a single item that you can put in an object's inventory.  Each time you add a new copy, the asset servers increase the sequence number on the end of the copy (Object, Object 1, Object 2, Object 3, Object 4 .....) until you get to Object 33.  You can add more copies after that, but the numbering gets all wonky, and not always the same way. I get numbers like Object 33, Object 51, Object 45, Object 59 ...

I know..... Why would I put more than one copy of anything in inventory?  Because I am finishing up a dance machine, and I need to provide a fresh instance of the Dance slave script for each potential dancer.  The sequence numbers are important, so the machine screws up if instances of the script after #33 aren't in sequence. 

So, is this a real, hard limitation? If so, that's fine. I was just surprised to make this discovery and wasn't sure whether to believe it.  Is there a workaround?

[Void Singer]

I don't think that's supposed to happen.... however I have seen something similar when serially dropping items into contents.... where the server has trouble spitting the list back to you, and shows some of them, but not all of them (eventually it shows the missing ones)... sometimes with weird gaps...

 

if the items really are getting funky numbering after a certain point and it's not the above problem, then i'd file a jira, as that should not happen....

 

although more than 30 helper scripts seems a bit excessive.

[PeterCanessa Oh]

Don't throw things at me but there are two obvious work-arounds

1. have versions of your slave script whose only difference is their name (so ObjA 1 - 30, ObjB 1 - 30, etc.)
2. use several child prims to hold the slave scripts

One slighly less obvious solution is to have the slave scripts report their names to the controlling script so it doesn't matter what they're called.  I have sometimes used this where I have dynamic numbers of copies in contents.

As to the limit itself; I think the most copies of anything I've had in contents were around 20 or so (also animation slaves) so I've never encountered the restriction.

[Rolig Loon]

---

Void Singer wrote:

I don't think that's supposed to happen.... however I have seen something similar when serially dropping items into contents.... where the server has trouble spitting the list back to you, and shows some of them, but not all of them (eventually it shows the missing ones)... sometimes with weird gaps...

 

if the items really are getting funky numbering after a certain point and it's not the above problem, then i'd file a jira, as that should not happen....

 

although more than 30 helper scripts seems a bit excessive.

---

That's reassuring, sort of.  I didn't think it was supposed to happen either.  It always happens when I get to the 33rd script, so whatever it is, it's a reproducible odd behavior.... just funky after that limit. I agree that more than 30 helper scripts does seem excessive, so I'm truly not upset to have made this discovery.  I was just testing all the ways that a user could screw this thing up and was surprised to find this one.  I'll just build in an internal switch to ignore any copies after 32 and tell the user that it's a hard limit.

BTW, it's not just scripts. It does the same thing with any asset I've tested.... objects, notecards....

[Rolig Loon]

Thanks, Pete.  Yeah, those are decent solutions, although they introduce one more way for the user to get confused and mess up.  I'm trying to avoid getting trouble IMs by making this thing as transparent to the user as I can. Your less obvious solution is probably the best one, but it would mean turning my script inside out to make that work, so I think I'll pass.

[Void Singer]

if it's a no-mod item (which it doesn't seem to be, but for reference) then you could always have the scripts just grab their index in the contents to use for ordering... you can even get accurate start indexes by subtracting the index for the first copy.

[Dora Gustafson]

In my Poly Dancer I did an initialization just to play safe...
Whenever inventory has changed the master script poll all scrpts in inventory using
llMessageLinked( LINK_THIS, 0, "HELLO", NULL_KEY);
Then all agent scripts report back with:
llMessageLinked( LINK_THIS, scriptNo, "I am number", NULL_KEY);
This way the central script knows what agent scripts are there and can be used

This probably is a work around your problem
At least I never noticed the problem you describe.

Note: When you have more than 64 agent scripts your event buffer will overflow because all agent scripts report back at the 'same time'
You will need a device to overcome that:smileyhappy:

[Rolig Loon]

That's not a bad idea, Dora.  It's another way of looking at what Void and Peter were suggesting. 

I have been doing it the other way around. I use a CHANGED_INVENTORY condition to trigger a function that re-initializes several variables, one of which is the number of scripts in inventory.  That number, minus one for the main script, is the number of copies of the DaNcE slave script in inventory.  Each copy knows its own sequence number, because that's added at the end of its name when you drop it in inventory.  I keep track of which copies are currently in use and then, when a new dancer clicks to join, I assign that dancer to the available DaNcE script with the lowest sequence number. With that approach, the DaNcE slave scripts never have to tell the main script their sequence numbers. Almost all of the communication is from the main script to the slaves.