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
<[email protected]> 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: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: segunda-feira, 19 de Janeiro de 2009 04:34
To: Matt McGill
Cc: [email protected]
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, [email protected] 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
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
