The AO could be coded such that it looks at the name of the currently worn
outfit and selects the appropriate animation list for that name. I believe
the name of the currently worn outfit is sent to the viewer as it's used to
highlight it in the appearance selector menu.

I suggested the notecard approach as an alternative that could also allow
notecards in outfits for other uses besides AO animation lists. However
given that it would likely require a server side change, it's probably much
less likely to happen than just re-coding the client-side AO. Personally I
would prefer anything that is associated with my avatar to not be client
dependant as I switch computers and clients a lot.

On Sun, Apr 15, 2012 at 10:50 PM, Erin Mallory <angel_of_crim...@hotmail.com
> wrote:

>  Why would it need to be in the inventory taking up space when it would
> ONLY do the same thing that either of these options do?  If you can link a
> client ao to activate when the outfit is equipped that would satisfy the
> need for it to automatically turn on when you equip a new outfit AND keep
> the inventory MUCH less cluttered.
> The entire reason I use Firestorm's ao is so that I could get rid of as
> many copies of aos as I could and swap between ao sets almost instantly
> even in high lag areas.  Right now they do not have a way to equip
> automatically when I set an outfit, however it is two extra clicks to
> select the one I want from a dropdown.  If I could have a menu option on
> the outfit folder to allow me to associate each outfit with an AO so that
> it automatically swapped when I changed outfits that would be neat and do
> the same thing you wanted it to do.  If I wanted to change the association
> or dissociate it I could do so from the same command.
> What I envision would simply be another option with a menu item such as
> "Set AO" and contain a drop nearly identical to the list in the AO drop
> down menu except it would also have a "none" option. for example if I had
> an outfit folder named "feral neko" with several attachments and clothes in
> it and wanted to associate my Puli Neko AO with it then all I would need to
> do is right click the folder for "feral neko" select "set ao" and click
> "Neko Puli AO" and then until i changed the associated ao every time I
> equipped the outfit "feral neko" it would automatically switch the ao to
> the Neko Puli AO set.  That way i would not need any box or notecard or
> other object to clutter my already overwhelming inventory.
> Please explain what such a system would lack that either type of object
> you are talking about could provide because I simply do not see the
> benifits or requirements to have any object in the inventory other than a
> single notecard for each ao set and a copy of each animation that is
> included in any set.
>
>
>
> > CC: opensource-dev@lists.secondlife.com
> > From: secret.arg...@gmail.com
> > Subject: Re: [opensource-dev] allowing client side AO's to swtich with
> outfits
> > Date: Sun, 15 Apr 2012 21:34:30 -0500
> > To: angel_of_crim...@hotmail.com
>
> >
> > On 2012-04-15, at 12:13, Erin Mallory wrote:
> > > 1) Allow outfit folders and AO sets to be able to share a "hotkey" so
> that pressing that hotkey will both equip the outfit and activate the AO
> >
> > > 2) Script in a right click menu option at the outfit folder level that
> asks if you want to link an AO config to activate the ao when equipping the
> outfit. IE: you right click the outfit folder and when the menu pops up it
> has something like "Set outfit AO."
> >
> > Neither of these are acceptable, it _has to_ be something in the
> inventory that is managed with the inventory tools. Otherwise there's no
> reason not to keep using the existing scripted AOs.
> >
> > Ideally, it's just a box, like an existing AO, except instead of having
> a script in it it's attached to an "AO" attachment point or has a name like
> "#AO".
> >
> > Alternatively, a scripted object could run and llOwnerSay a series of
> magic strings containing the animation name and animation type, in on_rez()
> or attach().
>
> _______________________________________________
> 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

Reply via email to