Jump to content

Removing duplicate items in an object's inventory


Monica Balut
 Share

You are about to reply to a thread that has been inactive for 4159 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I'm creating an installer package that is rezzed and that will llGiveInventory to another object being worn as a HUD.  I can easily make the installer.

One glitch however is the possibility that the object may already contain the same item (animation or notecard).  llGiveInventory will give a duplicate item to to the object and there doesn't seem to be a way to prevent that.

So, I thought of putting a function in the receiving object to allow the user to remove duplicate items.  Items given by llGiveInventory in this way all return the NULL key to llGetInventoryKey so I can't just compare keys.  Duplicate items usually have an integer appended to the name. However, there could also be legitimately different items that happen to be named the same except for a sp-integer suffix.

I want to keep the newest added copy and delete all the other duplicates.

I'm having difficulty wrapping my head around an efficient and even reliable algorithm that will accomplish this.  There could be 1000 or so items to check in the object's inventory.  Everything I can think of would likely be slow as molasses or could delete legitimate items.

Could someone point me to an efficient algorithm to keep the newest duplicates and delete the older ones?

Perhaps I'm going about this all wrong and there's a simpler way to ensure that an installer doesn't give items that are already in the receiver's inventory.  Any insights would be appreciated.

Link to comment
Share on other sites

I like your afterthought best.  Have the installer send a pre-install pessage to the HUD that says "I'm about to send you the following items.  Do you have any of them?"  The HUD can then quickly check its own inventory for matches and send back a reply that says "OK, send me A, C, and D but not B."  Or maybe "I have B already, but let me delete it before sending me a new copy." That beats making the HUD go through receiving things it already has and then deleting them.

No matter which way you solve the problem, though, there still might be some false positives.  There's no problem if  you add an object and a notecard with the same name, because they have different inventory types.  If you add two different notecards that are each named New Notecard, though.  the second one becomes NewNotecard1.  It looks like a duplicate, but it's not.  The only way to beat that problem is to be very sure to always send items with unique names.

Link to comment
Share on other sites

1k+ items? I sense overkill.

 

how about a single notecard with all the names in the updater and a single script that that runs off of it.... send the notecard and the script first (you'd need to use script pin) or have the script already built in... script reads notecard, deletes any names in the target object, then deletes the notecard, sends a continue message to the updater, (and deletes itself if it was sent).

or like like Rolig was saying, send a message with names to delete, as long as the receiving script isn't one of those names, you are fine. can be sent from either end object, depend on if you want the new or the old to take precedence

Link to comment
Share on other sites

I took your suggestion Rolig and came up with something that works pretty well.  This installer is only loading animations and notecards.  I have the installer send the name and creator of the animations to the HUD which checks if they already are in its inventory and deletes them if they are.  With notecards I just send the name and don't delete the one in the HUD if found.  I just warn the user that the new notecard will have an integer appended to it.  Then I just llGiveInventory all the animations and notecards.

Thanks for unmuddling my brain.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4159 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...