Re: [opensource-dev] allowing client side AO's to swtich with outfits
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 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
[opensource-dev] VWR-28752
Hi, I've filed this one: https://jira.secondlife.com/browse/VWR-28752 Any comments? Can someone with powers move that to STORM please? bye, LC ___ 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
Re: [opensource-dev] allowing client side AO's to swtich with outfits
On 2012-04-16, at 00:50, Erin Mallory 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? I have over 300 outfits, each with their own set of AO choices... maybe 15 or 20 different sets of AOs depending on the shape of the base avatar in the outfit, attachments, and general style of the avatar. I change avatars radically, maybe a couple of times a minute when it makes sense. I already have an appropriate AO item in the inventory for each avatar... changing them gradually over to calling the item #AO or moving its attachment point and turning the scripts off or changing the script to one that chats the Notecard to the viewer on attach, that I am willing to do. Under your scheme I will first have to manually configure the AO into the viewer, then associate it with the inventory. Then I will no longer have any record in the inventory of what AOs are associated with each outfit. If I'm using SL from another computer, or I lose the profile directory on my computer, all of that's gone, forever. There's no way I'd ever be able to reconstruct it. And for what benefit? A barely measurable drop in my script time (which is already very low), a savings of 16k of script memory (and people are routinely walking around with megabytes of scripts), and possibly better behavior in laggy areas. It's simply not worth the effort and risk. ___ 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
Re: [opensource-dev] allowing client side AO's to swtich with outfits
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 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 >> inventor
[opensource-dev] allowing client side AO's to swtich with outfits
I doubt it would be that hard to establish a way to ensure that the config could be exported to an easy to read table that can have the option to save to either a file on the computer (for easy reference) or as a single notecard within the ao folder that other viewers can read and allow you to import either manually or individually. An additional hot tip when you mouse over the folder could tell you what AO is associated with the outfit. As someone that has to constantly pack and unpack things on my two oldest accounts in order to even be able to get my inventory to fully load, the idea of having to add another item to each outfit folder I make pretty much destroys any advantage to having a system that could associate the ao with the outfit. I use in client ao systems to reduce attachments, lag, and inventory clutter. A system that relied on objects in each outfit folder would be a huge step backward for me. > 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: Mon, 16 Apr 2012 03:46:43 -0500 > To: angel_of_crim...@hotmail.com > > On 2012-04-16, at 00:50, Erin Mallory 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? > > I have over 300 outfits, each with their own set of AO choices... maybe 15 or > 20 different sets of AOs depending on the shape of the base avatar in the > outfit, attachments, and general style of the avatar. I change avatars > radically, maybe a couple of times a minute when it makes sense. I already > have an appropriate AO item in the inventory for each avatar... changing them > gradually over to calling the item #AO or moving its attachment point and > turning the scripts off or changing the script to one that chats the Notecard > to the viewer on attach, that I am willing to do. > > Under your scheme I will first have to manually configure the AO into the > viewer, then associate it with the inventory. Then I will no longer have any > record in the inventory of what AOs are associated with each outfit. If I'm > using SL from another computer, or I lose the profile directory on my > computer, all of that's gone, forever. There's no way I'd ever be able to > reconstruct it. > > And for what benefit? A barely measurable drop in my script time (which is > already very low), a savings of 16k of script memory (and people are > routinely walking around with megabytes of scripts), and possibly better > behavior in laggy areas. It's simply not worth the effort and risk. ___ 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
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
rem0ve me off your list -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Tateru Nino Sent: Saturday, April 14, 2012 2:00 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs On 14/04/2012 11:09 AM, glen wrote: > >> I don't really have any insights into the client vs. server vs. >> scripted AO debate. I think adding asynchronous events would be a >> very good short-to-medium-term solution, and any scripted AO that >> used them would probably cause low enough sim load that the whole >> question could be punted for a long time. Assuming script load is the >> reason this is being considered. >> > I think we've all gone a bit OT to be honest. All he wanted in the > first place was a quick tut on how the existing in-client AOs worked. > I'd assume he's considering adding one to the LL client. I agree with > Anne that he should probably start with the inworld scripted AOs and > then work from there as there are a lot of possibilities. That's because the AOs in TPVs are necessarily incomplete - because they cannot integrate with the server-side. If Linden Lab *were* considering just dropping similar functionality into the viewer without additional server-side integration, I'd consider that to only be half a job. ie: If Linden Lab basically copied what the TPVs do for the official viewer then creators would once again likely wind up in the position of telling customers "No, you can't use the builtin thingy. You have to use the scripted thingy instead, or it won't work properly. Why? Well, it's kind of complicated to explain..." That's a point of friction that users don't need. ___ 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
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Hello, go to https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev OR Click here and send an email (from your mailinglist-address) to unsubscribe: mailto:opensource-dev-requ...@lists.secondlife.com?subject=unsubscribe You can find these links/addresses if you view the options of one of the mailinglist-emails. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] Im Auftrag von Chico Hersey Sent: 16. April 2012 17:14 To: 'Tateru Nino'; opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs rem0ve me off your list -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Tateru Nino Sent: Saturday, April 14, 2012 2:00 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs On 14/04/2012 11:09 AM, glen wrote: > >> I don't really have any insights into the client vs. server vs. >> scripted AO debate. I think adding asynchronous events would be a >> very good short-to-medium-term solution, and any scripted AO that >> used them would probably cause low enough sim load that the whole >> question could be punted for a long time. Assuming script load is the >> reason this is being considered. >> > I think we've all gone a bit OT to be honest. All he wanted in the > first place was a quick tut on how the existing in-client AOs worked. > I'd assume he's considering adding one to the LL client. I agree with > Anne that he should probably start with the inworld scripted AOs and > then work from there as there are a lot of possibilities. That's because the AOs in TPVs are necessarily incomplete - because they cannot integrate with the server-side. If Linden Lab *were* considering just dropping similar functionality into the viewer without additional server-side integration, I'd consider that to only be half a job. ie: If Linden Lab basically copied what the TPVs do for the official viewer then creators would once again likely wind up in the position of telling customers "No, you can't use the builtin thingy. You have to use the scripted thingy instead, or it won't work properly. Why? Well, it's kind of complicated to explain..." That's a point of friction that users don't need. ___ 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
Re: [opensource-dev] allowing client side AO's to swtich with outfits
On 2012-04-16, at 09:34, Erin Mallory wrote: > I doubt it would be that hard to establish a way to ensure that the config > could be exported to an easy to read table that can have the option to save > to either a file on the computer (for easy reference) or as a single notecard > within the ao folder that other viewers can read and allow you to import > either manually or individually. An additional hot tip when you mouse over > the folder could tell you what AO is associated with the outfit. If the AO is not a single inventory item that I can copy from one folder to another, or link, or otherwise treat it as any other wearable, then I'm not going to use it because I can already do all that. > As someone that has to constantly pack and unpack things on my two oldest > accounts in order to even be able to get my inventory to fully load, the idea > of having to add another item to each outfit folder I make pretty much > destroys any advantage to having a system that could associate the ao with > the outfit. The item is _already in my folder_. There's nothing to add. > I use in client ao systems to reduce attachments, lag, and inventory > clutter. A system that relied on objects in each outfit folder would be a > huge step backward for me. If you don't need this feature there's no reason you can't keep doing whatever you're doing. ___ 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
