[opensource-dev] Inventory Patch you should integrate

Henri Beauchamp sldev at free.fr
Thu Feb 9 10:55:31 PST 2012


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...

Regards,

Henri.


More information about the opensource-dev mailing list