As much as I'm not a fan of hacks, until there's proper server-side support this is what I suggest: Dahlia, I think I've taken a liking to your suggestion of the notecard idea, but with a twist.
First, the client would create a new inventory folder named such that the likelihood of it being already in existence is extremely low. "Outfit Animations - Firestorm x.x" could be good for Firestorm, where the x's are a version code. This folder would be hidden from viewing in the client default so that it does not clutter up inventory, with an option in the client to make it visible. Inside this folder are notecards, each named after the outfit it's designed to match. These notecards contain LLSD serialized data designed to make it simple and fast for the client to pull down the animation data, update it, and store it back in the notecard. A simple GUI would be designed to make management and creation simple. Yes, this hack has the limitation that a given animation set cannot be in place for multiple outfits, but if there is a simple, easy way to clone an animation set to another outfit such would be mitigated. The ability to manually select another outfit's animation set is also an option. Ricky Cron Stardust On Mon, Apr 16, 2012 at 12:31 AM, Dahlia Trimble <dahliatrim...@gmail.com>wrote: > 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 >
_______________________________________________ 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
