[sldev] Regarding VWR-2427, expanding obj. inventory within agent inventroy

[Matt McGill]

Ah, there's an idea. It would be less satisfactory than what I had  
hoped for,
but I think plausible enough to explore.

Here's what I'm thinking: The context menu for object items in the  
inventory could be
modified to include a "view inventory" option. When this option is  
selected, the
viewer attempts to rez the object as a HUD attachment at an unoccupied
attachment point and off-screen. While waiting for the object to rez,  
the
inventory view displays "(viewing)" next to the object item in question.
When the client has determined that the rez was successful,
a floater is presented displaying the object's inventory. Inventory  
contents
can be modified as usual. When finished editing inventory, the user  
clicks
"apply" (at which point the viewer attempts to take the HUD-attached  
object
back into inventory and replaces the original item if successful) or  
"cancel"
(the HUD-attached object is simply deleted) to close the window.

As long as users are mindful of the underlying mechanism, they could  
easily
modify their scripts to detect being rezzed in this fashion and
behave appropriately (reset themselves, do nothing, etc.).

A potential issue might be accidental loss of property. Say a user  
moves a no-copy
item to the HUD-attached object, and then clicks "cancel". Even  
supposing
the functionality to attempt an "undo" of any user actions has been  
implemented,
I would imagine network instability or asset server problems could  
cause loss of
that no-copy object. In other words, right now users know that moving  
a no-copy
object around in inventory is "safe" while rezzing a no-copy object  
is "unsafe".
The proposed feature would go counter to that "common sense"  
principle by
making it "unsafe" to (from the user's point of view) move things  
around in the
inventory.

I am intrigued enough to look into this further. Naturally it would  
never go into
the trunk, but some builders/scripters might find it a useful enough  
feature for a custom
viewer build. I don't suppose the mailing list would be an  
appropriate place for me
to hash out a more detailed design - what would?

P. Spoonhammer

On Jan 19, 2009, at 5:59 AM, Ambrosia wrote:
> That would mean alot of internal change, as the object's scripts
> should not run in this case. No on_rez, no triggering, and such. We're
> talking about a huge effort here, and IMO LL already has their hands
> full on various issues.
>
> However, there's a small pet project for you. If you don't mind the
> scripts starting to run, modify the viewer to have an option that
> basically does the attach -> modify -> detach steps automatically.
> This'd require a timer, repeated checking if the object, as a matter
> of fact, already rezzed on the hud, modifying it, and sending a detach
> message afterwards. However, the client'd also have to make sure the
> modifications already got made sim-side before doing so.
>
> On Mon, Jan 19, 2009 at 11:47, Leonel Morgado  
> <leonel.morgado at gmail.com> wrote:
>> Just an idea: what if the object is rezzed as a HUD but outside  
>> the user's
>> view, and then taken back into the inventory? Wouldn't this simplify
>> matters?
>>
>> Inté,
>>
>> Leonel
>>
>>
>> -----Original Message-----
>> From: sldev-bounces at lists.secondlife.com
>> [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of  
>> kelly at lindenlab.com
>> Sent: segunda-feira, 19 de Janeiro de 2009 04:34
>> To: Matt McGill
>> Cc: sldev at lists.secondlife.com
>> Subject: Re: [sldev] Regarding VWR-2427, expanding obj. inventory  
>> within
>> agent inventroy
>>
>>> Hi Kelly,
>>>
>>> Thanks for such a prompt and detailed response!
>>>
>>> I suspected as much after reviewing the available messages. I had  
>>> been
>>> holding out hope that one could retrieve/de-serialize the asset  
>>> on the
>>> client, make the requisite changes to the object's contents, and  
>>> then
>>> serialize/store the updated asset file. However, am I correct  
>>> that the
>>> asset server is in fact not accessible by clients directly? It seems
>>> that this must be the case, but strangely I've had a hard time  
>>> confirming
>>> it via google.
>>>
>>
>> That is correct.  The viewer does not have any direct access to  
>> the asset
>> server, or the database.  All such access goes through the simulator.
>>
>>
>>> So the real problem is that the simulator must act as the go-between
>>> for the viewer and the asset server, and the simulator code  
>>> currently
>>> only supports manipulating live object inventories. Thus, any
>>> viewer-only attempt at supporting a feature like the one  
>>> described in
>>> VWR-2427 would inevitably be an ugly (and most likely unreliable)
>>> hack.
>>>
>>> Well, I shall have to find something else to serve as my hobby  
>>> project.
>>> Thanks again!
>>>
>>> P. Spoonhammer
>>>
>>> On Jan 18, 2009, at 7:19 PM, kelly at lindenlab.com wrote:
>>>
>>>> Unfortunately the design of SL makes this kind of feature rather
>>>> difficult, and especially more difficult as a viewer-only project.
>>>>
>>>> Agent inventory is conceptually a set of links or shortcuts to  
>>>> assets
>>>> (objects, sounds, textures etc).  When you manipulate agent
>>>> inventory data
>>>> is updated in a database, but the actual assets don't change.
>>>>
>>>> Assets on the other hand are *static files* that live on a (fancy,
>>>> high
>>>> performance) http server.  This includes 'objects' which live in
>>>> LLSD xml
>>>> format, including references to any inventory contents on them (and
>>>> script
>>>> state and lots more).
>>>>
>>>> When you rez an item the asset is fetched from the asset servers,
>>>> deserialized and instantiated in world.  Objects in world are *not*
>>>> assets, they are objects.  When you manipulate an object (or its
>>>> inventory) in world, it is the in memory version of that object
>>>> that is
>>>> changing on the simulator.  When you take the object (or when it  
>>>> gets
>>>> de-rezed back to inventory for any reason) then the object is
>>>> serialized
>>>> and saved as a new asset.
>>>>
>>>> With the way the system currently is, modifying an object  
>>>> (whether in
>>>> inventory or not) requires:
>>>> * An http fetch of the asset linked to by the inventory item
>>>> * Deserialization of that asset into memory
>>>> * Viewing and/or modification of the object
>>>> * Serialization of the newly modified object
>>>> * An http PUT to write a new asset
>>>> * Updating the inventory item references.
>>>>
>>>> That is, I think, a lot of work.  And a whole lot more, if it is
>>>> possible
>>>> at all, to get similar behavior with a viewer only project.
>>>>
>>>>  - Kelly
>>>>
>>>>
>>>>
>>>>> Hello all,
>>>>>
>>>>> I'm looking for a fun hobby project, and improving the SL client
>>>>> would help this humble Java programer stay current on his C++  
>>>>> skills.
>>>>>
>>>>> I've been wishing for something along the lines of the feature
>>>>> requested in VWR-2427 (https://jira.secondlife.com/browse/ 
>>>>> VWR-2427)
>>>>> for quite some time. Specifically, I was hoping to enable the  
>>>>> editing
>>>>> of an object's inventory without rezzing that object.
>>>>>
>>>>> Unfortunately, a cursory perusal of message_template.msg seems to
>>>>> indicate that the only messages that allow manipulation of an
>>>>> object's inventory are viewer->sim messages that require a rezzed
>>>>> object. Is my little project dead on arrival? Are there no  
>>>>> messages
>>>>> that can be used to manipulate inventory based on an agent and
>>>>> item Id?
>>>>>
>>>>> Thanks,
>>>>> -P. Spoonhammer
>>>>> _______________________________________________
>>>>> Policies and (un)subscribe information available here:
>>>>> http://wiki.secondlife.com/wiki/SLDev
>>>>> Please read the policies before posting to keep unmoderated  
>>>>> posting
>>>>> privileges
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.176 / Virus Database: 270.10.7/1895 - Release Date:  
>> 17-01-2009
>> 17:50
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated  
>> posting privileges
>>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges