Re: [opensource-dev] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
Am Mittwoch, 24. März 2010 23:58:39 schrieb Tayra Dagostino: > On Mon, 8 Mar 2010 09:39:00 +0100 > > Lance Corrimal wrote: > > Anyways, shouldn't SLPlugin exit when it is done doing what it > > thought it should be doing? > > installed and configured Pulseaudio > now only ONE SLPlugin thread executed, with very low processor > usage. ok, switched to pulse audio here... ...after some serious KDE related headache it works now, and with way less trouble in SL tan last time i tried, at least as far as sound quality goes. except that it didn't really help with the SLPlugin issues. Still more than one running at times, eating CPU like crazy, and loads of errors... sometimes i get "no plugin for the mimetype none/none", sometimes i get popups _outside_ sl from flashplayer complaining about a "script is slowing down adobe flash player"... I'm still not convinced about any benefits of that slplugin architecture. besides... fully interactive HTML on a worn prim? ... any of you guys still remember those sandwichboard advertizing guys in the streets? When will we see the first one in SL, offering you to play mafia wars in-world? ... or how about a prim that for all intentions seems to present the login page on the SL website, but of course it is not hosted on secondlife.com at all, instead it's from somewhere in asia? how many newbies will fall for that & end up with an emptied credit card? 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] Open Development project: extendingavatarwearables
On 2010-03-25, at 18:56, Nyx Linden wrote: > Its more than two sliders. Quite frankly I don't believe this is an > acceptable solution to ship in our main client for this particular > issue - a user would expect "wear as undershirt" to "just work". I'm not proposing "wear as undershirt". I'm proposing "convert this into an undershirt". > I'll note further that such a system would only be effective for > wearables you have copy + mod permissions for. Mod, at least. But if it was restricted to copy+mod that would be OK. ___ 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] Open Development project: extendingavatarwearables
On Thu, Mar 25, 2010 at 07:56:00PM -0400, Nyx Linden wrote: > further that such a system would only be effective for wearables you > have copy + mod permissions for. No worries for your own creation, but > few sold clothing pieces are so liberal to my understanding. Imho, the usable part be a "wear as..." for no mod items. They are the once really needing it. Leaving the need for copies just to get the different layers an almost obsolote need. -- o_ Anders Arnholm, o/ /\and...@arnholm.se /|_, \\http://anders.arnholm.se/ / ` -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] Open Development project: extendingavatarwearables
It bothers me a bit that we (you) would choose to go for an implementation that is not the best or the ideal one, ONLY because you want to push out a new feature "in time". Personally, I'd first design how I'd want it to look from the user point of view (what most of the discussion from the community is about) without taking into account coding arguments. And once we have that, I'd just implement it, no matter the costs or time needed. That is what coders do: they implement what is requested. Thus, since for almost everything we said so far your argument is: we can't do that within the given timeframe; can you defend, or at least make acceptable and understandable that "a" new feature has to be added in 3 months, even if that new feauture is a bit inferior compared to what that UI could have looked like? Changing it AGAIN in the near future (ie, 6 months later) is probably not going to happen for several reasons :/ So, not doing it right now has almost the same implications as deciding to never do it. I'd really like to understand why that is the best thing to do. Thanks for discussing this with us, Carlo Wood PS With regards to the UI design. I like the concept of "click wear" inserts the wearable in a default place, after which you can reorder it. And where this inserting means "at the top of a folder that one of the currently existing wearable categories". It just makes sense. But, in the end the goal should be that wearer can determine the order of every texture layer, or at least to a great extend, including: - Tucking in jackets or not (jacket <-> pants ordering) (my proposal was to add a pseudo jacket, below or above which other jackets are below or above the pants). - Wearing shirts over jackets (jacket <-> shirt ordering) (proposal was to be able to dump a jacket in the 'shirt' folder if one wishes). ___ 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] Open Development project: extendingavatarwearables
On Thu, Mar 25, 2010 at 10:48:24PM +0100, Latif Khalifa wrote: > Not to mention that some span over more than one bake, like jacket, > tattoo and alpha. I don't think changing wearable type is feasible. +1 The type is the type. Converting types will lead us nowhere. -- Carlo Wood ___ 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] Open Development project: extendingavatarwearables (TPV policy implications)
On 2010-03-25, at 18:56, Nyx Linden wrote: > However, if you'd like to code up a conversion routine for snowglobe > or a third party viewer, please do so! Let me know if you need any > information about our wearables system to do so. Wait a second, are you saying that if a viewer allowed "wear as", reset the sliders, and let you save the wearable back as a new clothing type, that would work now? A viewer could implement changing the type of a wearable and the server wouldn't prevent it? OK, if a third party viewer did this, what would LL's response be? Would this be allowed under the TPV policy? Because this could be huge. Amazing. See, for most clothes these days, about the only sliders most people actually use are looseness for pants and sleeves (and skirts, but skirts wouldn't be a compatible type with anything). Everything else is handled by alpha in the texture layer, not in the length sliders. Setting looseness to minimum and length to maximum... hmmm... ___ 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] Open Development project: extendingavatarwearables
On Fri, Mar 26, 2010 at 05:41:10AM -0500, Argent Stonecutter wrote: > I'm not proposing "wear as undershirt". > > I'm proposing "convert this into an undershirt". But with what goal? If the goal is to be able to tuck a jacket in and wear it below other shirts, then I think it's too much of a hack. People would want to wear an item below a shirt one day and wear it over their pants another day. Converting it back is going to be a bit hard if you cut off the lower part and then make the sleeves at length again manually. If the goal is to be able to change the type, then I don't feel it should be part of this particular project. Assume that the project will result in jackets (the canonical example) can be tucked in and/or being worn under shirts. Would you really still need it to be converted to a shirt? -- Carlo Wood ___ 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] [META] Communication tools (was: Request for clarification on mailing list guidelines)
I'd prefer it if the meeting was NOT during 9-11 pm my time (CET)... but immediately after it, or immediately before it. Alternatively 1-3 pm my time could be a good alternative. Now to convert that to PST ... I believe that most of the winter and summer the difference is 9 hours, even though at the *moment* the difference is 8 hours? So, assuming 9 hours that would translate to STARTING times of: 4 AM or 5 AM (I guess that is not going to happen?) 11 AM or 2 PM. Starting times of 12 AM or 1 PM are possible, but not preferable, and I would probably not be there every time in that case (my social life in SL happens then). On Fri, Mar 26, 2010 at 5:10 AM, Philippe (Merov) Bossut < me...@lindenlab.com> wrote: > Hi, > > We discussed this subject again at the Hippo meeting today. > > Forums didn't have much takers though I'll try to spend time there and see > for myself how the dynamic works. > > The extra IW meeting was better received. Tuesday seemed to work but we > couldn't decide on a time, 2pm PST works for those present at the meeting > but the point, precisely, is to get a time that works for those who can't > make it at 2pm PST > > So, if you think you'll come to this new meeting, please propose a time > range here and I'll collate the results. I'll give more weight to those who > can't make it to the Thursday meeting. Hope we'll find a time that works. > > Cheers, > - Merov > > > > ___ > 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] Open Development project: extendingavatarwearables
On 2010-03-26, at 07:06, Carlo Wood wrote: > On Fri, Mar 26, 2010 at 05:41:10AM -0500, Argent Stonecutter wrote: >> I'm not proposing "wear as undershirt". >> >> I'm proposing "convert this into an undershirt". > > But with what goal? I've got dozens of vests and shirts and jackets on the "wrong" layers because they were part of an outfit that had wearables on weird layers to deal with the problem that this change is designed to fix, and I want to move them to a layer that makes sense now. > Assume that the project will result in jackets > (the canonical example) can be tucked in and/or being > worn under shirts. Would you really still need it to > be converted to a shirt? If the project was going to achieve that goal, then they wouldn't really *be* jackets vs shirts vs undershirts any more, they'd just be "tops". But that's not what Nyx has proposed. ___ 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] Open Development project: extendingavatarwearables
On Fri, Mar 26, 2010 at 07:39:39AM -0500, Argent Stonecutter wrote: > >Assume that the project will result in jackets > >(the canonical example) can be tucked in and/or being > >worn under shirts. Would you really still need it to > >be converted to a shirt? > > If the project was going to achieve that goal, then they wouldn't > really *be* jackets vs shirts vs undershirts any more, they'd just > be "tops". But that's not what Nyx has proposed. That is not really true. The big difference between jackets and shirts is that jackets have a texture on the lower part too. Also, the default insertion point when wearing a new item would still be different. -- Carlo Wood ___ 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] Open Development project: extendingavatarwearables
On 2010-03-26, at 08:17, Carlo Wood wrote: > On Fri, Mar 26, 2010 at 07:39:39AM -0500, Argent Stonecutter wrote: >>> Assume that the project will result in jackets >>> (the canonical example) can be tucked in and/or being >>> worn under shirts. Would you really still need it to >>> be converted to a shirt? >> >> If the project was going to achieve that goal, then they wouldn't >> really *be* jackets vs shirts vs undershirts any more, they'd just >> be "tops". But that's not what Nyx has proposed. > > That is not really true. The big difference between jackets > and shirts is that jackets have a texture on the lower part > too. Also, the default insertion point when wearing a new > item would still be different. Doing this right (ie, starting from a clean slate, or going to 'new type' clothing with legacy wearables mapped to the new scheme when edited): 1. All tops would have a lower part. It would just be empty for many wearables. 2. The default insertion point would just be a suggestion, and probably just a number 0..31 (or even 0..255) "shirt" would be an alias for "16". ___ 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] Open Development project: extendingavatarwearables
On Fri, Mar 26, 2010 at 9:39 AM, Argent Stonecutter wrote: Doing this right (ie, starting from a clean slate, or going to 'new type' clothing with legacy wearables mapped to the new scheme when edited): 1. All tops would have a lower part. It would just be empty for many wearables. 2. The default insertion point would just be a suggestion, and probably just a number 0..31 (or even 0..255) "shirt" would be an alias for "16". -- This would be a great thing especially if the mapping for the sliders was extended to include a decimal in the range (ie length 94.3 instead of just 94 ) of course while we are dreaming it would also be good if the color picker would recognize the HTML 4.01 named colors (like the gimp dialog does) -- Robert L Martin ___ 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] Open Development project: extendingavatarwearables
+1 A 'change type' feature isn't needed for this project. Nyx's proposed category layout can override the type as old types are just hints. Possible with an ability to just drag-n-drop a wearable between categories. The proposed outfit list would allow more for arbitrary lists that wouldn't depend on type hints or any new ordinals for layer priority, yet a complete UI for such feature is not expected this cycle in the main viewer as noted. The solution is here, however, with further development. Instead of any need to convert a type into a new type, the category list can be converted to an outfit list that make sense. One can just wear the outfit list instead of wear the specific type. For example, the outfit list could be a notecard with a specific description to denote it as a wearable, which the viewer reads to fill in the category list when worn. Maybe you want superman underwear worn underneath blue pants, so your create a werable notecard called 'Kent'. You also can create a notecard called 'Superman' that then lists the superman underwear over the blue pants. To change layer order is now simply an action to either wear 'Kent' outfit or wear 'Superman' outfit, even though both lists contain specific wearables. With such outfit lists, there is never a need to 'change type' on a specific wearable. Carlo Wood wrote: > If the goal is to be able to change the type, then > I don't feel it should be part of this particular > project. > ___ 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] Open Development project: extendingavatarwearables
Nyx Linden wrote: > It would also require completely de-constructing the current layers > system, and rebuilding it based on the added parameters (I'd actually > argue making the parameters part of the links used to create an outfit, > not the wearables themselves but that's a side note). A while back, the order of the "makeup" and "skin" layers (I know that's not their official names) was temporarily reversed (with comical consequences) as a "bug fix" (see VWR-12962), so it is certainly possible to reorder them. I don't know where these new multiples fit in though, since I haven't looked at the new 2.0 code. I'm sure residents would want to do "this jacket, then this shirt, and now this other jacket" and the design many not have had the foresight to expect that. But that would be a good thing to incorporate before release. Mike ___ 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] Open Development project: extendingavatarwearables
On Fri, Mar 26, 2010 at 06:56, Carlo Wood wrote: > It bothers me a bit that we (you) would choose to go > for an implementation that is not the best or the > ideal one, ONLY because you want to push out a new > feature "in time". > *Carlo, it pains me to see you have this attitude towards the Lindens...especially those who are in here trying to communicate with us. ***Linden Labs has limited resources*** They can't just magically allocate time and money to a feature that would be awesome because you think so. They have time and money constraints.* > > Personally, I'd first design how I'd want it to look > from the user point of view (what most of the discussion > from the community is about) without taking into account > coding arguments. And once we have that, I'd just > implement it, no matter the costs or time needed. > That is what coders do: they implement what is requested. > This is a blind perspective to have. Coding constraints come into play because coding takes time and when you are on a payroll with a budget, time = money. You have to sacrifice the really awesome feature that will take a while for the ones that are easy, but have an ok benefit. *The Lindens aren't tools, my friend. Perhaps showing more respect for them will give you respect in return by getting us new features. And, keep in mind, this is an OpenSource forum. If you have an idea, make it happen and pitch it to us. Code it yourself and post it to the open forum. The lindens have enough on their plate as it is which is why they went the opensource route to begin with...having the assistance of the community make a better product.* > > Thus, since for almost everything we said so far your > argument is: we can't do that within the given timeframe; > can you defend, or at least make acceptable and understandable > that "a" new feature has to be added in 3 months, even if > that new feauture is a bit inferior compared to what > that UI could have looked like? > *Again, show some respect here. The lindens have a lot on their plate and are wanting you to make a business case for this. They need to know a feasible, tangible way they can impliment feature ABC while not over taxing their resources. Also, this feature needs to be used by the whole and not a small percentage of users.* > > Changing it AGAIN in the near future (ie, 6 months later) > is probably not going to happen for several reasons :/ > So, not doing it right now has almost the same implications > as deciding to never do it. I'd really like to understand > why that is the best thing to do. > > Thanks for discussing this with us, > Carlo Wood > > PS With regards to the UI design. > I like the concept of "click wear" inserts the wearable > in a default place, after which you can reorder it. > And where this inserting means "at the top of a folder > that one of the currently existing wearable categories". > It just makes sense. > > But, in the end the goal should be that wearer can > determine the order of every texture layer, or at > least to a great extend, including: > - Tucking in jackets or not (jacket <-> pants ordering) > (my proposal was to add a pseudo jacket, below or > above which other jackets are below or above the pants). > - Wearing shirts over jackets (jacket <-> shirt ordering) > (proposal was to be able to dump a jacket in the 'shirt' > folder if one wishes). > > ___ > 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 > *In conclusion, have a little more common courtesy. The fact that the Lindens are participating as often as they are and engaging in good conversation should be something you shouldn't take for granted. Think good business.* ___ 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] Open Development project: extendingavatarwearables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This clean slate would need additional texture swatches for the other components of existing types of wearables, including the gradients for the different cuts (sleeve length, cleavage amount etc On 26/3/2010 10:39, Argent Stonecutter wrote: > > On 2010-03-26, at 08:17, Carlo Wood wrote: > >> On Fri, Mar 26, 2010 at 07:39:39AM -0500, Argent Stonecutter wrote: Assume that the project will result in jackets (the canonical example) can be tucked in and/or being worn under shirts. Would you really still need it to be converted to a shirt? >>> >>> If the project was going to achieve that goal, then they wouldn't >>> really *be* jackets vs shirts vs undershirts any more, they'd just >>> be "tops". But that's not what Nyx has proposed. >> >> That is not really true. The big difference between jackets >> and shirts is that jackets have a texture on the lower part >> too. Also, the default insertion point when wearing a new >> item would still be different. > > Doing this right (ie, starting from a clean slate, or going to 'new > type' clothing with legacy wearables mapped to the new scheme when > edited): > > 1. All tops would have a lower part. It would just be empty for many > wearables. > > 2. The default insertion point would just be a suggestion, and > probably just a number 0..31 (or even 0..255) "shirt" would be an > alias for "16". > ___ > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkutE1AACgkQ8ZFfSrFHsmXs2wCfSJgyI9oWSyPfDvdLx7xj2Dkz FVYAnRRyw/dkEp7W+jTJ8EiKS5vfHMND =Gbrx -END PGP SIGNATURE- ___ 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] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I believe those are called "sandwich men" On 26/3/2010 05:29, Lance Corrimal wrote: > Am Mittwoch, 24. März 2010 23:58:39 schrieb Tayra Dagostino: >> On Mon, 8 Mar 2010 09:39:00 +0100 >> >> Lance Corrimal wrote: >>> Anyways, shouldn't SLPlugin exit when it is done doing what it >>> thought it should be doing? >> >> installed and configured Pulseaudio >> now only ONE SLPlugin thread executed, with very low processor >> usage. > > ok, switched to pulse audio here... > > > ...after some serious KDE related headache it works now, and with way less > trouble in SL tan last time i tried, at least as far as sound quality goes. > except that it didn't really help with the SLPlugin issues. Still more than > one running at times, eating CPU like crazy, and loads of errors... > > sometimes i get "no plugin for the mimetype none/none", sometimes i get > popups > _outside_ sl from flashplayer complaining about a "script is slowing down > adobe flash player"... > > > I'm still not convinced about any benefits of that slplugin architecture. > > besides... fully interactive HTML on a worn prim? > > ... any of you guys still remember those sandwichboard advertizing guys in > the > streets? When will we see the first one in SL, offering you to play mafia > wars in-world? > > ... or how about a prim that for all intentions seems to present the login > page on the SL website, but of course it is not hosted on secondlife.com at > all, instead it's from somewhere in asia? how many newbies will fall for that > & end up with an emptied credit card? > > > 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkutE34ACgkQ8ZFfSrFHsmV1aQCeMKOzGuvH4Zf0gYY4B6MkpQTN z9gAn3+q/Th72xZ4v66/lv8WDTF5v/SQ =Yh4s -END PGP SIGNATURE- ___ 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] Open Development project: extendingavatarwearables
Jonathan, I have no disrespect at all for Nyx. And yes, it's highly appreciated that he asks us for input instead of just implementing it. Still, if nothing in his original design is going to be changed then the effect is almost the same; except if this list is convinced that his original design is indeed the best. Apparently that stands or falls with having time (money) to do anything beyond what he already planned to do, and therefore explaining that is the only way to make the list understand this. Hence my question. Not because I think he is wrong, but because I want to know (and understand): Why not implement the extra requests from this list and then release the whole feature three months later? Imho it IS better to delay the feature and release a really well-thought-out new feature that will really work for a long time, than to be 3 months sooner and have people feel frustrated about little shortcomings for the next 3 years. Specifically to Jonathan: I'm sure this is a misunderstanding in the way my post came across. I appologise for that. It's sometimes hard to come accross correctly in written emails (I'm not even good at it in RL). On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote: > > On Fri, Mar 26, 2010 at 06:56, Carlo Wood wrote: > > It bothers me a bit that we (you) would choose to go > for an implementation that is not the best or the > ideal one, ONLY because you want to push out a new > feature "in time". > > > Carlo, it pains me to see you have this attitude towards the > Lindens...especially those who are in here trying to communicate with us. > ***Linden Labs has limited resources*** They can't just magically allocate > time > and money to a feature that would be awesome because you think so. They have > time and money constraints. > > > Personally, I'd first design how I'd want it to look > from the user point of view (what most of the discussion > from the community is about) without taking into account > coding arguments. And once we have that, I'd just > implement it, no matter the costs or time needed. > That is what coders do: they implement what is requested. > > > This is a blind perspective to have. Coding constraints come into play > because > coding takes time and when you are on a payroll with a budget, time = money. > You have to sacrifice the really awesome feature that will take a while for > the > ones that are easy, but have an ok benefit. > > The Lindens aren't tools, my friend. Perhaps showing more respect for them > will give you respect in return by getting us new features. And, keep in > mind, > this is an OpenSource forum. If you have an idea, make it happen and pitch it > to us. Code it yourself and post it to the open forum. The lindens have > enough on their plate as it is which is why they went the opensource route to > begin with...having the assistance of the community make a better product. > > > Thus, since for almost everything we said so far your > argument is: we can't do that within the given timeframe; > can you defend, or at least make acceptable and understandable > that "a" new feature has to be added in 3 months, even if > that new feauture is a bit inferior compared to what > that UI could have looked like? > > > Again, show some respect here. The lindens have a lot on their plate and are > wanting you to make a business case for this. They need to know a feasible, > tangible way they can impliment feature ABC while not over taxing their > resources. Also, this feature needs to be used by the whole and not a small > percentage of users. > > > Changing it AGAIN in the near future (ie, 6 months later) > is probably not going to happen for several reasons :/ > So, not doing it right now has almost the same implications > as deciding to never do it. I'd really like to understand > why that is the best thing to do. > > Thanks for discussing this with us, > Carlo Wood > > PS With regards to the UI design. > I like the concept of "click wear" inserts the wearable > in a default place, after which you can reorder it. > And where this inserting means "at the top of a folder > that one of the currently existing wearable categories". > It just makes sense. > > But, in the end the goal should be that wearer can > determine the order of every texture layer, or at > least to a great extend, including: > - Tucking in jackets or not (jacket <-> pants ordering) > (my proposal was to add a pseudo jacket, below or > above which other jackets are below or above the pants). > - Wearing shirts over jackets (jacket <-> shirt ordering) > (proposal was to be able to dump a jacket in the 'shirt' > folder if one wishes). > > ___ > Policies and (un)subscribe information available he
Re: [opensource-dev] Open Development project: extending avatar wearables
This is a pretty generic question, but I hope it will be helpful. Under what conditions might it be possible to do a fairly quick to release version and then iterate the feature behavior towards something more sophisticated, without breaking things? Best regards, Joel On 3/26/10, Carlo Wood wrote: > Jonathan, > > I have no disrespect at all for Nyx. And yes, it's highly appreciated > that he asks us for input instead of just implementing it. > > Still, if nothing in his original design is going to be changed > then the effect is almost the same; except if this list is > convinced that his original design is indeed the best. > > Apparently that stands or falls with having time (money) to do > anything beyond what he already planned to do, and therefore > explaining that is the only way to make the list understand this. > > Hence my question. Not because I think he is wrong, but because > I want to know (and understand): Why not implement the extra > requests from this list and then release the whole feature > three months later? Imho it IS better to delay the feature and > release a really well-thought-out new feature that will really > work for a long time, than to be 3 months sooner and have people > feel frustrated about little shortcomings for the next 3 years. > > Specifically to Jonathan: I'm sure this is a misunderstanding > in the way my post came across. I appologise for that. It's > sometimes hard to come accross correctly in written emails > (I'm not even good at it in RL). > > On Fri, Mar 26, 2010 at 02:52:39PM -0500, Jonathan Irvin wrote: >> >> On Fri, Mar 26, 2010 at 06:56, Carlo Wood wrote: >> >> It bothers me a bit that we (you) would choose to go >> for an implementation that is not the best or the >> ideal one, ONLY because you want to push out a new >> feature "in time". >> >> >> Carlo, it pains me to see you have this attitude towards the >> Lindens...especially those who are in here trying to communicate with us. >> ***Linden Labs has limited resources*** They can't just magically allocate >> time >> and money to a feature that would be awesome because you think so. They >> have >> time and money constraints. >> >> >> Personally, I'd first design how I'd want it to look >> from the user point of view (what most of the discussion >> from the community is about) without taking into account >> coding arguments. And once we have that, I'd just >> implement it, no matter the costs or time needed. >> That is what coders do: they implement what is requested. >> >> >> This is a blind perspective to have. Coding constraints come into play >> because >> coding takes time and when you are on a payroll with a budget, time = >> money. >> You have to sacrifice the really awesome feature that will take a while >> for the >> ones that are easy, but have an ok benefit. >> >> The Lindens aren't tools, my friend. Perhaps showing more respect for >> them >> will give you respect in return by getting us new features. And, keep in >> mind, >> this is an OpenSource forum. If you have an idea, make it happen and >> pitch it >> to us. Code it yourself and post it to the open forum. The lindens have >> enough on their plate as it is which is why they went the opensource route >> to >> begin with...having the assistance of the community make a better product. >> >> >> Thus, since for almost everything we said so far your >> argument is: we can't do that within the given timeframe; >> can you defend, or at least make acceptable and understandable >> that "a" new feature has to be added in 3 months, even if >> that new feauture is a bit inferior compared to what >> that UI could have looked like? >> >> >> Again, show some respect here. The lindens have a lot on their plate and >> are >> wanting you to make a business case for this. They need to know a >> feasible, >> tangible way they can impliment feature ABC while not over taxing their >> resources. Also, this feature needs to be used by the whole and not a >> small >> percentage of users. >> >> >> Changing it AGAIN in the near future (ie, 6 months later) >> is probably not going to happen for several reasons :/ >> So, not doing it right now has almost the same implications >> as deciding to never do it. I'd really like to understand >> why that is the best thing to do. >> >> Thanks for discussing this with us, >> Carlo Wood >> >> PS With regards to the UI design. >> I like the concept of "click wear" inserts the wearable >> in a default place, after which you can reorder it. >> And where this inserting means "at the top of a folder >> that one of the currently existing wearable categories". >> It just makes sense. >> >> But, in the end the goal should be that wearer can >> determine the order of every texture layer, or at >> least to a great extend, including: >> - Tucking in jackets or not (jacket
Re: [opensource-dev] Open Development project: extendingavatar wearables
On Thu, Mar 25, 2010 at 11:08 AM, Nyx Linden wrote:
>
> We're trying to make the system as flexible as possible. Think of it
> this way: you have a bunch of 'categories' or 'slots' - one for each
> type of wearable (pants, shirts, jackets). Inside each category, you can
> have multiple items up to a reasonable maximum. When you "wear" a shirt,
> it gets added to the top of the list of shirts that you are wearing. If
> you don't want it to be on top, you can push it down below other shirts.
>
> [snip]
>
> there is not a concept of a "shirt1" slot, vs "shirt 2" etc - the list
> of your shirts can change size according to how many shirts you want to
> wear at the time. The order in which you wear your clothing is
> completely up to the end-user who is constructing the outfit.
>
> a couple things to note with this approach:
> 1) the listed order of clothing probably will change to something that
> makes a bit more sense.
> 2) the list is wearable-focused, not texture-focused. Hence tattoos
> won't be split up into upper/lower/head, as they are a single wearable item.
> 3) the "order" will be able to be changed frequently and will not
> require any change to the item itself - only how it is stored in
> inventory. Hence, you don't need mod privs to re-order a shirt.
>
> Thus, pants are not inherently set to "pants 3", they're just pants! The
> consumer of said pants will determine if there are any other pants above
> or below it. This has the other advantage of allowing you to take a
> single pair of pants ("blue jeans") and having it be the bottom layer in
> one outfit, and the 3rd layer in a different outfit, even if they refer
> to the same wearable item!
>
> I hope that clarifies the proposed design - I hope to get more detailed
> information up in a central location sometime next week. In the
> meantime, keep poking at the proposal on-list!
>
> -Nyx
I really like this design, for the most part. But I think it would be
much better, and would address everyone's wishes for more flexibility
in clothing order, if a few things were changed:
1. Instead of having categories for each wearable type (shirts, pants,
shoes, etc.), have categories for "layer" (as when getting dressed in
RL):
* Outer Layer: jacket, gloves, shoes
* Inner Layer: shirt, pants, and skirt
* Under Layer: underpants, undershirt, and socks
* Body Layer: skin, tattoos, and (maybe) alpha
This is just an example. I'm not picky about the number of layers, or
what they're called, or which types go in which layer. But the idea is
that higher layers render on top of lower layers. The same is also
true within each category, an Nyx said: higher items render on top of
lower items.
2. When a wearable is worn, it goes to the top of the appropriate
layer (as above). But the user can open up the outfit editor and drag
the wearable to any layer they want, or reorder the items within a
layer. I think this would be a good solution, because wearing clothes
would "just work", yet users still have total control over the order
of layers, with a simple and natural way of modifying the order.
- Jacek
___
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] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
zOmg ty. I know have my first wearable html prim object project. I couldn't think of a *use* for that!! --GC On 03/26/2010 04:29 AM, Lance Corrimal wrote: > Am Mittwoch, 24. März 2010 23:58:39 schrieb Tayra Dagostino: > >> On Mon, 8 Mar 2010 09:39:00 +0100 >> >> Lance Corrimal wrote: >> >>> Anyways, shouldn't SLPlugin exit when it is done doing what it >>> thought it should be doing? >>> >> installed and configured Pulseaudio >> now only ONE SLPlugin thread executed, with very low processor >> usage. >> > ok, switched to pulse audio here... > > > ...after some serious KDE related headache it works now, and with way less > trouble in SL tan last time i tried, at least as far as sound quality goes. > except that it didn't really help with the SLPlugin issues. Still more than > one running at times, eating CPU like crazy, and loads of errors... > > sometimes i get "no plugin for the mimetype none/none", sometimes i get popups > _outside_ sl from flashplayer complaining about a "script is slowing down > adobe flash player"... > > > I'm still not convinced about any benefits of that slplugin architecture. > > besides... fully interactive HTML on a worn prim? > > ... any of you guys still remember those sandwichboard advertizing guys in the > streets? When will we see the first one in SL, offering you to play mafia > wars in-world? > > ... or how about a prim that for all intentions seems to present the login > page on the SL website, but of course it is not hosted on secondlife.com at > all, instead it's from somewhere in asia? how many newbies will fall for that > & end up with an emptied credit card? > > > 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 > ___ 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] [solved?] Re: SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?
We have already seen the first sandwich men in SL, experiments with that have happened early on. One of those times was I believe 06, during the beginning of the hype. It came to be because of the LlLoadURL function, for the first time it was possible to link to the web from a Object. -- Jeroen Frans Virtual World Technology Specialist. VesuviusGroup.com SL: Frans Charming On Sat, Mar 27, 2010 at 1:58 AM, Glen Canaday wrote: > zOmg ty. I know have my first wearable html prim object project. I > couldn't think of a *use* for that!! > > --GC > > On 03/26/2010 04:29 AM, Lance Corrimal wrote: > > Am Mittwoch, 24. März 2010 23:58:39 schrieb Tayra Dagostino: > > > >> On Mon, 8 Mar 2010 09:39:00 +0100 > >> > >> Lance Corrimal wrote: > >> > >>> Anyways, shouldn't SLPlugin exit when it is done doing what it > >>> thought it should be doing? > >>> > >> installed and configured Pulseaudio > >> now only ONE SLPlugin thread executed, with very low processor > >> usage. > >> > > ok, switched to pulse audio here... > > > > > > ...after some serious KDE related headache it works now, and with way > less > > trouble in SL tan last time i tried, at least as far as sound quality > goes. > > except that it didn't really help with the SLPlugin issues. Still more > than > > one running at times, eating CPU like crazy, and loads of errors... > > > > sometimes i get "no plugin for the mimetype none/none", sometimes i get > popups > > _outside_ sl from flashplayer complaining about a "script is slowing down > > adobe flash player"... > > > > > > I'm still not convinced about any benefits of that slplugin architecture. > > > > besides... fully interactive HTML on a worn prim? > > > > ... any of you guys still remember those sandwichboard advertizing guys > in the > > streets? When will we see the first one in SL, offering you to play > mafia > > wars in-world? > > > > ... or how about a prim that for all intentions seems to present the > login > > page on the SL website, but of course it is not hosted on secondlife.comat > > all, instead it's from somewhere in asia? how many newbies will fall for > that > > & end up with an emptied credit card? > > > > > > 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 > > > > ___ > 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
