Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
This is fixed internally in the ECC project branch. Once that merges into viewer-development (we have the same submission process for merging as you guys do!), I'll post here to ask everyone to test out the fix. Thanks! -Nyx Nyx Linden wrote: Its a bug. We're going to fix it. This isn't the final behavior. -Nyx Trilo Byte wrote: I thought that was the whole point of creating outfit folders to begin with. Get your avatar looking exactly the way you want, attachments and all, then save it to a folder for fast/easy/fun one click wardrobe change. New behavior makes outfit folders decidedly less fast/easy/fun to work with. On Aug 27, 2010, at 1:12 PM, Kadah wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/27/2010 8:37 AM, Trilo Byte wrote: Nyx, I did also notice that if you wear an outfit folder that makes use of mutliple attachments in v2.1.2, it no longer works properly. Instead of putting on all the items in the user-specified folder, it only puts on the first attachment the viewer gets to. Any additional ones are left un-worn, and must be added to the outfit manually, one at a time. I can verifiy this is the case with 2.1.2.208673. Made a new outfit that has 2 tails, took everything off, did wear-replace with new outfit. Saw the first one pop on for a moment then replaced by the 2nd one a moment later. Wear-add had the same effect. Kinda defeats the purpose of 2's outfits if it don't work together with multi-attach :P Would be nice if I could also put on all items in a folder with multi-attach. Would be nice for those infrequently used collection of items that aren't associated to any one outfit. Its a little confusing now that add has different meanings on different items. Add on a single item attaches it without replace, add on a folder/outfit replaces existing on same points. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMeBw+AAoJEIdLfPRu7qE2DTMH/iuCUdlibLH4Xt64AaJa3Cnt 8RjXYbtkm3MjtgK/m+a+lV/lngO7regiVshDMUo55mdUbzA0MNgI9bdsEkXJQfzY NJQGr5bcC4ls3clnY9oVOSdZKncuq0N/tU6Smno8Y4M4LzCmIj2WEyjWC77U9sOC bTtmGwHdTnJqEWGVuei1ABvg5QgLaqBymSKTVcXyGr2wVtEC+HxTSYFWKe33tyow 7Uvvw/yO0fn5sXfdgacCpepRdlq73Z6BDHMyOFd2KMZHQ+eRiL15cbua5BLE09ui NeBmu8NMMvFkCKpBvl0cEhnI+DklHmYFxmxNdYpMpOMwCzWdES0luVZ1kyFHkeM= =ZQJu -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 ___ 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] Removal of the MultipleAttachments debug settings ?
On 2010-08-31, at 22:40, Glen Canaday wrote: Gamers like it broken like it is now, people who SOCIALIZE here (since SL is, in fact, *not* a game... ahem) like it broken the way it's historically been. It wasn't broken historically: it was a prefs setting. Also, gamers don't like it the way it is, seems like they want to completely lose the chat bar on hitting enter: http://jira.secondlife.com/browse/VWR-18323 The current behavior doesn't work well for either camp. ___ 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] Removal of the MultipleAttachments debug settings ?
On Wed, 01 Sep 2010 13:46:10 -0700 Kadah kadah.c...@gmail.com wrote: I prefer WASD movement, but the current method has a lot of focus control issues where enter doesn't always bring focus to the chat bar. I'm having to use the mouse all the time to do this. I htink is better give as option to residents, a lot of ppl got crazy without a fixed focus on chatbar... ___ 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] Removal of the MultipleAttachments debug settings ?
On 2010-08-30, at 15:39, Suz Dollar wrote: *cough* If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. If I can't talk without jumping I'm not going to go to V2 no matter how many attachment points it has. ___ 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] Removal of the MultipleAttachments debug settings ?
Been over that and over that on the list. The only way to get that taken care of is to fix it ourselves and have LL merge it in. I'd do it if I were 'up to the task' but anyone who does do it just needs to remember to have it set up as a pref setting. Gamers like it broken like it is now, people who SOCIALIZE here (since SL is, in fact, *not* a game... ahem) like it broken the way it's historically been. Either way, it's broken for someone. Just need the check box for b0rken other way. --GC On Tue, 2010-08-31 at 12:24 +0200, Francesco Rabbi wrote: Il giorno 31/ago/2010, alle ore 12:11, Argent Stonecutter secret.arg...@gmail.com ha scritto: On 2010-08-30, at 15:39, Suz Dollar wrote: *cough* If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. If I can't talk without jumping I'm not going to go to V2 no matter how many attachment points it has. Yes Focus should be fixed... ___ 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] Removal of the MultipleAttachments debug settings ?
*cough* If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. *cough* Ok, a bit snarky, but seriously, if we HIDE the COOL stuff, where's the fire to get people over the pain of a UI transition and into using the new viewer and all it has to offer? I know we still have problems, but things like this and the alpha clothing layers should be helping entice people to work around those issues til fixed. Charlene Trudeau Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a little backwards ? Why not set MultipleAttachments to TRUE by default and let the user choose in the preferences or in the navbar as I did ? I for one would very much like to see the MultipleAttachments debug setting come back and stay ! Marine ___ 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] Removal of the MultipleAttachments debug settings ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2010 1:39 PM, Suz Dollar wrote: If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. It worked for Emerald. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMfBgUAAoJEIdLfPRu7qE2pUsH/jthvhKGh7WM+RUvv/lKNZVj OqQo8oJXUqMkf0Cu13dvhjbKX7V4SxGGH0523Ise7S9do7K03fMJgUx6lI3F6ug7 fWjl1LcHMBkG33P60uYDiYwb6WllSfEHIdGlrw0JgSyWPigOsaT5KtsAn8ZQVwV6 h5gpgDIZyWLqENcFSQjD7VI64q63/KZaJc2/NyEa6QEuBh0dRj7zc4lBPw9iT/PR ST+hf8gMWeChMNQygsAam8SSL/KduEmfkCmUqcc7aeDORp3y0hItNqAsgm393jRh c18ESbwrQTOpfySh5du7lHgB0SZyZHRsDIgdCJftHI/qIWvyXkZxVVhfgs90PQg= =1Ya0 -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] Removal of the MultipleAttachments debug settings ?
On Mon, 30 Aug 2010 13:44:04 -0700 Kadah kadah.c...@gmail.com wrote: If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. It worked for Emerald. Emerald use a tweaked code+xml, only an emerald see correctly another emerald user... now there is a standard, already used by a lot of non-linden viewers (is why i'm staring EM blog waiting for the right release than stop to see fuzzy attachments fly around sims XD) and no, attachments are a bit feature of emerald, the most is the radar, a lot of ppl can save lag using builtin radar in place of a laggy hud... for sl2 cannot work, why if somebody say you use [only_one_viewer] ___ 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] Removal of the MultipleAttachments debug settings ?
The way emerald works and others is no good solution couse as you sayd you can only see it with those viewers AND it dosent even work for hud objects, how viewer 2 works now is it do works accross all viewers AND it works for hud objects and as for the radar thing, Kristens viewer already added sort of that to (and thats on viewer 2) and couse allot of people saying viewer 2 sucks couse they miss the things in emerald YET emerald refuses to work on viewer 2 (WHY) if evreyone dont like it start working on it! and make it bether thats what opensource should be, and not refuse to work on couse you dont like it. annyway sorry for hijacking this treath but get 100 of mails so one more dont mather -.- On Mon, 30 Aug 2010 13:44:04 -0700 Kadah kadah.c...@gmail.com wrote: If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. It worked for Emerald. Emerald use a tweaked code+xml, only an emerald see correctly another emerald user... now there is a standard, already used by a lot of non-linden viewers (is why i'm staring EM blog waiting for the right release than stop to see fuzzy attachments fly around sims XD) and no, attachments are a bit feature of emerald, the most is the radar, a lot of ppl can save lag using builtin radar in place of a laggy hud... for sl2 cannot work, why if somebody say you use [only_one_viewer] ___ 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] Removal of the MultipleAttachments debug settings ?
On Mon, 30 Aug 2010 23:15:17 +0200 Alexandrea Fride babytje...@live.com wrote: The way emerald works and others is no good solution couse as you sayd you can only see it with those viewers AND it dosent even work for hud objects, how viewer 2 works now is it do works accross all viewers AND it works for hud objects and as for the radar thing, Kristens viewer already added sort of that to (and thats on viewer 2) and couse allot of people saying viewer 2 sucks couse they miss the things in emerald YET emerald refuses to work on viewer 2 (WHY) if evreyone dont like it start working on it! and make it bether thats what opensource should be, and not refuse to work on couse you dont like it. annyway sorry for hijacking this treath but get 100 of mails so one more dont mather -.- i think is only proudness while somebody say is the MY viewer, till few time ago there are few solutions, but now in snowstorm project things are quite different, now all this can be a real opensource community, in place to create dozens of *SAME* viewer (same core, same main features) with few addons all people can throw patches in same pot (i know i'm a dreamer) so maybe a day we can have a amazing rocking viewer, with the solid core from LL, a friendly interface with granular parameters setup like emerald, with floatings and dockable tabs and sidebar like kirsten, with a clean code like in imprudence and a cross platform know-how addicted by a lot of developers with specific skills in each OS ___ 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] Removal of the MultipleAttachments debug settings ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2010 2:04 PM, Altair Sythos Memo wrote: On Mon, 30 Aug 2010 13:44:04 -0700 Kadah kadah.c...@gmail.com wrote: If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. It worked for Emerald. Emerald use a tweaked code+xml, only an emerald see correctly another emerald user... now there is a standard, already used by a lot of non-linden viewers (is why i'm staring EM blog waiting for the right release than stop to see fuzzy attachments fly around sims XD) and no, attachments are a bit feature of emerald, the most is the radar, a lot of ppl can save lag using builtin radar in place of a laggy hud... for sl2 cannot work, why if somebody say you use [only_one_viewer] I know that a lot of people switched to emerald just because of the multi-attachment hack. It wasn't a good solution to the problem but LL took so long to do anything about adding new attachment points that this ended up be norm for a good portion of the grid. Emerald's multi-attachment works by using the modified avatar_lad.xml (I think it was based off the one from VWR-489) to duplicate all the existing points on to unused upper attachment point IDs. This messes with scripts as the attachment point isn't defined serverside and requires other users to have the same modified avatar_lad in order not to see the attachments on these points just floating randomly where the avatar first rezed for that users. LL *finally* delivered their solution for more attachment points. They essentially added slots to each attachment point, the actual number of slots is unknown to me, but it seems to be greater than 2. Attach one thing and it goes to the first slot, add a second thing to your appearance that uses the same attachment point and its pushes the first item, and any others also there, back a slot. I mention that it pushing the others back cause non-2.x viewers will only see the last added thing, the top most slot. As far as I know without testing it again, if they remove the top most item on a attachment point, 1.x viewers will see nothing on that point, the items the lower slots do not move back up when the first is removed. While this is not perfect and 1.x viewers will not see attachment on the higher slots, this is a bit nicer than some random clothing floating around. And its likely someone will backport it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMfDZWAAoJEIdLfPRu7qE2UK0IAMXxtXU46lKUPbvuPDjVkTNt 6SeqUczWvWJJsEeZ6UnJC83+oySMUavP1FYS/R3p3B+obBPbU0akykdX7lE0kaKV WGdal5XWZtBaJk/HeUOAE/ErXZOEC4yRv0WrlbSKMWL6xNq6Mne3vRs/q8oqNdn3 UdbQebcG73WSR0ap6IIe23XL4JLfABum0cIx6lbvXDlLKD+QIoCj6G6I77uX3qLF xwA+MdImeSTRu5iDFDi0e3caesZjhScAHpYCC8lEaQyBu8xH1mvSzPslhkkMuhgp JwGfch5UmaeJXiWVyWjs5c05Luvdtsa4FzpFpWJOU5mjLyZYXfWWW0nQx8NsBhI= =o3mT -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] Removal of the MultipleAttachments debug settings ?
On 8/30/2010 3:04 PM, Altair Sythos Memo wrote: On Mon, 30 Aug 2010 13:44:04 -0700 Kadahkadah.c...@gmail.com wrote: If the point of this is to make people *want* 2.x a lot of nice tags that say 'to see me properly, use viewer 2.x... I have more attachments than you do' might be a good way to go. It worked for Emerald. Emerald use a tweaked code+xml, only an emerald see correctly another emerald user...snip Someone can edit and add the additional attachment points to the avatar_lad.xml file for the other viewer(s). I've done this for the 2.1.2 viewer and it seems to work. Note that you can't simply copy the avatar_lad.xml from Emerald to 2.x. This way a 2.x viewer can see the Emerald attachments correctly, and still have use of the newer multi-attachment feature too. Essentially making it backwards compatible with Emerald, but Emerald still cannot see the newer attachments. --- As an avatar builder I intend to start stating which features/viewers my avatars are designed to be compatible with. This may lower my business since there will be viewers my avatars will not be compatible with, but I also cannot wait several months for Emerald and other third party viewers to catch up to the official viewer's capabilities. Gosh... Wasn't too long ago I would have said that Emerald was much more advanced than the official viewer... Now it's flipped around for me. - Obsidian Stormwind ___ 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] Removal of the MultipleAttachments debug settings ?
On 8/30/2010 19:38, David Couchenour wrote Someone can edit and add the additional attachment points to the avatar_lad.xml file for the other viewer(s). I've done this for the 2.1.2 viewer and it seems to work. Note that you can't simply copy the avatar_lad.xml from Emerald to 2.x. This way a 2.x viewer can see the Emerald attachments correctly, and still have use of the newer multi-attachment feature too. Essentially making it backwards compatible with Emerald, but Emerald still cannot see the newer attachments. I disagree. The proper way to implement multiattach is to recognize a list and render them all.. everyone that was using Emeralds ugly hack needs a backwards compatible kludge that isnt ever going to be forwards compatible. So to equip viewer 2 with the kludgy emerald attachment points would be to bake the kludge into the mainstream and we dont want that. I would suggest instead the following user story... As a user who has become familiar with the TPV extensions to avatar_lad.xml I want the official viewer to recognize those hacked additions and silently convert them to multiattach-compatible additions to the attachment list on the appropriate point. ___ 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] Removal of the MultipleAttachments debug settings ?
The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words, at any time one can only have one object attached at a given position with any given bit set. Suppose you think that 8 bits are enough, then the following holds: * = old 'wear' behavior: replaces everything else. * = 'add' behavior: is added, replaces nothing. * 0001 = (for example): assign default meaning 'jacket' for chest attachments (jacket collars and hoodies). * 0010 = (for example): assign default meaning 'shirt' for chest attachments (shirt collars). * 0100 = (for example): assign default meaning 'necklace' for chest attachments. and so on. This allows users to make groups of attachments that are mutually exclusive, but having up till 8 classes that can be worn at the same time on the same attachment point. Personally I think that those bits also should be added to normal wearables, so that it is possible to have attachments being removed when you wear a new shirt (ie, a shirt without a collar should remove all existing shirt-collars, or wearing a penis could automatically remove underwear and pants and visa versa, Linden shoes could remove prim shoes, etc, all user customizable for his/her own attachments; the default naming would be just a hint to make things work reasonable after just having bought it). I'm not sure, but I think that having eight classes per attachment points should be enough, so adding a single byte to every object should be enough. On Thu, Aug 26, 2010 at 10:43 PM, Nyx Linden n...@lindenlab.com wrote: however, so if you have suggestions for better ways of exposing the functionality, please do let us know! ___ 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] Removal of the MultipleAttachments debug settings ?
I fail to see how your example could undermine the bits-proposal. For a start, the bits *only* add possibilities (254 per object!). Currently the ONLY existing behavior is as if my bits are already in place, but set to when you 'wear' something, and to when you 'add' something. Adding the bits will just open up a whole scala of control over how your attachments replace other attachments (and clothing?). On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi syt...@gmail.com wrote: You lost quite all good taste of this feature Ppl should be free to add everything in funny/weird way, and creators cannot be limited matching which bit another creator use... The possibilities only increase, as I just explained. You can still add anything in every way possible. I specifically said that each user should be able to change the bits of objects even if those objects are no modify. You can always just set all bits to 0, then you can wear anything and everything at the same time. The solution is resident side: outfits folders, may be interesting mark boxes or vendors to create automatically outfit folders maybe Lets look at your example. I added comment on the right. Example: -outfit naked Hair --- Head attachament SHAPE NO bits (or all 0) Skin NO bits (or all 0) Genitalia --- Pelvis attachment -outfit sport All above but genitalia Jeans--- covers genitalia Shirt Shirt collar --- Chest attachment Necklace --- Chest attachment Shoes --- Feet attachments Ok, so a user could set the same bit on the Genitalia object as on the pants. Then they would become mutual exclusive, which is what you want apparently (and which makes sense since pants cover genitalia. Pants that don't should just NOT set that bit). Assuming that it looks good if you wear the necklace and the shirt collar at the same time: put them in different classes so they won't replace each other when worn. replace outfit should revert from to other, without got creators crazy replace outfit is an entirely different thing than wear attachment/clothing. The usual meaning is that EVERYTHING is removed and then things in the folder are added. If a vendor or box can be enganced with outfit (over buy content and buy copy) I think daily outfit management by the users is more important than the urge to control how and what the users wear by vendors. If things bought by users don't work out of the box, then they will have to manually remove a few things, just like now. But at least they'll be able to automate that and not have to worry about having the add and remove attachments/clothing EVERY time, when wearing stuff from inventory. Any change to wearing a new outfit that is in a just-bought box is orthogonal to my proposal. ( all this marked with a giant IMHO) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words, at any time one can only have one object attached at a given position with any given bit set. Suppose you think that 8 bits are enough, then the following holds: * = old 'wear' behavior: replaces everything else. * = 'add' behavior: is added, replaces nothing. * 0001 = (for example): assign default meaning 'jacket' for chest attachments (jacket collars and hoodies). * 0010 = (for example): assign default meaning 'shirt' for chest attachments (shirt collars). * 0100 = (for example): assign default meaning 'necklace' for chest attachments. and so on. This allows users to make groups of attachments that are mutually exclusive, but having up till 8 classes that can be worn at the same time on the same attachment point. Personally I think that those bits also should be added to normal wearables, so that it is possible to have attachments being removed when you wear a new shirt (ie, a shirt without a collar should remove all existing shirt-collars, or wearing a penis could automatically remove underwear and pants and visa versa, Linden shoes could remove prim shoes, etc, all user customizable for his/her own attachments; the default naming would be just a hint to make things work reasonable after just having bought it). I'm not sure, but I think that having eight classes per attachment points should be enough, so adding a
Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
Maybe i not understand well, now if i want i can wear a collar from a creator on a shirt made by somebody else, if viewer lock me on a fixed wearing strutture imho is a pain IF a user want create fast combination of clothes and attachments without waste time clicking one per time each item can use outfits folders, without overload viewers with code than limit residents creativity in outfit composing. If i want wear me undie ON my jeans i must be free to do it :) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:48, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: I fail to see how your example could undermine the bits-proposal. For a start, the bits *only* add possibilities (254 per object!). Currently the ONLY existing behavior is as if my bits are already in place, but set to when you 'wear' something, and to when you 'add' something. Adding the bits will just open up a whole scala of control over how your attachments replace other attachments (and clothing?). On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi syt...@gmail.com wrote: You lost quite all good taste of this feature Ppl should be free to add everything in funny/weird way, and creators cannot be limited matching which bit another creator use... The possibilities only increase, as I just explained. You can still add anything in every way possible. I specifically said that each user should be able to change the bits of objects even if those objects are no modify. You can always just set all bits to 0, then you can wear anything and everything at the same time. The solution is resident side: outfits folders, may be interesting mark boxes or vendors to create automatically outfit folders maybe Lets look at your example. I added comment on the right. Example: -outfit naked Hair --- Head attachament SHAPE NO bits (or all 0) Skin NO bits (or all 0) Genitalia --- Pelvis attachment -outfit sport All above but genitalia Jeans--- covers genitalia Shirt Shirt collar --- Chest attachment Necklace --- Chest attachment Shoes --- Feet attachments Ok, so a user could set the same bit on the Genitalia object as on the pants. Then they would become mutual exclusive, which is what you want apparently (and which makes sense since pants cover genitalia. Pants that don't should just NOT set that bit). Assuming that it looks good if you wear the necklace and the shirt collar at the same time: put them in different classes so they won't replace each other when worn. replace outfit should revert from to other, without got creators crazy replace outfit is an entirely different thing than wear attachment/clothing. The usual meaning is that EVERYTHING is removed and then things in the folder are added. If a vendor or box can be enganced with outfit (over buy content and buy copy) I think daily outfit management by the users is more important than the urge to control how and what the users wear by vendors. If things bought by users don't work out of the box, then they will have to manually remove a few things, just like now. But at least they'll be able to automate that and not have to worry about having the add and remove attachments/clothing EVERY time, when wearing stuff from inventory. Any change to wearing a new outfit that is in a just-bought box is orthogonal to my proposal. ( all this marked with a giant IMHO) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words, at any time one can only have one object attached at a given position with any given bit set. Suppose you think that 8 bits are enough, then the following holds: * = old 'wear' behavior: replaces everything else. * = 'add' behavior: is added, replaces nothing. * 0001 = (for example): assign default meaning 'jacket' for chest attachments (jacket collars and hoodies). * 0010 = (for example): assign default meaning 'shirt' for chest attachments (shirt collars). * 0100 = (for example): assign default meaning 'necklace' for chest attachments. and so on. This allows users to make groups of attachments that are mutually exclusive, but having up till 8 classes that can be worn at the same time on the same attachment point.
Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
Are we saying it will actually be impossible for a scripter to prevent users attaching other objects at the same point as the object being scripted? Or even detect that another attachment is using the same point? Combat systems tend to rely on that to enforce 'one weapon per user' rules. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Francesco Rabbi Sent: 27 August 2010 13:57 To: Aleric Inglewood Cc: opensource-dev Subject: Re: [opensource-dev] Removal of the MultipleAttachments debug settings ? Maybe i not understand well, now if i want i can wear a collar from a creator on a shirt made by somebody else, if viewer lock me on a fixed wearing strutture imho is a pain IF a user want create fast combination of clothes and attachments without waste time clicking one per time each item can use outfits folders, without overload viewers with code than limit residents creativity in outfit composing. If i want wear me undie ON my jeans i must be free to do it :) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:48, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: I fail to see how your example could undermine the bits-proposal. For a start, the bits *only* add possibilities (254 per object!). Currently the ONLY existing behavior is as if my bits are already in place, but set to when you 'wear' something, and to when you 'add' something. Adding the bits will just open up a whole scala of control over how your attachments replace other attachments (and clothing?). On Fri, Aug 27, 2010 at 2:20 PM, Francesco Rabbi syt...@gmail.com wrote: You lost quite all good taste of this feature Ppl should be free to add everything in funny/weird way, and creators cannot be limited matching which bit another creator use... The possibilities only increase, as I just explained. You can still add anything in every way possible. I specifically said that each user should be able to change the bits of objects even if those objects are no modify. You can always just set all bits to 0, then you can wear anything and everything at the same time. The solution is resident side: outfits folders, may be interesting mark boxes or vendors to create automatically outfit folders maybe Lets look at your example. I added comment on the right. Example: -outfit naked Hair --- Head attachament SHAPE NO bits (or all 0) Skin NO bits (or all 0) Genitalia --- Pelvis attachment -outfit sport All above but genitalia Jeans--- covers genitalia Shirt Shirt collar --- Chest attachment Necklace --- Chest attachment Shoes --- Feet attachments Ok, so a user could set the same bit on the Genitalia object as on the pants. Then they would become mutual exclusive, which is what you want apparently (and which makes sense since pants cover genitalia. Pants that don't should just NOT set that bit). Assuming that it looks good if you wear the necklace and the shirt collar at the same time: put them in different classes so they won't replace each other when worn. replace outfit should revert from to other, without got creators crazy replace outfit is an entirely different thing than wear attachment/clothing. The usual meaning is that EVERYTHING is removed and then things in the folder are added. If a vendor or box can be enganced with outfit (over buy content and buy copy) I think daily outfit management by the users is more important than the urge to control how and what the users wear by vendors. If things bought by users don't work out of the box, then they will have to manually remove a few things, just like now. But at least they'll be able to automate that and not have to worry about having the add and remove attachments/clothing EVERY time, when wearing stuff from inventory. Any change to wearing a new outfit that is in a just-bought box is orthogonal to my proposal. ( all this marked with a giant IMHO) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 14:11, Aleric Inglewood aleric.inglew...@gmail.com ha scritto: The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words
Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
Nyx, I did also notice that if you wear an outfit folder that makes use of mutliple attachments in v2.1.2, it no longer works properly. Instead of putting on all the items in the user-specified folder, it only puts on the first attachment the viewer gets to. Any additional ones are left un-worn, and must be added to the outfit manually, one at a time. On Aug 27, 2010, at 5:11 AM, Aleric Inglewood wrote: The following has been proposed before: * Add new bits to each object (all existing objects should act as if all bits are set). * Give the bits a default meaning (read: human readable word, which can be different per attachment point), but allow each user to override those descriptions locally. * Allow users to change the bits for each of their objects, even no-modify ones. * If a user 'wears' (or adds, which becomes redundant) a new attachment, then remove those attachments that have one or more of the same bits set. In other words, at any time one can only have one object attached at a given position with any given bit set. Suppose you think that 8 bits are enough, then the following holds: * = old 'wear' behavior: replaces everything else. * = 'add' behavior: is added, replaces nothing. * 0001 = (for example): assign default meaning 'jacket' for chest attachments (jacket collars and hoodies). * 0010 = (for example): assign default meaning 'shirt' for chest attachments (shirt collars). * 0100 = (for example): assign default meaning 'necklace' for chest attachments. and so on. This allows users to make groups of attachments that are mutually exclusive, but having up till 8 classes that can be worn at the same time on the same attachment point. Personally I think that those bits also should be added to normal wearables, so that it is possible to have attachments being removed when you wear a new shirt (ie, a shirt without a collar should remove all existing shirt-collars, or wearing a penis could automatically remove underwear and pants and visa versa, Linden shoes could remove prim shoes, etc, all user customizable for his/her own attachments; the default naming would be just a hint to make things work reasonable after just having bought it). I'm not sure, but I think that having eight classes per attachment points should be enough, so adding a single byte to every object should be enough. On Thu, Aug 26, 2010 at 10:43 PM, Nyx Linden n...@lindenlab.com wrote: however, so if you have suggestions for better ways of exposing the functionality, please do let us know! ___ 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] Removal of the MultipleAttachments debug settings ?
I thought that was the whole point of creating outfit folders to begin with. Get your avatar looking exactly the way you want, attachments and all, then save it to a folder for fast/easy/fun one click wardrobe change. New behavior makes outfit folders decidedly less fast/easy/fun to work with. On Aug 27, 2010, at 1:12 PM, Kadah wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/27/2010 8:37 AM, Trilo Byte wrote: Nyx, I did also notice that if you wear an outfit folder that makes use of mutliple attachments in v2.1.2, it no longer works properly. Instead of putting on all the items in the user-specified folder, it only puts on the first attachment the viewer gets to. Any additional ones are left un-worn, and must be added to the outfit manually, one at a time. I can verifiy this is the case with 2.1.2.208673. Made a new outfit that has 2 tails, took everything off, did wear-replace with new outfit. Saw the first one pop on for a moment then replaced by the 2nd one a moment later. Wear-add had the same effect. Kinda defeats the purpose of 2's outfits if it don't work together with multi-attach :P Would be nice if I could also put on all items in a folder with multi-attach. Would be nice for those infrequently used collection of items that aren't associated to any one outfit. Its a little confusing now that add has different meanings on different items. Add on a single item attaches it without replace, add on a folder/outfit replaces existing on same points. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMeBw+AAoJEIdLfPRu7qE2DTMH/iuCUdlibLH4Xt64AaJa3Cnt 8RjXYbtkm3MjtgK/m+a+lV/lngO7regiVshDMUo55mdUbzA0MNgI9bdsEkXJQfzY NJQGr5bcC4ls3clnY9oVOSdZKncuq0N/tU6Smno8Y4M4LzCmIj2WEyjWC77U9sOC bTtmGwHdTnJqEWGVuei1ABvg5QgLaqBymSKTVcXyGr2wVtEC+HxTSYFWKe33tyow 7Uvvw/yO0fn5sXfdgacCpepRdlq73Z6BDHMyOFd2KMZHQ+eRiL15cbua5BLE09ui NeBmu8NMMvFkCKpBvl0cEhnI+DklHmYFxmxNdYpMpOMwCzWdES0luVZ1kyFHkeM= =ZQJu -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] Removal of the MultipleAttachments debug settings ?
Its a bug. We're going to fix it. This isn't the final behavior. -Nyx Trilo Byte wrote: I thought that was the whole point of creating outfit folders to begin with. Get your avatar looking exactly the way you want, attachments and all, then save it to a folder for fast/easy/fun one click wardrobe change. New behavior makes outfit folders decidedly less fast/easy/fun to work with. On Aug 27, 2010, at 1:12 PM, Kadah wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/27/2010 8:37 AM, Trilo Byte wrote: Nyx, I did also notice that if you wear an outfit folder that makes use of mutliple attachments in v2.1.2, it no longer works properly. Instead of putting on all the items in the user-specified folder, it only puts on the first attachment the viewer gets to. Any additional ones are left un-worn, and must be added to the outfit manually, one at a time. I can verifiy this is the case with 2.1.2.208673. Made a new outfit that has 2 tails, took everything off, did wear-replace with new outfit. Saw the first one pop on for a moment then replaced by the 2nd one a moment later. Wear-add had the same effect. Kinda defeats the purpose of 2's outfits if it don't work together with multi-attach :P Would be nice if I could also put on all items in a folder with multi-attach. Would be nice for those infrequently used collection of items that aren't associated to any one outfit. Its a little confusing now that add has different meanings on different items. Add on a single item attaches it without replace, add on a folder/outfit replaces existing on same points. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMeBw+AAoJEIdLfPRu7qE2DTMH/iuCUdlibLH4Xt64AaJa3Cnt 8RjXYbtkm3MjtgK/m+a+lV/lngO7regiVshDMUo55mdUbzA0MNgI9bdsEkXJQfzY NJQGr5bcC4ls3clnY9oVOSdZKncuq0N/tU6Smno8Y4M4LzCmIj2WEyjWC77U9sOC bTtmGwHdTnJqEWGVuei1ABvg5QgLaqBymSKTVcXyGr2wVtEC+HxTSYFWKe33tyow 7Uvvw/yO0fn5sXfdgacCpepRdlq73Z6BDHMyOFd2KMZHQ+eRiL15cbua5BLE09ui NeBmu8NMMvFkCKpBvl0cEhnI+DklHmYFxmxNdYpMpOMwCzWdES0luVZ1kyFHkeM= =ZQJu -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 ___ 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] Removal of the MultipleAttachments debug settings ?
On Fri, 27 Aug 2010 17:39:38 -0400 Nyx Linden n...@lindenlab.com wrote: Its a bug. We're going to fix it. This isn't the final behavior. dunno if related or not, just asking before open a JIRA now in mouselook i see hair and other face attachments (piercing, cigarette, hair), is this right? ___ 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] Removal of the MultipleAttachments debug settings ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/27/2010 3:03 PM, Altair Sythos Memo wrote: dunno if related or not, just asking before open a JIRA now in mouselook i see hair and other face attachments (piercing, cigarette, hair), is this right? Me too, I opened a Jira for it; VWR-21002 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMeEt9AAoJEIdLfPRu7qE2k98IAJoHXqLvFBxCriY++2q9kmGp MyJVLDafhMLebacooE7Sycse2yXcOOmqM6YdpyXXGgq83TPyxmbiJSVwoIAzWWAf tmWg8Fhl7vbn0nB3FMJJqixmsmHKbaEd4uPmnRV8Z57OeKtziI0/PTF/9wqWykIn l0OUp3PVgN8BZdWFoyCVLzbm4FzBjSUD4rJtp+Z+NCFe054sz1FnxyEvTUAV/pt3 vv7yW9wq3sTd1Y9/WoeLy2QGAYUD2wrPGA0IzAVRD6Y8IOsWbhMWJBzV+9Y5Qpss ISYFzBK3GSmjtab/DTslkLMX3NB2RIJ6OmZdjZ6xF+LUe5reWT8g3iqXaxequLc= =rqVv -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] Removal of the MultipleAttachments debug settings ?
On Thu, 26 Aug 2010 21:06:53 +0100 Aidan Thornton makos...@gmail.com wrote: I for one would very much like to see the MultipleAttachments debug setting come back and stay ! i use multiple attachments, quite all users (but not emerald neither imprudence) see them correctly, all kirsten viewers (on kirsten is enabled by default on last 2 builds) rezz them fine, both SL2 users (if they don't turn TRUE the debug options too, they say...) So in other words, exactly what Marine Kelley said - they only show up properly for users of Viewer 2 or a third-party viewer based on it. That's quite a lot of Second Life users who won't be able to see some attachments you're wearing in an unpredictable fashion. with my bad eng i was trying to confirm... XD ___ 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] Removal of the MultipleAttachments debug settings ?
Trying to confirm the change (and how attachments look/don't look to 1.x clients), and am finding that in 2.1.2 (298569) multiple attachments just appears to be broken. I don't see a debug setting, I'm not finding a preference option, and the feature is definitely not working in-world. Putting on a belt is taking off coat-tails, and vice-versa. TriloByte Zanzibar On Aug 26, 2010, at 12:45 PM, Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a little backwards ? Why not set MultipleAttachments to TRUE by default and let the user choose in the preferences or in the navbar as I did ? I for one would very much like to see the MultipleAttachments debug setting come back and stay ! Marine ___ 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] Removal of the MultipleAttachments debug settings ?
MultipleAttachments was a debug setting we were using for testing multi-attachments internally because we didn't have sufficient UI for specifying what happened when you went to wear an item on your avatar. To be clear, the setting MultipleAttachments affected the wear option for attachments as follows: FALSE: When set to false, any time you wear an attachment, it would replace all attachments at that point. If you're wearing three things on your head, and you wear something on your head, all three will be replaced with the new attachment. Result: you're wearing a single attachment on your head. TRUE: When set to true, any time you wear an attachment, it would ignore whatever attachments were at that point and add the attachment onto that point. For example, if you're wearing three attachments on your head and you wear something new, you will end up with four things on your head. We've removed the debug setting as we've implemented this functionality directly in the user interface, making the debug setting completely unnecessary. With the latest code if you wear an attachment on your head, it will act as if MultipleAttachments was set to FALSE - it will replace everything else on your head. We have a new option in the UI which we've labeled add - which will act as if MultipleAttachments is TRUE - that is it will add the attachment to the attachment point, without removing the existing attachments. With both of these options being available through the UI, there is no need for the debug option anymore. If you don't want to use multi-attachments, all you need to do is make sure you use the wear option instead of the add option. If this is not working as I've described, then let us know as we have some bugs to fix :) Let me know if this clarifies things. -Nyx Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a little backwards ? Why not set MultipleAttachments to TRUE by default and let the user choose in the preferences or in the navbar as I did ? I for one would very much like to see the MultipleAttachments debug setting come back and stay ! Marine ___ 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] Removal of the MultipleAttachments debug settings ?
My mistake, then. When I performed the same action to wear an item as I had in previous builds and got the unexpected/unwanted result, and saw that the debug option was gone, I thought it had broken (like anti-aliasing did in the latest build). When this viewer gets released. it would be helpful if this change in behavior was blogged and documented. I think it makes a lot of sense, but double-clicking on an item or right-clicking and choosing 'wear' is what I imagine most people would do. Trilo On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote: MultipleAttachments was a debug setting we were using for testing multi-attachments internally because we didn't have sufficient UI for specifying what happened when you went to wear an item on your avatar. To be clear, the setting MultipleAttachments affected the wear option for attachments as follows: FALSE: When set to false, any time you wear an attachment, it would replace all attachments at that point. If you're wearing three things on your head, and you wear something on your head, all three will be replaced with the new attachment. Result: you're wearing a single attachment on your head. TRUE: When set to true, any time you wear an attachment, it would ignore whatever attachments were at that point and add the attachment onto that point. For example, if you're wearing three attachments on your head and you wear something new, you will end up with four things on your head. We've removed the debug setting as we've implemented this functionality directly in the user interface, making the debug setting completely unnecessary. With the latest code if you wear an attachment on your head, it will act as if MultipleAttachments was set to FALSE - it will replace everything else on your head. We have a new option in the UI which we've labeled add - which will act as if MultipleAttachments is TRUE - that is it will add the attachment to the attachment point, without removing the existing attachments. With both of these options being available through the UI, there is no need for the debug option anymore. If you don't want to use multi-attachments, all you need to do is make sure you use the wear option instead of the add option. If this is not working as I've described, then let us know as we have some bugs to fix :) Let me know if this clarifies things. -Nyx Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a little backwards ? Why not set MultipleAttachments to TRUE by default and let the user choose in the preferences or in the navbar as I did ? I for one would very much like to see the MultipleAttachments debug setting come back and stay ! Marine ___ 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] Removal of the MultipleAttachments debug settings ?
Correct, that is what most people will do, and that's why we wanted to keep the behavior of double click / wear to be consistent with how the functionality worked in 1.23.X, as that's what most people are used to those functions doing. Since multi-wearables is a new feature, using the new functionality warranted using a new right click menu option. We'd like to keep things consistent for old users and offer new functionality for those who would like to take advantage of it. Its a fairly simple implementation for the UI for controlling multiwearables, however, so if you have suggestions for better ways of exposing the functionality, please do let us know! -Nyx Trilo Byte wrote: My mistake, then. When I performed the same action to wear an item as I had in previous builds and got the unexpected/unwanted result, and saw that the debug option was gone, I thought it had broken (like anti-aliasing did in the latest build). When this viewer gets released. it would be helpful if this change in behavior was blogged and documented. I think it makes a lot of sense, but double-clicking on an item or right-clicking and choosing 'wear' is what I imagine most people would do. Trilo On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote: MultipleAttachments was a debug setting we were using for testing multi-attachments internally because we didn't have sufficient UI for specifying what happened when you went to wear an item on your avatar. To be clear, the setting MultipleAttachments affected the wear option for attachments as follows: FALSE: When set to false, any time you wear an attachment, it would replace all attachments at that point. If you're wearing three things on your head, and you wear something on your head, all three will be replaced with the new attachment. Result: you're wearing a single attachment on your head. TRUE: When set to true, any time you wear an attachment, it would ignore whatever attachments were at that point and add the attachment onto that point. For example, if you're wearing three attachments on your head and you wear something new, you will end up with four things on your head. We've removed the debug setting as we've implemented this functionality directly in the user interface, making the debug setting completely unnecessary. With the latest code if you wear an attachment on your head, it will act as if MultipleAttachments was set to FALSE - it will replace everything else on your head. We have a new option in the UI which we've labeled add - which will act as if MultipleAttachments is TRUE - that is it will add the attachment to the attachment point, without removing the existing attachments. With both of these options being available through the UI, there is no need for the debug option anymore. If you don't want to use multi-attachments, all you need to do is make sure you use the wear option instead of the add option. If this is not working as I've described, then let us know as we have some bugs to fix :) Let me know if this clarifies things. -Nyx Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a little backwards ? Why not set MultipleAttachments to TRUE by default and let the user choose in the preferences or in the navbar as I did ? I for one would very much like to see the MultipleAttachments debug setting come back and stay ! Marine
Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
I understand, it makes sense, thanks for your reply Nyx. I did see the Add option on 2.1.0 along with MultipleAttachments there too so I assumed both were needed for some reason (this debug setting was used in a few places in the code). On 26 August 2010 22:43, Nyx Linden n...@lindenlab.com wrote: Correct, that is what most people will do, and that's why we wanted to keep the behavior of double click / wear to be consistent with how the functionality worked in 1.23.X, as that's what most people are used to those functions doing. Since multi-wearables is a new feature, using the new functionality warranted using a new right click menu option. We'd like to keep things consistent for old users and offer new functionality for those who would like to take advantage of it. Its a fairly simple implementation for the UI for controlling multiwearables, however, so if you have suggestions for better ways of exposing the functionality, please do let us know! -Nyx Trilo Byte wrote: My mistake, then. When I performed the same action to wear an item as I had in previous builds and got the unexpected/unwanted result, and saw that the debug option was gone, I thought it had broken (like anti-aliasing did in the latest build). When this viewer gets released. it would be helpful if this change in behavior was blogged and documented. I think it makes a lot of sense, but double-clicking on an item or right-clicking and choosing 'wear' is what I imagine most people would do. Trilo On Aug 26, 2010, at 1:24 PM, Nyx Linden wrote: MultipleAttachments was a debug setting we were using for testing multi-attachments internally because we didn't have sufficient UI for specifying what happened when you went to wear an item on your avatar. To be clear, the setting MultipleAttachments affected the wear option for attachments as follows: FALSE: When set to false, any time you wear an attachment, it would replace all attachments at that point. If you're wearing three things on your head, and you wear something on your head, all three will be replaced with the new attachment. Result: you're wearing a single attachment on your head. TRUE: When set to true, any time you wear an attachment, it would ignore whatever attachments were at that point and add the attachment onto that point. For example, if you're wearing three attachments on your head and you wear something new, you will end up with four things on your head. We've removed the debug setting as we've implemented this functionality directly in the user interface, making the debug setting completely unnecessary. With the latest code if you wear an attachment on your head, it will act as if MultipleAttachments was set to FALSE - it will replace everything else on your head. We have a new option in the UI which we've labeled add - which will act as if MultipleAttachments is TRUE - that is it will add the attachment to the attachment point, without removing the existing attachments. With both of these options being available through the UI, there is no need for the debug option anymore. If you don't want to use multi-attachments, all you need to do is make sure you use the wear option instead of the add option. If this is not working as I've described, then let us know as we have some bugs to fix :) Let me know if this clarifies things. -Nyx Marine Kelley wrote: Hello all, I am currently working at integrating the RLV code into the latest 2.1.2 viewer in viewer-development. Some users might have noticed that the MultipleAttachments debug setting was set to FALSE by default in order to stay compatible with 1.x, because 1.x users cannot see attachments worn on slots 1 and beyond, only slot 0 is rendered. So the feature is still rather useless because since most of the users are still using 1.x, multiple attachments are to be avoided. However having the option to choose whether to activate it or not was a good idea. I even added a checkbox in the navbar to set it to TRUE or FALSE in one click without having to open the debug settings (but that version is not released). And now what I'm seeing in the latest version worries me. The MultipleAttachments debug setting is gone ! The viewer behaves as if it were always TRUE. On the paper it makes sense, since 2.x is supposed to handle multiple attachments natively and the sims have been updated to 1.40 (and now 1.42) almost only for this reason. But... this is actually counter-productive because now someone who tries 2.1 will soon discover that most of their attachments are not showing to their friends. And that they require more steps to change an outfit than before, because they now have to explicitely remove attachments before wearing new ones. For a viewer that has a lot of difficulties being adopted by the user base, isn't this move a
Re: [opensource-dev] Removal of the MultipleAttachments debug settings ?
I'd like to chime in and say that this happens to me often as well. Attachments are worn twice on relog, approx. once a day. Since the attachments I'm wearing usually say things with llOwnerSay and I see them say their messages twice, I do know this is not only a viewer-side problem. I have never observed this with 1.23, only with 2.1. Soft is aware of this issue, and confirmed seeing the double-rezzing in the logs of my sim at the time I indicated. On 26 August 2010 22:30, Altair Sythos syt...@gmail.com wrote: On Thu, 26 Aug 2010 16:24:08 -0400 Nyx Linden n...@lindenlab.com wrote: Let me know if this clarifies things. yeah i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life Development) now, it work as you said, just noticed something weird and tryiong to reproduce: if i crash when relog all attachments are weared double time, like the dirty logoff don't detach items. I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff acvatar destructor take current outfit and store somewhere on asset, during login last saved current outfit is worn. maybe is better if saved current outfit replace what worn during login, so if crashed nothing boudle is worn... somebody who know better and deeper the code can hint me about? ___ 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] Removal of the MultipleAttachments debug settings ?
On 8/26/2010 15:54, Marine Kelley wrote: I understand, it makes sense, thanks for your reply Nyx. I did see the Add option on 2.1.0 along with MultipleAttachments there too so I assumed both were needed for some reason (this debug setting was used in a few places in the code). So, Marine, I'm guessing theres going to be a new UI element in the next RLV release - a checkbox that toggles the behaviour of the force-attach option between wear and add. Either that or you've got the pain of revising the API yet again and having @attach:folder=force do a wear and @attach:folder=forceadd do an add - along with a note that for backwards compatibility, any viewer that doesnt implement add must treat forceadd as equivalent to force, just to spread the pain down to the other folks that implement it :) ___ 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] Removal of the MultipleAttachments debug settings ?
There were some fixes in 1.42 that dealt with a related MultipleAttachments issue, and should have addressed the more general case. If anyone encounters this while logging in with an account where you've crashed or logged out today or later, would you please follow up with me in direct email? If you include the time and location at which you logged in, as well as what the item names were, and which attachment point they were on, it will help tremendously. Also, let me know if you flipped between 2.x and 1.x viewers in those sessions - anything out of the ordinary could be relevant. On Thu, Aug 26, 2010 at 2:37 PM, Marine Kelley marinekel...@gmail.comwrote: I'd like to chime in and say that this happens to me often as well. Attachments are worn twice on relog, approx. once a day. Since the attachments I'm wearing usually say things with llOwnerSay and I see them say their messages twice, I do know this is not only a viewer-side problem. I have never observed this with 1.23, only with 2.1. Soft is aware of this issue, and confirmed seeing the double-rezzing in the logs of my sim at the time I indicated. On 26 August 2010 22:30, Altair Sythos syt...@gmail.com wrote: On Thu, 26 Aug 2010 16:24:08 -0400 Nyx Linden n...@lindenlab.com wrote: Let me know if this clarifies things. yeah i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life Development) now, it work as you said, just noticed something weird and tryiong to reproduce: if i crash when relog all attachments are weared double time, like the dirty logoff don't detach items. I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff acvatar destructor take current outfit and store somewhere on asset, during login last saved current outfit is worn. maybe is better if saved current outfit replace what worn during login, so if crashed nothing boudle is worn... somebody who know better and deeper the code can hint me about? ___ 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 -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ 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] Removal of the MultipleAttachments debug settings ?
I think may be more usefull add all you asked in the jira opened about multiattachments double worn :) -- Sent by iPhone Il giorno 27/ago/2010, alle ore 00:50, Brian McGroarty s...@lindenlab.com ha scritto: There were some fixes in 1.42 that dealt with a related MultipleAttachments issue, and should have addressed the more general case. If anyone encounters this while logging in with an account where you've crashed or logged out today or later, would you please follow up with me in direct email? If you include the time and location at which you logged in, as well as what the item names were, and which attachment point they were on, it will help tremendously. Also, let me know if you flipped between 2.x and 1.x viewers in those sessions - anything out of the ordinary could be relevant. On Thu, Aug 26, 2010 at 2:37 PM, Marine Kelley marinekel...@gmail.comwrote: I'd like to chime in and say that this happens to me often as well. Attachments are worn twice on relog, approx. once a day. Since the attachments I'm wearing usually say things with llOwnerSay and I see them say their messages twice, I do know this is not only a viewer-side problem. I have never observed this with 1.23, only with 2.1. Soft is aware of this issue, and confirmed seeing the double-rezzing in the logs of my sim at the time I indicated. On 26 August 2010 22:30, Altair Sythos syt...@gmail.com wrote: On Thu, 26 Aug 2010 16:24:08 -0400 Nyx Linden n...@lindenlab.com wrote: Let me know if this clarifies things. yeah i'm on Second Life 2.1.2 (208569) Aug 26 2010 05:22:24 (Second Life Development) now, it work as you said, just noticed something weird and tryiong to reproduce: if i crash when relog all attachments are weared double time, like the dirty logoff don't detach items. I dunno how logoff/login work, i *SUPPOSE* debug warn during logoff acvatar destructor take current outfit and store somewhere on asset, during login last saved current outfit is worn. maybe is better if saved current outfit replace what worn during login, so if crashed nothing boudle is worn... somebody who know better and deeper the code can hint me about? ___ 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 -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ 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
