[opensource-dev] Inventory Patch you should integrate

Oz Linden (Scott Lawrence) oz at lindenlab.com
Thu Feb 9 11:11:30 PST 2012


On 2012-02-09 13:55 , Henri Beauchamp wrote:
> Greetings,
>
> Sorry for my late reply, but I have been busy backporting multiple
> clothing layers to the Cool VL Viewer this last couple of weeks
> (released today in Cool VL Viewer v1.26.3.4)...
>
> On Mon, 6 Feb 2012 11:13:31 -0800, Jenn Leech wrote:
>
>> I should add that we are also testing inventory routing changes on those
>> sims on aditi as well. Items which are *newly* sent to your inventory
>> should show up in the Received Items folder (e.g. someone gives you an
>> item, you purchase an item etc. - these will show up in this new system
>> folder).
> And that's why it currently fails with the patch as provided by Oz for
> v2/3 and backported by me to v1. Here is an example of the log I get in
> the CG Test 8 region when hitting the "Copy And Wear" button of the
> "Objects Contents" floater on a prim (named "Copy And Wear Test"
> containing the items copied from the "Boy Next Door" stock (library)
> avatar:
>
> - On the first try, a new "Received Items" folder is created at the
> root of the inventory, but nothing appears in it (luckily, the items
> are copy-ok and therefore not gone from the container prim).
>
> - On the second try (i.e. after "Received Items" was created), I get:
>
> 2012-02-09T18:28:47Z DEBUG: createNewCategory: Using the CreateInventoryCategory capability.
> 2012-02-09T18:28:48Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5
> 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(f55dae61-cfe8-e6b6-5429-bfb973639ea9) was NULL
> 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(7371ea0b-2f57-ab08-02cb-031378564b83) was NULL
> 2012-02-09T18:28:48Z WARNING: changed: gInventory.getCategory(775690a1-f412-69c3-fafe-2e4698af15d9) was NULL
> 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'Copy And Wear Test' 2 with 1 descendents.
> .../... (repeated for each item)
> 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: ffffffff-ffff-ffff-ffff-ffffffffffff
> 2012-02-09T18:28:49Z DEBUG: accountForUpdate: accounted: 'My Inventory' 902 with 18 descendents.
> 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: 5
> 2012-02-09T18:28:49Z INFO: processBulkUpdateInventory: Bulk inventory: 76ac463f-ca9b-608b-b5f7-80d1cb519463
> 2012-02-09T18:28:49Z WARNING: accountForUpdate: No accounting for: 'Received Items' version: -1
> .../... (repeated for each item)
>
> The items then do appear in a sub-folder of "Received Items", but they
> are not worn.
>
>> We plan to announce a public beta for testing these behavior changes in the
>> next couple of weeks and have been performing primarily internal testing so
>> far.
> What we'd need now is the viewer side code dealing with the "Received
> Items" folder (obviously, it's a new system folder...<rant>another of
> these stupid folders that will crowd the root of our inventory</rant>).
>
> But I think it's a BAD IDEA to FORCE things to go into a specific folder
> from the server side (it should be the viewer to decide where it puts the
> received inventory: either at the root, like v1 always did, or in Received
> Items" if it exists or if the user configured their viewer to do this):
> the v3 viewer may perfectly reparent a folder received at the root of the
> inventory to "Received Items" folder, while a v1 viewer (or a user
> having deleted the "Received Items" folder because they don't want it)
> will not be able to deal with reparenting from a non-existent folder to
> its root folder (and the received items may be lost, which would cause
> definitive inventory loss for no-copy items...).
>
> Please, reconsider this IMO crippled protocol...
>

Henri, that protocol is not subject to change at this very late date.

Thanks for the problem report - hopefully Jenn will be able to 
coordinate with you to get a proper fix together (I'm going to be on 
vacation starting tomorrow evening for a bit over a week).





More information about the opensource-dev mailing list