[opensource-dev] Open Development project: extending avatar wearables

Carlo Wood carlo at alinoe.com
Thu Mar 25 05:12:25 PDT 2010


On an equal note, it's extremely annoying that the priority
of animations is determined at creation time.

Why can't I, as user, determine in what order I want animations
to take precedence?

On Wed, Mar 24, 2010 at 10:20:19PM -0400, Glen Canaday wrote:
> Actually, I don't mind "undies, shirt, and jacket." What I'm really referring
> to is maybe 3 undies layers numbered 1,2,3. Creators can still specify which of
> those three as they do now, but the user would choose the 1, 2, 3 bit. The
> creator doesn't lose the ability to choose which of the three upper layers (or
> two lower), so they can still specify on which layer the items would look as
> intended... but the user doesn't have to stick to "gee, do I wear the garter,
> the undies, or the tattoos? But I still want to wear the glitchpants that came
> with the skirt..."
> 
> I think 1,2,3 is probably fine.. that gives 9 uppers and 6 lowers. There should
> be a limit to keep the code simple, it's just a way bigger limit!
> 
> There are content creators that give transfer on items.. and I like it that
> way. There are some (ok, one that I can name) that doesn't give multiple layers
> because she gives them xfer, which I can understand. It all comes down to smart
> permissions for the next person. But that's a key issue for the creators I
> think.
> 
> However, they'd still get to choose that their pants go on the pants layer -
> just not choose WHICH pants layer. The user would get that, and that might curb
> some people's bitching at the creators! Kind of a win-win imo...
> 
> --GC
> 
> On 03/24/2010 09:48 PM, Brent Tubbs wrote:
> 
>     I like this idea a lot.  While we're talking about about increasing
>     flexibility though, why have a low hardcoded limit to the number of layers?
>      The new tattoo and alpha layers are great, but what comes next, and how
>     long do we keep hardcoding more specific layers?  If someone wants to layer
>     on ten tattoos at once, let's let them!  At some point it makes sense to
>     throw away the pre-defined layers and just call them 1 through n.
> 
>     On the other hand, some content creators sell items in separate under-layer
>     and tattoo friendly over-layer packs.  I imagine some of them would be
>     pretty upset if the layer restrictions on all the products they've sold
>     were suddenly removed.
> 
>     Brent
> 
>     On Wed, Mar 24, 2010 at 6:21 PM, Glen Canaday <gcanaday at gmail.com> wrote:
> 
>         Nyx,
> 
>         Oh, I actually do have one functionality idea / request: rather than
>         allowing the creator to dictate the clothing layer of a wearable, can
>         we allow the wearer themselves choose where it goes? I can't tell you
>         how many times I've had to not wear something because the original
>         creator did not have the foresight to put it on a layer that makes
>         sense for that wearable, nor include a copy that goes onto the desired
>         layer.
> 
>         We might have a tattoo layer now, but most places are not offering
>         that, nor are very many people using 2.0. It would be nice to be able
>         to choose that a tattoo goes *under* the underpants since most people
>         sell tats on the unders layer and will until 2.1 or 2.2 is widely used.
>         If we get to choose which of which multiple-wearable goes on top at
>         wear time and not creation time, it allows for far more flexibility in
>         customizing an avatar's look.
> 
>         Just my $0.02, but it's hard to justify having multiple layers in my
>         mind without doing it this way.
> 
> 
>         --GC
> 
>         On 03/23/2010 12:58 PM, Nyx Linden wrote:
> 
>               The current iteration of the appearance floater needs to go away. The
>             current implementation has been held together with chicken wire, bubble
>             gum, and duct tape. It works for now, but it won't hold up to the
>             addition of multiple wearables of a given type. The currently designed
>             plan is to extend the appearance sidebar to pick up the extra
>             functionality of editing a saved outfit and editing of individual
>             wearables. I think the flow between the different stages (selecting your
>             outfit, editing your outfit, editing a wearable item) should be pretty
>             useful and intuitive. I'll be posting our initial design thoughts once
>             we get the appropriate channels set up (forums most likely).
> 
>             I will remind you, however, that this project is specifically about
>             extending the avatar functionality. Yes there is a UI element here, and
>             I'm open to discussion of various ways of presenting the UI for these
>             specific features, given that the ideas are 1) easy to use and intuitive
>             and 2) still able to be done within the given timeframe.
> 
>             It sounds, however that you're asking for the ability to "tear off" any
>             of the sidepanels into independent floaters. This is good feedback, and
>             a perspective that a number of residents share, but this project is not
>             the one that is capable of doing that. We have a design team and a
>             "Viewer interactive" team that is in charge of the overall design and
>             GUI implementation of the major elements of the viewer. I'm pretty sure
>             that they're already aware of this feedback, but I'll send it their way
>             again.
> 
>             Let's keep discussion of the multi-wearables functionality on-target,
>             please :)
> 
>             -Nyx
> 
>             Bryon Ruxton wrote:
> 
> 
>                 Could you please stop putting everything into that sidebar as the only
>                 way to access stuff. You’ve kept wanting to make this “communicator
>                 window “ before into a single un-detachable block. And despite many of
>                 use hating it and asking for you to make separate floaters, (or at
>                 least give us that option), you keep attaching everything all together
>                 again in that sidebar. This is an ill conceived approach for many of
>                 us, who are used to identify specific panels at a specific position of
>                 our choice on the screen just like . Blending it all together makes it
>                 harder in that sense.
> 
>                 I recall LL hiring a guy who worked on the Tivo interface which is a
>                 great one for its purpose. But the viewer is a much more complex
>                 interface. I see too much of the Tivo formula into this “drawer”. The
>                 worse part is that the sidebar buttons are stuck on the left side and
>                 actual move with the sidebar panel itself. That seems wrong. Button
>                 should stay at the same place on the right in an Adobe fashion for
>                 distinction purpose.
> 
>                 I wish you had studied and adopted the approach of the Adobe UIs with
>                 stackable and detachable panels and buttons on the right side (which
>                 always stay there). Their approach is a much better solution in my
>                 view that this drawer type, which is a huge waste of space right now
>                 and adding to the required amount of clicks to get somewhere.
> 
>                 In short, please reserve an option for detachable floaters as much as
>                 possible, and please
>                 consider the Adobe approach for a more flexible and customizable
>                 sidebar(s) for Version 2.x.x
> 
>                 Thank you
> 
>                 On 3/22/10 8:06 PM, "Nyx Linden" <nyx at lindenlab.com> wrote:
> 
>                     Good question! There is still a lot of detail left out of these
>                     descriptions, but we are planning on moving the UI in the
>                     appearance editor into the sidebar, along with creating a new
>                     outfit editor UI. You will still see the results of the changes
>                     you are making on your avatar in-world in real time. There will
>                     still be an "editing appearance" mode as you have now, it will
>                     just be accompanied by a panel in the sidebar instead of a
>                     separate floater.
> 
>                     - Nyx
> 
>                     On Mon, Mar 22, 2010 at 6:56 PM, Argent Stonecutter
>                     <secret.argent at gmail.com> wrote:
> 
> 
>                         On 2010-03-22, at 12:45, Nyx Linden wrote:
> 
>                             1) A new panel to edit what is stored in your saved outfit
>                             without
>                             creating a new one.
>                             This will include both an inventory view and a view of
>                             your outfit
>                             itself, so you can drag items from your inventory to your
>                             outfit without
>                             having an extra floater open
>                             2) Editing of wearable items (body parts and/or clothing
>                             objects) in the
>                             sidebar, selectable from the outfit editor
>                             3) Removal of the appearance floater
> 
> 
>                         I have a concern about this, where it comes to editing outfits
>                         containing prim parts. You have to see them in world, you
>                         can't just edit them in a sidebar window, because you may need
>                         to edit them with reference to objects in world.
> 
>                         If I'm mistaken about what "removal of the appearance floater"
>                         means, in the context of a UI designed to allow you to edit
>                         outfits without having to wear them, then I'll be happy to be
>                         corrected.
> 
> 
> 
>                     ------------------------------------------------------------------------
>                     _______________________________________________
>                     Policies and (un)subscribe information available here:
>                     http://wiki.secondlife.com/wiki/OpenSource-Dev
>                     Please read the policies before posting to keep unmoderated
>                     posting privileges
> 
> 
> 
>             _______________________________________________
>             Policies and (un)subscribe information available here:
>             http://wiki.secondlife.com/wiki/OpenSource-Dev
>             Please read the policies before posting to keep unmoderated posting privileges
> 
> 
> 
> 
>         _______________________________________________
>         Policies and (un)subscribe information available here:
>         http://wiki.secondlife.com/wiki/OpenSource-Dev
>         Please read the policies before posting to keep unmoderated posting
>         privileges
> 
> 
> 
> 

> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges


-- 
Carlo Wood <carlo at alinoe.com>


More information about the opensource-dev mailing list