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

Ambrosia chaosstar at gmail.com
Mon Jan 19 02:59:46 PST 2009


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
>


More information about the SLDev mailing list