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 <gcana...@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" <n...@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.arg...@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 <ca...@alinoe.com>
_______________________________________________
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

Reply via email to