From sl at phoca.com Wed Aug 1 00:00:23 2007 From: sl at phoca.com (Second Life) Date: Wed Aug 1 00:00:38 2007 Subject: [sldev] Voice In-Reply-To: <46B027D1.4030608@ucsd.edu> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> Message-ID: Yeah it's this cut off of the viewport that makes having that window any larger a much bigger deal, and it's bothersome no matter where you put the window, top/bottom or side.. If the center of view were repositioned downwards it would actually be much less annoying :) In fact the latest version of Photoshop FINALLY got this right. I think ultimately I'd love to see a truly fully dockable/customizable window layout system ala Photoshop or even Visual Studio. Then a nice noob friendly default layout can be had and power users can tweak it to their version of perfection. But I'll just be happy if the current UI isn't made any more difficult to use in future updates for the time being ;) Farallon ----- Original Message ----- From: "Max Okumoto" To: "Second Life Developer Mailing List" Sent: Tuesday, July 31, 2007 11:27 PM Subject: Re: [sldev] Voice > Yea, it would be nice if we could adjust the "view point". I have a dual > monitor setup, and one of the things that > I wish I could do shift some of those windows to the side. And have my > avatar in the center of the other screen. > > Max > > > Callum Lerwick wrote: >> On Tue, 2007-07-31 at 21:12 -0700, Second Life wrote: >> >> >>> Image 1: My normal, every day, always open window set. History and IM >>> with enough space for 8-9 IMs before scrolling sets in and then I can >>> enlarge it quite a bit sideways without using up any more real usable >>> screen real-estate (eating up the mini map of course). >>> >>> http://www.seal-cove.com/chatterbox/Current.jpg >>> >> >> This is exactly what I do. This is a sign. >> >> There should be a "communications HUD" that docks like a toolbar along >> the top (or bottom, perhaps it could integrate with normal chat and >> those damn buttons along the bottom) with a layout something like this. >> This HUD should bump the center of focus of the 3D view down so that it >> doesn't feel like your view is getting cut off. Just like how the center >> of focus moves to the side when you edit your avatar appearance. >> >> Now make it a slide out bar, that can be easily hidden with one click. >> Maybe it could auto-hide. Maybe it could stretch bigger and smaller as >> the mouse approaches. OSX, eat your heart out. >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From ashea at ups.com Wed Aug 1 04:50:39 2007 From: ashea at ups.com (ashea@ups.com) Date: Wed Aug 1 04:51:07 2007 Subject: [sldev] Open Source Server Code References: <46AF990D.1080400@lindenlab.com> Message-ID: What will it mean when the server code is open sourced? Will this code allow me run my own small version of SL on my own private network, or does it mean I can only hook into the main grid? If you hook up to the main grid, how does this effect land ownership? Will running server code automatically give you a set amount of land? Is one instance of server code equal to one region of land? Will there be a connection fee to be "attached" to the main grid? Has anyone asked these questions before, I'm new to the list. Thanks AJS From nicholaz at blueflash.cc Wed Aug 1 05:13:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Aug 1 05:16:57 2007 Subject: [sldev] Voice In-Reply-To: References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> Message-ID: <46B078FC.9040800@blueflash.cc> Second Life wrote: > 8 hours a day for the last two months. And on the occasions when I go > back to the standard client it is a RELIEF. *nods* ... "relief" is exactly the word for what I felt when going back. Nick From roamingryozu at gmail.com Wed Aug 1 05:27:01 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Aug 1 05:27:03 2007 Subject: [sldev] Voice In-Reply-To: References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> Message-ID: <5eff6d3b0708010527y335683a9kca6717412bdabe41@mail.gmail.com> My solution is very similar, but with one major difference. I'd like to see the Friends list totally removed from the chatterbox and turned into it's own window again. Keep the groups tab on there as well, and what you have left is a "Contacts" window. Much like how many (Well, all, as far as I know) Instant Messenger programs have a "Contacts" or "Friends" list window separate from the actual IM windows. I don't really see a reason to dock the friends list in the "Communicate" window, as I also don't see much reason for there to be two buttons with labels that mean the same basic thing. "Chat" and "Communicate." Although that's a slightly stickier situation to handle without breaking usability. The solution isn't that hard: Make the friends list detachable and put a > button to show/hide it back on the button bar. > > As I said there are plenty of other smaller problems but if this ONE big > backwards step were put right, then I think I and most everyone else I've > talked too just might be able to "get used to it". > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/c11ad28b/attachment.htm From tateru.nino at gmail.com Wed Aug 1 05:35:32 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Aug 1 05:35:43 2007 Subject: [sldev] Voice In-Reply-To: <5eff6d3b0708010527y335683a9kca6717412bdabe41@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <5eff6d3b0708010527y335683a9kca6717412bdabe41@mail.gmail.com> Message-ID: <46B07E14.30402@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/c122a395/attachment.htm From nicholaz at blueflash.cc Wed Aug 1 04:51:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Aug 1 05:37:07 2007 Subject: [sldev] Voice In-Reply-To: <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> Message-ID: <46B073D7.10100@blueflash.cc> Soft Linden wrote: > I've seen a lot of comments about the new chatterbox panel, mostly > negative. The "make voice chatterbox more usable" is within the top#5 voted ... and that is for a First Look version which is ususally used by those most most willing to change (otherwise they would not try First Look) and which most people haven't even seen yet (which makes the high number of votes even more relevant in my view). If you're going to ignore this, I hope you guys are knowing what you're doing. > The bHear team will be pushing to have the final source released at > the same time as, or just before, the official launch. Btw, is there roadmap for this? Meaning: Have you guys planned another non-voice release or are all the "fixed internallys" on the jire going towards the voice release? Will the official voice (when it comes) render the older versions useless or will message liberation hold up through this? Any rough timeframe for official voice? (I know there are no specific dates, but I'd like to hear if it's more a matter of days, weeks or months)? Nick From nicholaz at blueflash.cc Wed Aug 1 04:53:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Aug 1 05:39:00 2007 Subject: [sldev] Open Source Server Code In-Reply-To: References: <46AF990D.1080400@lindenlab.com> Message-ID: <46B0742F.20803@blueflash.cc> There's been extensive discussion about that recently ... just dig through the sldev archives on the wiki and you'll easily find them (I guess it was about a month back). Nick ashea@ups.com wrote: > What will it mean when the server code is open sourced? Will this code > allow me run my own small version of SL on my own private network, or > does it mean I can only hook into the main grid? > > If you hook up to the main grid, how does this effect land ownership? > Will running server code automatically give you a set amount of land? Is > one instance of server code equal to one region of land? Will there be a > connection fee to be "attached" to the main grid? > > Has anyone asked these questions before, I'm new to the list. > > Thanks > AJS > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Wed Aug 1 06:04:35 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Aug 1 06:03:32 2007 Subject: [sldev] Open Source Server Code In-Reply-To: References: <46AF990D.1080400@lindenlab.com> Message-ID: <46B084E3.7020401@dzonux.net> From the different comment made, the first release of the code won't be fully open source. You can expect to see more or less terms on par of a commercial license. The asset data and avatar presence is too sensitive too just immediately open up all access. Even if LL releases the code today, there would still be the need to attach to the main servers. Those kinds of open protocols are not ready, which makes an open source server useless besides for testing/development only. The development of the protocols no doubt will require LL to establish a new support reference as other businesses host servers. Just my 2 L$ worth... ashea@ups.com wrote: > What will it mean when the server code is open sourced? Will this code > allow me run my own small version of SL on my own private network, or > does it mean I can only hook into the main grid? > > If you hook up to the main grid, how does this effect land ownership? > Will running server code automatically give you a set amount of land? Is > one instance of server code equal to one region of land? Will there be a > connection fee to be "attached" to the main grid? > > Has anyone asked these questions before, I'm new to the list. > > Thanks > AJS > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Power to Change the Void From ashea at ups.com Wed Aug 1 06:21:54 2007 From: ashea at ups.com (ashea@ups.com) Date: Wed Aug 1 06:22:26 2007 Subject: [sldev] HTTP Response & RSS Message-ID: Is there a way to take an HTTP response and save it as a notecard? Also I've seen rss viewers that display the feed on an object's surface, how is this done? Is the feed converted to an image outside of SL then dynamically uploaded and attached? If so, how do you dynamically upload an image. Thanks AJS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/4151a811/attachment.htm From webmaster at ligosworld.com Wed Aug 1 07:01:09 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Wed Aug 1 07:01:14 2007 Subject: [sldev] bandwidth usage Message-ID: <46B09225.5050804@ligosworld.com> Hi, can anyone explain me exactly how much bandwidth is used by second life and how it is used? which messages are sended how often? how much percent of the bandwitch is used for textures or sound? how much percent for the messages? what is the minimum of bandwitch sl will run width? regards Andi From alissa_sabre at yahoo.co.jp Wed Aug 1 02:46:36 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Aug 1 07:19:32 2007 Subject: [spam] Re: [sldev] Translations In-Reply-To: <46AF5006.7020705@dzonux.net> References: <46ACAC5F.7040903@danielnylander.se> <5Q8u7Px0JxYocrk8rkerQ8rt.alissa_sabre@yahoo.co.jp> <46AF5006.7020705@dzonux.net> Message-ID: <1dscdx4en4ds4s41GJ4dvc6o.alissa_sabre@yahoo.co.jp> > Alissa Sabre wrote: > > This mechanism will work fine as long as it is used corectly. > Sounds like there needs to be a new layer between dialog being exposed > by the source code and the appearant UI that is dependent on such > dialog. My sentence quoted above is in a context of discussing usefulness of gettext-like mechanisms. I don't think just adding gettext-like mechanisms into SL XUI requires an "additional layer." One way to implement it is to interpret all #PCDATA content as a gettext key, keeping the current schema, and slightly modify LLUI codes to call gettext just before setting the content text to a just created LLUICtrl. (We need to rewrite XUI file entirely, however.) Your discussion seems to be on layout adjustment issue. I agree that we will require an additional layer if we are to have a dynamic, constraint based layout engine. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From dereck at gmail.com Wed Aug 1 07:46:35 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Wed Aug 1 07:46:38 2007 Subject: [sldev] Duel monitors Message-ID: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> I agree on that entirely, SL looks so pretty across two monitors, but it is too frustrating to have gap down the center of my avatar to use it like that. I wonder if it is possible to center the viewpoint in the center of a chosen monitor? And for the UI people worrying a bout clutter... simply don't show the option unless multiple monitors were detected. I put in a Jira ticket. oh! think this can be done in LSL actually. you can control the camera with a script, possible just set a specific offset and bamo! your Avatar would be in the center of one of your monitors. ~Dereck Yea, it would be nice if we could adjust the "view point". I have a dual monitor setup, and one of the things that I wish I could do shift some of those windows to the side. And have my avatar in the center of the other screen. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/b5e3104e/attachment.htm From dzonatas at dzonux.net Wed Aug 1 08:41:04 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Aug 1 08:39:59 2007 Subject: [spam] Re: [sldev] Translations In-Reply-To: <1dscdx4en4ds4s41GJ4dvc6o.alissa_sabre@yahoo.co.jp> References: <46ACAC5F.7040903@danielnylander.se> <5Q8u7Px0JxYocrk8rkerQ8rt.alissa_sabre@yahoo.co.jp> <46AF5006.7020705@dzonux.net> <1dscdx4en4ds4s41GJ4dvc6o.alissa_sabre@yahoo.co.jp> Message-ID: <46B0A990.7020707@dzonux.net> Alissa Sabre wrote: >> Alissa Sabre wrote: >> >>> This mechanism will work fine as long as it is used corectly. >>> > > >> Sounds like there needs to be a new layer between dialog being exposed >> by the source code and the appearant UI that is dependent on such >> dialog. >> > > My sentence quoted above is in a context of discussing usefulness of > gettext-like mechanisms. I don't think just adding gettext-like > mechanisms into SL XUI requires an "additional layer." > I do not disagree with that point. > One way to implement it is to interpret all #PCDATA content as a > gettext key, keeping the current schema, and slightly modify LLUI > codes to call gettext just before setting the content text to a just > created LLUICtrl. (We need to rewrite XUI file entirely, however.) > If we stay with content of a absolute nature, that is workable. Is this step needed immediately? > Your discussion seems to be on layout adjustment issue. I agree that > we will require an additional layer if we are to have a dynamic, > constraint based layout engine. > > The dynamics enabled by such layer is more of a known side-effect than the intended goal. As you have seen on this thread, there is a need for much greater scalability in the UI than just internationalization. For example, we want a view that stretches across multiple monitors where you the human eye can still read the words. We also want to allow multiple UI skins, and each UI skin may have its own unique internationalization technique, and this is where gettext() breaks. There is also the preference to have no UI in the main view where all pop-ups or other windows show up totally separate in another monitor or even more ubiquitously on tablets and other mobile devices. Further, one viewer may mean one main viewer for multiple avatars on the same screen of real life people in the same room, yet each appearent dialog/UI for each avatar may have different international contexts. The goal is more into the extremes of virtual reality, but down to earth it can be easily described as an technological-edge on international conferences. What if we even enable speech to text, then text to international text, then international text to an avatar's locale, than that avatar's local text to (foreign) speech... what have we done? Now don't tell me virtual reality will automate translators out of their jobs. =p Cheers1 -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/9e32024a/attachment.htm From harrisos at us.ibm.com Wed Aug 1 08:59:20 2007 From: harrisos at us.ibm.com (Steven Harrison) Date: Wed Aug 1 08:59:26 2007 Subject: [sldev] HTTP Response & RSS In-Reply-To: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/0ba06801/graycol-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: pic18676.gif Type: image/gif Size: 1255 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/0ba06801/pic18676-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/0ba06801/ecblank-0001.gif From po at danielnylander.se Wed Aug 1 09:16:20 2007 From: po at danielnylander.se (Daniel Nylander) Date: Wed Aug 1 09:16:34 2007 Subject: [spam] Re: [sldev] Translations In-Reply-To: <1dscdx4en4ds4s41GJ4dvc6o.alissa_sabre@yahoo.co.jp> References: <46ACAC5F.7040903@danielnylander.se> <5Q8u7Px0JxYocrk8rkerQ8rt.alissa_sabre@yahoo.co.jp> <46AF5006.7020705@dzonux.net> <1dscdx4en4ds4s41GJ4dvc6o.alissa_sabre@yahoo.co.jp> Message-ID: <46B0B1D4.8040107@danielnylander.se> Alissa Sabre skrev: > One way to implement it is to interpret all #PCDATA content as a > gettext key, keeping the current schema, and slightly modify LLUI > codes to call gettext just before setting the content text to a just > created LLUICtrl. (We need to rewrite XUI file entirely, however.) > > Your discussion seems to be on layout adjustment issue. I agree that > we will require an additional layer if we are to have a dynamic, > constraint based layout engine. You can of course include some UI design features (such as button lengths) as translated strings. Then the translator can change the design to fit his translation. -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info@danielnylander.se yeager@ubuntu.com dnylande@gnome.org From nicholaz at blueflash.cc Wed Aug 1 06:31:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Aug 1 10:22:27 2007 Subject: [sldev] Voice In-Reply-To: <46B07E14.30402@gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <5eff6d3b0708010527y335683a9kca6717412bdabe41@mail.gmail.com> <46B07E14.30402@gmail.com> Message-ID: <46B08B2B.8090503@blueflash.cc> Tateru Nino wrote: > That and the size of the communicate window are my two big bugbears - You can tear off the "Near me" and it will act mostly like the old history (it has a few quirks too, but it's an improvment if you have to use the voice viewer and there are so many usability quirks in there that I won't even bother to list them). But yes, the use of screen real estate seems to be the biggest gripe out there (for me also). It sort of reduces the in-world stuff to an animated background wallpaper. I noticed this already when using the voice viewer, it is a sublte cause, but for me has a fundamental effect on the way I use SL. I assume it's less noticeable with actually using voice, because I guess using voice will draw the attention away from the screen anyway ... equally fundamental but probably less noticeably for those who do, because people who tend to use voice, seem to tend to use SL in a less immersive way anyway. I guess these are more those kind of people who write articles about SL saying it's a chatroom with 3D avatars and now it's going to be Skype with pictures. The longer I think about it and play with it, the more I'm getting the impression, that this stuff will have profound effects by affecting users in intuive and subconscious ways. It's obviously a business decision, maybe the next gen teleconferencing system will be more profitable than an immersive excape route and hideout from real life. But, as I said, I can only hope the Lindens know what they're doing (that and that the message liberation will hold up for long enough that it's worthwhile investing efforts in developing alternatives.) > Third place has to go to the FL voice viewer using an /order of > magnitude/ more RAM for the same settings (570MB vs 57MB for > Nicholaz18a). That's just crazy now. :) You need to be careful about that. Even on my machine Windows does some odd things reporting memory. My viewer just using 57MB is unrealistic, it's probably Windows reporting something weird. As long as the new one (I have not tested that) does not go much beyond my rule of thumb from the blog, they're probably more or less equal. Nick From roamingryozu at gmail.com Wed Aug 1 10:29:35 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Aug 1 10:29:40 2007 Subject: [sldev] Duel monitors In-Reply-To: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> References: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> Message-ID: <5eff6d3b0708011029j67dc18efyd0a545fe57c87adc@mail.gmail.com> Technically speaking, you could use LSL to adjust the camera offset to one side. In practice however, this leads to a distorted view as the perspective is still focused at the midpoint. Wasn't there at some point an option to adjust the field of view in the debug menu? On 8/1/07, Dereck Wonnacott wrote: > > I agree on that entirely, SL looks so pretty across two monitors, but it > is too frustrating to have gap down the center of my avatar to use it like > that. > > I wonder if it is possible to center the viewpoint in the center of a > chosen monitor? And for the UI people worrying a bout clutter... simply > don't show the option unless multiple monitors were detected. > > I put in a Jira ticket. oh! think this can be done in LSL actually. you > can control the camera with a script, possible just set a specific offset > and bamo! your Avatar would be in the center of one of your monitors. > > ~Dereck > > > Yea, it would be nice if we could adjust the "view point". I have a > dual monitor setup, and one of the things that > I wish I could do shift some of those windows to the side. And have my > avatar in the center of the other screen. > > Max > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/1878638c/attachment.htm From soft at lindenlab.com Wed Aug 1 11:43:12 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 11:43:13 2007 Subject: [sldev] Voice In-Reply-To: References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> Message-ID: <9e6e5c9e0708011143p3a8b5b31nac54951666aa6e99@mail.gmail.com> I can't access the URLs on this. Could you check permissions? On 7/31/07, Second Life wrote: > Soft, > > Thanks for replying to this thread. > > Believe me it is not merely resistance to change. There is a fatal flaw in > the design as it sits that should be corrected. > > There are many minor issues with the chatterbox but one stands out above all > the rest. I have been using the FL client for about 80% of my SLing, 8 hours > a day for the last two months. And on the occasions when I go back to the > standard client it is a RELIEF. > > I have taken several snapshots to try to illustrate the problem and it all > stems from having a large number of :friends and trying to deal with several > IMs at once where the chatter box is completely deficient in usability. > > Image 1: My normal, every day, always open window set. History and IM with > enough space for 8-9 IMs before scrolling sets in and then I can enlarge it > quite a bit sideways without using up any more real usable screen > real-estate (eating up the mini map of course). > > http://www.seal-cove.com/chatterbox/Current.jpg > > Image 2: Now, when I want to check on the friends list, it is a simple click > away, click on, browse the entire list of "on-line" friends without even > scrolling, click off when done. Extremely fast and efficient. And even when > I want to leave it open to check on things real-time It's still relatively > compact and out of the way, and I can see it and my IM windows at the same > time. This is unusual but happens sometimes, nice to have that option. > > http://www.seal-cove.com/chatterbox/Current-WithFriendsList.jpg > > Image 3: Chatterbox, trying to maintain the same setup as I normally use in > image 1. Note that it is immediately and uselessly larger than it needs to > be for IMs as compared to before. Why? because of the friends list that is > wedged in there. Now look at even trying to use the friends list, I can only > see 4.5 names at a time. I've never used the scroll wheel so much in SL as > trying to look up and down my friends list in this configuration :( > > http://www.seal-cove.com/chatterbox/Chatterbox-IMs.jpg > > Image 4: I tried this for a while, making the chatterbox more friends list > friendly, but then you can only manage 2-3 IM windows before having to > annoyingly scroll them, and the aspect ratio for the IMs is not best AND the > friends list names are pretty scrunched. > > http://www.seal-cove.com/chatterbox/Chatterbox-FriendsList.jpg > > Image 5: And here is the meat of it, IF you have a lot of friends and don;t > like constantly scrolling scrolling scrolling AND you want to manage 6-8-10 > IMs at once, here is what you have to have: > > http://www.seal-cove.com/chatterbox/Chatterbox-Both.jpg > > That is plainly ridiculous. Now go back and look at my image 1 and Image 2 > again, see what I mean by "relief"? And finally, these shots were taken on a > 1920x1200 screen at a UI size of 0.90. How are people on 1024x768 screens > going to take this? (Which BTW I use on the living room media computer while > watching TV sometimes) > > It should be fairly plain what the problem is: The friends list and the IM > window /demand/ opposite aspect ratios for best usage and having them > attached like that makes one or the other very hard to use. > > The solution isn't that hard: Make the friends list detachable and put a > button to show/hide it back on the button bar. > > As I said there are plenty of other smaller problems but if this ONE big > backwards step were put right, then I think I and most everyone else I've > talked too just might be able to "get used to it". > > Thank you for looking. > > Farallon Greyskin > > > > > > > > > > ----- Original Message ----- > From: "Soft Linden" > To: "Nicholaz Beresford" > Cc: "Second Life Developer Mailing List" > Sent: Tuesday, July 31, 2007 5:57 PM > Subject: Re: [sldev] Voice > > > > I've seen a lot of comments about the new chatterbox panel, mostly > > negative. For me (and I think many other Lindens), it's hard to tell > > how many of the comments are resistance to changing something so > > fundamental and familiar, and how much is real usability breakage. I > > know I get pretty attached to one way of doing things after being > > exposed to it for so long. > > > > The design isn't set in stone, although what you see now will be, > > roughly, what you see in the first release. Posting specific requests > > and shortcomings as JIRAs will help a lot in evolving this into > > something better-received, and many thanks to those of you who have > > posted comments. > > > > The bHear team will be pushing to have the final source released at > > the same time as, or just before, the official launch. If you've got > > things you'd like to change yourselves, you might visit Benjamin > > Linden's usability office hours to propose ideas in advance and to > > highlight existing chatterbox JIRAs you want to act on, based on your > > reactions to the First Look version. If we see patches that > > specifically note that you already ran an implemented idea by > > Benjamin, we should be able to bring them in pretty quickly. > > > > > > On 7/28/07, Nicholaz Beresford wrote: > >> > >> I just tried the voice first look for the first time > >> today and read the blog post about a mandatory FL on > >> Monday and integration in to the main viewer. > >> > >> Is there are roadmap for this (time-wise and in relation > >> to the non-voice viewer)? > >> > >> Also, I'd like to know how much set in stone the > >> communication center design is (in my personal opinion > >> that dialog is quite underwhelming and will most likely > >> cause a major uproar when it becomes mandatory for all). > >> > >> > >> Nick > >> -- > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dzonatas at dzonux.net Wed Aug 1 12:08:41 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Aug 1 12:07:37 2007 Subject: [sldev] Re: The future of "Text On a Prim" (Jeff Barr) In-Reply-To: <46AFB86C.1040104@lindenlab.com> References: <20070731212620.SLOV14792.fep02.xtra.co.nz@jamesdad0c5ae5> <46AFB143.20508@greenfate.com> <46AFB86C.1040104@lindenlab.com> Message-ID: <46B0DA39.7030102@dzonux.net> The idea of this has been known and used in different ways. Good and bad. We'll have to invent a protocol to ensure that the content being viewed by one is the same content concurrently viewed by others and a way for those users to verify it. Cheers Kelly Linden wrote: > Using the client UI you can only set 1 stream per parcel. Using the lsl > function call you can set 1 stream per agent per parcel. > > I think the following works in a touch event (give or take): > > llParcelMediaCommandList(PARCEL_MEDIA_COMMAND_AGENT, llDetectedKey(0), > PARCEL_MEDIA_COMMAND_URL, my_url, PARCEL_MEDIA_COMMAND_PLAY]); > > And yes, if you use a different my_url you can play a different stream > for each agent that touches it. > > - Kelly > > Green Fate wrote: > >> I don't think you can. >> >> James Jones wrote: >> >>> How do you display a different media stream per agent? >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters > > > -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/b86e7ade/attachment.htm From soft at lindenlab.com Wed Aug 1 12:09:54 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 12:09:56 2007 Subject: [sldev] Voice In-Reply-To: <46B073D7.10100@blueflash.cc> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <46B073D7.10100@blueflash.cc> Message-ID: <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> On 8/1/07, Nicholaz Beresford wrote: > > Soft Linden wrote: > > I've seen a lot of comments about the new chatterbox panel, mostly > > negative. > > The "make voice chatterbox more usable" is within the top#5 voted ... > and that is for a First Look version which is ususally used by > those most most willing to change (otherwise they would not try > First Look) and which most people haven't even seen yet (which > makes the high number of votes even more relevant in my view). > > If you're going to ignore this, I hope you guys are knowing what > you're doing. We're not ignoring it, but we're also wary of holding back release and keeping this in a branch. There's a lot of engineering time being wasted because we're fixing bugs in the main branch that don't even apply to the code in bHear, and a lot of danger is introduced as merges between bHear and the other branches are getting increasingly involved. Take a look at the block of reverted bugs that included Gigs' animation fix for an example of what can go wrong here. Setting that right pretty much ate a full day of the release team's time. Different Lindens are going to have different takes - I've got a few things I'd prefer to see fixed before release too, such as mouseless usability for independent chat and IM windows. But I couldn't point to any one problem and say it's a dealbreaker, and more important than the cost and risk that the divergent branch is introducing. I also don't have the bandwidth to drop tasks and work on UI stuff, which is why I wanted to point to how sldev could take things up with Benjamin ahead of offering patches in order to speed patch acceptance. I'm really hoping we can get a quick follow-up revision. > Will the official voice (when it comes) render the older > versions useless or will message liberation hold up through > this? Message liberation should hold up here. I think the currently deployed server is capable of acting as the release version of the voice server. > Any rough timeframe for official voice? (I know there are no > specific dates, but I'd like to hear if it's more a matter > of days, weeks or months)? I don't know if it's set in stone, but the team's pushing to make it part of the very next release. From sl at phoca.com Wed Aug 1 12:17:42 2007 From: sl at phoca.com (Second Life) Date: Wed Aug 1 12:17:59 2007 Subject: [sldev] Voice In-Reply-To: <9e6e5c9e0708011143p3a8b5b31nac54951666aa6e99@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <9e6e5c9e0708011143p3a8b5b31nac54951666aa6e99@mail.gmail.com> Message-ID: <5FEA552144774562A4E9AC50045E25EC@SanMiguel> Ack, sorry :/ Does this work? I made a page with the letter text and links in it. http://www.seal-cove.com/chatterbox/ Farallon ----- Original Message ----- From: "Soft Linden" To: "Second Life" Cc: "Nicholaz Beresford" ; "Second Life Developer Mailing List" Sent: Wednesday, August 01, 2007 11:43 AM Subject: Re: [sldev] Voice >I can't access the URLs on this. Could you check permissions? > > > On 7/31/07, Second Life wrote: >> Soft, >> >> Thanks for replying to this thread. >> >> Believe me it is not merely resistance to change. There is a fatal flaw >> in >> the design as it sits that should be corrected. >> >> There are many minor issues with the chatterbox but one stands out above >> all >> the rest. I have been using the FL client for about 80% of my SLing, 8 >> hours >> a day for the last two months. And on the occasions when I go back to the >> standard client it is a RELIEF. >> >> I have taken several snapshots to try to illustrate the problem and it >> all >> stems from having a large number of :friends and trying to deal with >> several >> IMs at once where the chatter box is completely deficient in usability. >> >> Image 1: My normal, every day, always open window set. History and IM >> with >> enough space for 8-9 IMs before scrolling sets in and then I can enlarge >> it >> quite a bit sideways without using up any more real usable screen >> real-estate (eating up the mini map of course). >> >> http://www.seal-cove.com/chatterbox/Current.jpg >> >> Image 2: Now, when I want to check on the friends list, it is a simple >> click >> away, click on, browse the entire list of "on-line" friends without even >> scrolling, click off when done. Extremely fast and efficient. And even >> when >> I want to leave it open to check on things real-time It's still >> relatively >> compact and out of the way, and I can see it and my IM windows at the >> same >> time. This is unusual but happens sometimes, nice to have that option. >> >> http://www.seal-cove.com/chatterbox/Current-WithFriendsList.jpg >> >> Image 3: Chatterbox, trying to maintain the same setup as I normally use >> in >> image 1. Note that it is immediately and uselessly larger than it needs >> to >> be for IMs as compared to before. Why? because of the friends list that >> is >> wedged in there. Now look at even trying to use the friends list, I can >> only >> see 4.5 names at a time. I've never used the scroll wheel so much in SL >> as >> trying to look up and down my friends list in this configuration :( >> >> http://www.seal-cove.com/chatterbox/Chatterbox-IMs.jpg >> >> Image 4: I tried this for a while, making the chatterbox more friends >> list >> friendly, but then you can only manage 2-3 IM windows before having to >> annoyingly scroll them, and the aspect ratio for the IMs is not best AND >> the >> friends list names are pretty scrunched. >> >> http://www.seal-cove.com/chatterbox/Chatterbox-FriendsList.jpg >> >> Image 5: And here is the meat of it, IF you have a lot of friends and >> don;t >> like constantly scrolling scrolling scrolling AND you want to manage >> 6-8-10 >> IMs at once, here is what you have to have: >> >> http://www.seal-cove.com/chatterbox/Chatterbox-Both.jpg >> >> That is plainly ridiculous. Now go back and look at my image 1 and Image >> 2 >> again, see what I mean by "relief"? And finally, these shots were taken >> on a >> 1920x1200 screen at a UI size of 0.90. How are people on 1024x768 screens >> going to take this? (Which BTW I use on the living room media computer >> while >> watching TV sometimes) >> >> It should be fairly plain what the problem is: The friends list and the >> IM >> window /demand/ opposite aspect ratios for best usage and having them >> attached like that makes one or the other very hard to use. >> >> The solution isn't that hard: Make the friends list detachable and put a >> button to show/hide it back on the button bar. >> >> As I said there are plenty of other smaller problems but if this ONE big >> backwards step were put right, then I think I and most everyone else I've >> talked too just might be able to "get used to it". >> >> Thank you for looking. >> >> Farallon Greyskin >> >> >> >> >> >> >> >> >> >> ----- Original Message ----- >> From: "Soft Linden" >> To: "Nicholaz Beresford" >> Cc: "Second Life Developer Mailing List" >> Sent: Tuesday, July 31, 2007 5:57 PM >> Subject: Re: [sldev] Voice >> >> >> > I've seen a lot of comments about the new chatterbox panel, mostly >> > negative. For me (and I think many other Lindens), it's hard to tell >> > how many of the comments are resistance to changing something so >> > fundamental and familiar, and how much is real usability breakage. I >> > know I get pretty attached to one way of doing things after being >> > exposed to it for so long. >> > >> > The design isn't set in stone, although what you see now will be, >> > roughly, what you see in the first release. Posting specific requests >> > and shortcomings as JIRAs will help a lot in evolving this into >> > something better-received, and many thanks to those of you who have >> > posted comments. >> > >> > The bHear team will be pushing to have the final source released at >> > the same time as, or just before, the official launch. If you've got >> > things you'd like to change yourselves, you might visit Benjamin >> > Linden's usability office hours to propose ideas in advance and to >> > highlight existing chatterbox JIRAs you want to act on, based on your >> > reactions to the First Look version. If we see patches that >> > specifically note that you already ran an implemented idea by >> > Benjamin, we should be able to bring them in pretty quickly. >> > >> > >> > On 7/28/07, Nicholaz Beresford wrote: >> >> >> >> I just tried the voice first look for the first time >> >> today and read the blog post about a mandatory FL on >> >> Monday and integration in to the main viewer. >> >> >> >> Is there are roadmap for this (time-wise and in relation >> >> to the non-voice viewer)? >> >> >> >> Also, I'd like to know how much set in stone the >> >> communication center design is (in my personal opinion >> >> that dialog is quite underwhelming and will most likely >> >> cause a major uproar when it becomes mandatory for all). >> >> >> >> >> >> Nick >> >> -- >> >> Second Life from the inside out: >> >> http://nicholaz-beresford.blogspot.com/ >> >> _______________________________________________ >> >> Click here to unsubscribe or manage your list subscription: >> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> From dzonatas at dzonux.net Wed Aug 1 12:25:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Aug 1 12:24:21 2007 Subject: [sldev] Voice In-Reply-To: <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <46B073D7.10100@blueflash.cc> <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> Message-ID: <46B0DE27.2080804@dzonux.net> Soft Linden wrote: > Message liberation should hold up here. > Good on the server end. How about the open source side? Are the libraries distributed with the Voice viewer STL compliant? Has anybody in LL tested a Voice viewer build with VS2005 and on Vista? -- Power to Change the Void From soft at lindenlab.com Wed Aug 1 12:28:28 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 12:28:31 2007 Subject: [sldev] Voice In-Reply-To: <46B027D1.4030608@ucsd.edu> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> Message-ID: <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> This is a *really* great idea. If you JIRA it, I promise I'd vote on it too. Even with the current client, which is still what I use any time I'm not in a voice meeting, I end up putting my chat at the bottom and IMs at the top to try and keep the view centered. If I could shift the view center upward and leftward, then I'd keep both things on the bottom, and I could even keep the mini map and inventory up on the right. On 7/31/07, Max Okumoto wrote: > Yea, it would be nice if we could adjust the "view point". I have a > dual monitor setup, and one of the things that > I wish I could do shift some of those windows to the side. And have my > avatar in the center of the other screen. > > Max > > > Callum Lerwick wrote: > > On Tue, 2007-07-31 at 21:12 -0700, Second Life wrote: > > > > > >> Image 1: My normal, every day, always open window set. History and IM with > >> enough space for 8-9 IMs before scrolling sets in and then I can enlarge it > >> quite a bit sideways without using up any more real usable screen > >> real-estate (eating up the mini map of course). > >> > >> http://www.seal-cove.com/chatterbox/Current.jpg > >> > > > > This is exactly what I do. This is a sign. > > > > There should be a "communications HUD" that docks like a toolbar along > > the top (or bottom, perhaps it could integrate with normal chat and > > those damn buttons along the bottom) with a layout something like this. > > This HUD should bump the center of focus of the 3D view down so that it > > doesn't feel like your view is getting cut off. Just like how the center > > of focus moves to the side when you edit your avatar appearance. > > > > Now make it a slide out bar, that can be easily hidden with one click. > > Maybe it could auto-hide. Maybe it could stretch bigger and smaller as > > the mouse approaches. OSX, eat your heart out. > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Wed Aug 1 12:33:25 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 12:33:27 2007 Subject: [sldev] Voice In-Reply-To: <5FEA552144774562A4E9AC50045E25EC@SanMiguel> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <9e6e5c9e0708011143p3a8b5b31nac54951666aa6e99@mail.gmail.com> <5FEA552144774562A4E9AC50045E25EC@SanMiguel> Message-ID: <9e6e5c9e0708011233j71b1fe4pe5cf5bff759acb70@mail.gmail.com> Thanks, this does illustrate some of the problems pretty vividly. Rob's forwarded this on internally - I'll make sure people get the self-referring link as well. On 8/1/07, Second Life wrote: > Ack, sorry :/ > > Does this work? I made a page with the letter text and links in it. > > http://www.seal-cove.com/chatterbox/ > > Farallon > > ----- Original Message ----- > From: "Soft Linden" > To: "Second Life" > Cc: "Nicholaz Beresford" ; "Second Life Developer > Mailing List" > Sent: Wednesday, August 01, 2007 11:43 AM > Subject: Re: [sldev] Voice > > > >I can't access the URLs on this. Could you check permissions? > > > > > > On 7/31/07, Second Life wrote: > >> Soft, > >> > >> Thanks for replying to this thread. > >> > >> Believe me it is not merely resistance to change. There is a fatal flaw > >> in > >> the design as it sits that should be corrected. > >> > >> There are many minor issues with the chatterbox but one stands out above > >> all > >> the rest. I have been using the FL client for about 80% of my SLing, 8 > >> hours > >> a day for the last two months. And on the occasions when I go back to the > >> standard client it is a RELIEF. > >> > >> I have taken several snapshots to try to illustrate the problem and it > >> all > >> stems from having a large number of :friends and trying to deal with > >> several > >> IMs at once where the chatter box is completely deficient in usability. > >> > >> Image 1: My normal, every day, always open window set. History and IM > >> with > >> enough space for 8-9 IMs before scrolling sets in and then I can enlarge > >> it > >> quite a bit sideways without using up any more real usable screen > >> real-estate (eating up the mini map of course). > >> > >> http://www.seal-cove.com/chatterbox/Current.jpg > >> > >> Image 2: Now, when I want to check on the friends list, it is a simple > >> click > >> away, click on, browse the entire list of "on-line" friends without even > >> scrolling, click off when done. Extremely fast and efficient. And even > >> when > >> I want to leave it open to check on things real-time It's still > >> relatively > >> compact and out of the way, and I can see it and my IM windows at the > >> same > >> time. This is unusual but happens sometimes, nice to have that option. > >> > >> http://www.seal-cove.com/chatterbox/Current-WithFriendsList.jpg > >> > >> Image 3: Chatterbox, trying to maintain the same setup as I normally use > >> in > >> image 1. Note that it is immediately and uselessly larger than it needs > >> to > >> be for IMs as compared to before. Why? because of the friends list that > >> is > >> wedged in there. Now look at even trying to use the friends list, I can > >> only > >> see 4.5 names at a time. I've never used the scroll wheel so much in SL > >> as > >> trying to look up and down my friends list in this configuration :( > >> > >> http://www.seal-cove.com/chatterbox/Chatterbox-IMs.jpg > >> > >> Image 4: I tried this for a while, making the chatterbox more friends > >> list > >> friendly, but then you can only manage 2-3 IM windows before having to > >> annoyingly scroll them, and the aspect ratio for the IMs is not best AND > >> the > >> friends list names are pretty scrunched. > >> > >> http://www.seal-cove.com/chatterbox/Chatterbox-FriendsList.jpg > >> > >> Image 5: And here is the meat of it, IF you have a lot of friends and > >> don;t > >> like constantly scrolling scrolling scrolling AND you want to manage > >> 6-8-10 > >> IMs at once, here is what you have to have: > >> > >> http://www.seal-cove.com/chatterbox/Chatterbox-Both.jpg > >> > >> That is plainly ridiculous. Now go back and look at my image 1 and Image > >> 2 > >> again, see what I mean by "relief"? And finally, these shots were taken > >> on a > >> 1920x1200 screen at a UI size of 0.90. How are people on 1024x768 screens > >> going to take this? (Which BTW I use on the living room media computer > >> while > >> watching TV sometimes) > >> > >> It should be fairly plain what the problem is: The friends list and the > >> IM > >> window /demand/ opposite aspect ratios for best usage and having them > >> attached like that makes one or the other very hard to use. > >> > >> The solution isn't that hard: Make the friends list detachable and put a > >> button to show/hide it back on the button bar. > >> > >> As I said there are plenty of other smaller problems but if this ONE big > >> backwards step were put right, then I think I and most everyone else I've > >> talked too just might be able to "get used to it". > >> > >> Thank you for looking. > >> > >> Farallon Greyskin > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> From: "Soft Linden" > >> To: "Nicholaz Beresford" > >> Cc: "Second Life Developer Mailing List" > >> Sent: Tuesday, July 31, 2007 5:57 PM > >> Subject: Re: [sldev] Voice > >> > >> > >> > I've seen a lot of comments about the new chatterbox panel, mostly > >> > negative. For me (and I think many other Lindens), it's hard to tell > >> > how many of the comments are resistance to changing something so > >> > fundamental and familiar, and how much is real usability breakage. I > >> > know I get pretty attached to one way of doing things after being > >> > exposed to it for so long. > >> > > >> > The design isn't set in stone, although what you see now will be, > >> > roughly, what you see in the first release. Posting specific requests > >> > and shortcomings as JIRAs will help a lot in evolving this into > >> > something better-received, and many thanks to those of you who have > >> > posted comments. > >> > > >> > The bHear team will be pushing to have the final source released at > >> > the same time as, or just before, the official launch. If you've got > >> > things you'd like to change yourselves, you might visit Benjamin > >> > Linden's usability office hours to propose ideas in advance and to > >> > highlight existing chatterbox JIRAs you want to act on, based on your > >> > reactions to the First Look version. If we see patches that > >> > specifically note that you already ran an implemented idea by > >> > Benjamin, we should be able to bring them in pretty quickly. > >> > > >> > > >> > On 7/28/07, Nicholaz Beresford wrote: > >> >> > >> >> I just tried the voice first look for the first time > >> >> today and read the blog post about a mandatory FL on > >> >> Monday and integration in to the main viewer. > >> >> > >> >> Is there are roadmap for this (time-wise and in relation > >> >> to the non-voice viewer)? > >> >> > >> >> Also, I'd like to know how much set in stone the > >> >> communication center design is (in my personal opinion > >> >> that dialog is quite underwhelming and will most likely > >> >> cause a major uproar when it becomes mandatory for all). > >> >> > >> >> > >> >> Nick > >> >> -- > >> >> Second Life from the inside out: > >> >> http://nicholaz-beresford.blogspot.com/ > >> >> _______________________________________________ > >> >> Click here to unsubscribe or manage your list subscription: > >> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> >> > >> > _______________________________________________ > >> > Click here to unsubscribe or manage your list subscription: > >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > >> > > From seg at haxxed.com Wed Aug 1 12:43:41 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Aug 1 12:44:05 2007 Subject: [sldev] Duel monitors In-Reply-To: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> References: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> Message-ID: <1185997421.18603.58.camel@localhost> On Wed, 2007-08-01 at 10:46 -0400, Dereck Wonnacott wrote: > I wonder if it is possible to center the viewpoint in the center of a > chosen monitor? And for the UI people worrying a bout clutter... > simply don't show the option unless multiple monitors were detected. The avatar appearance editor moves the center of focus, so there's code in there to do it somewhere. The tricky part is getting the information about the monitor arrangement and relating it to SL's window, this would require platform specific code. Since all window handling is apparently platform specific anyway, I guess that isn't much of a stretch. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/80879c06/attachment.pgp From soft at lindenlab.com Wed Aug 1 12:51:06 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 12:51:08 2007 Subject: [sldev] Open Source Meeting Agenda - Thursday 2pm Message-ID: <9e6e5c9e0708011251m62479f5agf07142b8414e5fff@mail.gmail.com> The open source meeting is tomorrow, Thursday at 2pm. If there's anything you'd like to see covered, please add it to the agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Thanks! From frank.van.rooij at nl.ibm.com Wed Aug 1 13:17:12 2007 From: frank.van.rooij at nl.ibm.com (Frank van Rooij) Date: Wed Aug 1 13:17:28 2007 Subject: [sldev] Frank van Rooij is on Holiday! Message-ID: I will be out of the office starting 01-08-2007 and will not return until 28-08-2007. For urgent topics please contact my back-up Hans Jacobs ( (hans.jacobs@nl.ibm.com) or my secretary Jane Patty (jane.patty@nl.ibm.com) From soft at lindenlab.com Wed Aug 1 14:54:07 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Aug 1 14:54:09 2007 Subject: [sldev] Voice In-Reply-To: <46B0DE27.2080804@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <46B073D7.10100@blueflash.cc> <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> <46B0DE27.2080804@dzonux.net> Message-ID: <9e6e5c9e0708011454s4ff97d8el9d26407999ca860@mail.gmail.com> Asking internally. I saw ya put that on the open source meeting agenda - hopefully I'll have an answer by then! On 8/1/07, Dzonatas wrote: > Soft Linden wrote: > > Message liberation should hold up here. > > > > Good on the server end. How about the open source side? Are the > libraries distributed with the Voice viewer STL compliant? Has anybody > in LL tested a Voice viewer build with VS2005 and on Vista? > > > > -- > Power to Change the Void > From zefram at kryptonians.net Wed Aug 1 15:10:56 2007 From: zefram at kryptonians.net (Zefram Cochrane) Date: Wed Aug 1 15:11:04 2007 Subject: [sldev] Duel monitors In-Reply-To: <5eff6d3b0708011029j67dc18efyd0a545fe57c87adc@mail.gmail.com> References: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> <5eff6d3b0708011029j67dc18efyd0a545fe57c87adc@mail.gmail.com> Message-ID: On Wed, 1 Aug 2007, Andre Roche wrote: > Technically speaking, you could use LSL to adjust the camera offset to one > side. In practice however, this leads to a distorted view as the > perspective is still focused at the midpoint. > > Wasn't there at some point an option to adjust the field of view in the > debug menu? Even offseting your character enough to keep him out of the middle seam would probably be enough, and the parallax distortion would be minimal. Now I'm anxious to try this when I get home! From deklax at gmail.com Wed Aug 1 15:23:02 2007 From: deklax at gmail.com (Deklax Fairplay) Date: Wed Aug 1 15:23:05 2007 Subject: [sldev] Second Life & Terrorism Message-ID: <63fbc0a0708011523q40a1aedfl9239e5821554f169@mail.gmail.com> All - There have been several disturbing articles indicating second life is related to terroristic activity. Writers have compared an in-game social group to al qaeda and made unsubstantiated claims about members of the second life network. Closer to home, the second life herald appears to use the second life logo and name. On it, Matthias Zander wrote an article suggesting Ulrika Zugzwang was a "cyber-terrorist". Looks like the corn fieldmight need a new name - may I suggest Second Gitmo? There is a certain ring to it. Sounds like something Mitt Romney would be interested in. Strange Days. Deklax Fairplay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/1e206da3/attachment.htm From roamingryozu at gmail.com Wed Aug 1 15:27:03 2007 From: roamingryozu at gmail.com (Andre Roche) Date: Wed Aug 1 15:27:05 2007 Subject: [sldev] Duel monitors In-Reply-To: References: <2d8148cd0708010746s5d966afdoae1e2d0d58ea0b1f@mail.gmail.com> <5eff6d3b0708011029j67dc18efyd0a545fe57c87adc@mail.gmail.com> Message-ID: <5eff6d3b0708011527k51d70481y7087d5c142f9e586@mail.gmail.com> The avatar appearance editor moves the center of focus, so there's code in there to do it somewhere. The tricky part is getting the information about the monitor arrangement and relating it to SL's window, this would require platform specific code. Since all window handling is apparently platform specific anyway, I guess that isn't much of a stretch. I would imagine trying to automatically adjust the view would be much more work than would really be worth it. Better to simply give them something to adjust it manually, an x/y offset in the preferences at minimum, or a UI dot of some kind that you could drag to to set center. Of course for me, I just plan to go SLI and get a 3rd monitor ;) On 8/1/07, Zefram Cochrane wrote: > > On Wed, 1 Aug 2007, Andre Roche wrote: > > > Technically speaking, you could use LSL to adjust the camera offset to > one > > side. In practice however, this leads to a distorted view as the > > perspective is still focused at the midpoint. > > > > Wasn't there at some point an option to adjust the field of view in the > > debug menu? > > Even offseting your character enough to keep him out of the middle seam > would probably be enough, and the parallax distortion would be minimal. > > Now I'm anxious to try this when I get home! > > Just noticed the e-mail, is that you K? I tried tried it myself with just panning to the side. To me, the distortion was just too much, but everyone has their own tolerance levels. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/5fd69dcf/attachment.htm From seg at haxxed.com Wed Aug 1 15:39:12 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Aug 1 15:39:28 2007 Subject: [sldev] Second Life & Terrorism In-Reply-To: <63fbc0a0708011523q40a1aedfl9239e5821554f169@mail.gmail.com> References: <63fbc0a0708011523q40a1aedfl9239e5821554f169@mail.gmail.com> Message-ID: <1186007952.18603.109.camel@localhost> On Wed, 2007-08-01 at 17:23 -0500, Deklax Fairplay wrote: > All - > > There have been several disturbing articles indicating second life > is related to terroristic activity. Writers have compared an in-game > social group to al qaeda and made unsubstantiated claims about members > of the second life network. Closer to home, the second life herald > appears to use the second life logo and name. On it, Matthias Zander > wrote an article suggesting Ulrika Zugzwang was a "cyber-terrorist". > Looks like the corn field might need a new name - may I suggest Second > Gitmo? There is a certain ring to it. Sounds like something Mitt > Romney would be interested in. I've heard that communists, the CIA, the KKK, the aliens, the illuminati and even jews use Second Life too. And beware of Anonymous: http://www.youtube.com/watch?v=O6q1MMEUQTM This is a development list, PATCH or GTFO. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/db95f19b/attachment.pgp From gigstaggart at gmail.com Wed Aug 1 15:40:36 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Aug 1 15:40:24 2007 Subject: [sldev] Second Life & Terrorism In-Reply-To: <63fbc0a0708011523q40a1aedfl9239e5821554f169@mail.gmail.com> References: <63fbc0a0708011523q40a1aedfl9239e5821554f169@mail.gmail.com> Message-ID: <46B10BE4.1010206@gmail.com> I think you must have picked the wrong email on mistake. This list is about the development of the open source client. -Jason From nicholaz at blueflash.cc Wed Aug 1 15:44:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Aug 1 15:44:53 2007 Subject: [sldev] Voice In-Reply-To: <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <46B073D7.10100@blueflash.cc> <9e6e5c9e0708011209o73f574f1y9a78c41dd19e8058@mail.gmail.com> Message-ID: <46B10CDA.40105@blueflash.cc> Soft Linden wrote: > Message liberation should hold up here. I think the currently deployed > server is capable of acting as the release version of the voice > server. I'll keep my fingers crossed ... > I don't know if it's set in stone, but the team's pushing to make it > part of the very next release. Thanks for the info Nick From okumoto at ucsd.edu Wed Aug 1 15:54:58 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Wed Aug 1 15:55:02 2007 Subject: [sldev] Voice In-Reply-To: <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> Message-ID: <46B10F42.4000904@ucsd.edu> It's already in jira, *VWR-1960 . I should vote for it too. :-) Max * Soft Linden wrote: > This is a *really* great idea. If you JIRA it, I promise I'd vote on it too. > > Even with the current client, which is still what I use any time I'm > not in a voice meeting, I end up putting my chat at the bottom and IMs > at the top to try and keep the view centered. If I could shift the > view center upward and leftward, then I'd keep both things on the > bottom, and I could even keep the mini map and inventory up on the > right. > > On 7/31/07, Max Okumoto wrote: > >> Yea, it would be nice if we could adjust the "view point". I have a >> dual monitor setup, and one of the things that >> I wish I could do shift some of those windows to the side. And have my >> avatar in the center of the other screen. >> >> Max >> >> >> Callum Lerwick wrote: >> >>> On Tue, 2007-07-31 at 21:12 -0700, Second Life wrote: >>> >>> >>> >>>> Image 1: My normal, every day, always open window set. History and IM with >>>> enough space for 8-9 IMs before scrolling sets in and then I can enlarge it >>>> quite a bit sideways without using up any more real usable screen >>>> real-estate (eating up the mini map of course). >>>> >>>> http://www.seal-cove.com/chatterbox/Current.jpg >>>> >>>> >>> This is exactly what I do. This is a sign. >>> >>> There should be a "communications HUD" that docks like a toolbar along >>> the top (or bottom, perhaps it could integrate with normal chat and >>> those damn buttons along the bottom) with a layout something like this. >>> This HUD should bump the center of focus of the 3D view down so that it >>> doesn't feel like your view is getting cut off. Just like how the center >>> of focus moves to the side when you edit your avatar appearance. >>> >>> Now make it a slide out bar, that can be easily hidden with one click. >>> Maybe it could auto-hide. Maybe it could stretch bigger and smaller as >>> the mouse approaches. OSX, eat your heart out. >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/873432c9/attachment.htm From robla at lindenlab.com Wed Aug 1 16:47:39 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Aug 1 16:48:28 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <20070723101014.GA7339@bruno.sbruno> References: <20070723101014.GA7339@bruno.sbruno> Message-ID: <46B11B9B.9010901@lindenlab.com> Dale, Sorry for not weighing in on this sooner. Could you link to the /exact/ license you're referrring to when you talk about the "3-clause BSD license"? Preferably, a link to the exact code as distributed. Thanks Rob On 7/23/07 3:10 AM, Dale Glass wrote: > Hi! > > My avatar scanner (see http://sl.daleglass.net) calculates ages of > residents based on the birth date. On Linux I use strptime for this, but > Windows lacks the function, so currently this functionality isn't > available there. > > I'd like to be able to merge this into the official source some day, so > I'd like to know if LL would accept a 3-clause BSD licensed > implementation of strptime. > > Of course, if somebody knows of a better alternative, that works for me > as well. > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070801/dfb1d26f/signature.pgp From adam at gwala.net Wed Aug 1 17:47:57 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Aug 1 17:48:15 2007 Subject: [sldev] Can I include source licensed under the 3-clause BSD? In-Reply-To: <46B11B9B.9010901@lindenlab.com> References: <20070723101014.GA7339@bruno.sbruno> <46B11B9B.9010901@lindenlab.com> Message-ID: <46B129BD.7010002@gwala.net> Hi Rob, This is a copy of the 3-clause BSD license we use for the openmetaverse.org projects. 3-clause means the standard BSD license, less the "advertising" clause, it's fairly common (probably the second most common open source license apart from the GPL). When you see "BSD-licensed" 9/10 times it's reffering to the 3-clause version. > /* > * Copyright (c) Contributors, http://www.openmetaverse.org/ > * See CONTRIBUTORS.TXT for a full list of copyright holders. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions are met: > * * Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * * Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * * Neither the name of the OpenSim Project nor the > * names of its contributors may be used to endorse or promote products > * derived from this software without specific prior written permission. > * > * THIS SOFTWARE IS PROVIDED BY THE DEVELOPERS ``AS IS AND ANY > * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED > * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE > * DISCLAIMED. IN NO EVENT SHALL THE CONTRIBUTORS BE LIABLE FOR ANY > * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; > * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND > * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS > * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > * > */ Regards, Adam Rob Lanphier wrote: > Dale, > > Sorry for not weighing in on this sooner. Could you link to the /exact/ > license you're referrring to when you talk about the "3-clause BSD > license"? Preferably, a link to the exact code as distributed. > > Thanks > Rob > > On 7/23/07 3:10 AM, Dale Glass wrote: > >>Hi! >> >>My avatar scanner (see http://sl.daleglass.net) calculates ages of >>residents based on the birth date. On Linux I use strptime for this, but >>Windows lacks the function, so currently this functionality isn't >>available there. >> >>I'd like to be able to merge this into the official source some day, so >>I'd like to know if LL would accept a 3-clause BSD licensed >>implementation of strptime. >> >>Of course, if somebody knows of a better alternative, that works for me >>as well. >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Click here to unsubscribe or manage your list subscription: >>https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Wed Aug 1 18:31:46 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Aug 1 18:31:48 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B10F42.4000904@ucsd.edu> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> Message-ID: <46B13402.4030804@cox.net> Is there a design team or thread for how to add scripting to the client, ala Lua and/or Python and/or Perl etc? What should be scriptable by such an interface? How it should accomidate/facilitate plug-ins? And so on and so on and so forth? *Etcetera, etcetera, etcetera... --spoken with best royal Yul Brynner accent From brenda_archer_1 at yahoo.com Wed Aug 1 20:19:10 2007 From: brenda_archer_1 at yahoo.com (Brenda Archer) Date: Wed Aug 1 20:19:12 2007 Subject: [sldev] Communication Message-ID: <674707.86779.qm@web62507.mail.re1.yahoo.com> This is my first post, please bear with me. I'd like to try to describe what is happening when someone uses the new communicate window while running a large meeting. If this problem can be solved I would be forever grateful. I know it's been discussed but I don't know if you've seen the extreme of it. I run meetings and parties, for a large group, that often have ten to twenty people in attendance. Not all of them can use voice, because they are on Linux, at work, at home with family who are asleep, etc. So the chat window is moving non-stop, and I have to reply to it immediately, with no hesitation. At the same time, the group IM session is open, and generally IMs from individual avies are also coming in every few minutes, some of them requests to teleport (which means I'll need to Search) and some of the requests to join the group (which means I'll need to pull up the detailed group info). Eventually, I am tracking ten IM sessions, which in the original client, I ran as a bar across either the top or bottom of the screen. Every twenty seconds or so, I click through all the IM tabs to check for conversation; the people talking to me will only notice I'm replying a bit slowly. At the same time, I have to be able to see the building, walk around, greet new people, notice who's being quiet and engage them, and keep an eye out for any security issues. The only way I can do this and not look frozen, is to run the chat window and the IM windows as two separate windows, going across the top and bottom of the screen. The group info is in another separate window, and Friends list should also be separate so I can watch my volunteers come and go. I need to be able to watch all of these at once, AND walk around AND see where I am going. This is why the new communication window makes me feel blind, dumb and mute. If I attend to chat history, I can't see the people next to me. If I attend to IMs asking for teleports, I lose the thread of the chat and stand there frozen. I can't ask everyone to voice, because not everyone can. My voice is on, just in case someone tries to talk to me. With separate, resizable, potentially very small windows, I can work this meeting alone, by keeping my eyes moving just as I would driving down a freeway. I've tried to get a volunteer to help, but it doesn't work. In a social situation, when people want to talk to you, they want YOU, now, not someone else. It's critical that I be able to give them that. Many thanks, Brenda Archer From dzonatas at dzonux.net Wed Aug 1 20:59:16 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Aug 1 20:58:09 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B13402.4030804@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> Message-ID: <46B15694.7050507@dzonux.net> Lawson English wrote: > What should be scriptable by such an interface? How it should > accomidate/facilitate plug-ins? A scriptable interface allows us to use higher-level plug-in easier. The script engine has to exist as a binary plug-in at a lower level. Binary plug-ins have to be somewhat isolated in name-space. I have made the C++ class LLDynamicSharedLibrary to help with binary plug-in models. The problem is that STL code prevents us from having a stable viewer, but we are working on it. It is a matter of library/API compatibility. Plug-ins need the STL to use a more higher-level API. A very low-level API is possible, but such is much harder to port across platforms and is much harder to maintain. -- Power to Change the Void From jradford at npl.com Wed Aug 1 22:30:27 2007 From: jradford at npl.com (Jim Radford) Date: Wed Aug 1 22:30:30 2007 Subject: [sldev] UDP Issue Message-ID: <2c77def30708012230u2a976078o5fd2d801c3609bd3@mail.gmail.com> Jh: This is a new one that came up this evening out of the blue. Might be more of that udp stuff you were looking for. If I can provide further details let me know. Jim ERROR [libsecondlife]: A SocketException occurred in UDPServer.AsyncBeginSend() (System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used at System.Net.Sockets.Socket.DoBeginSendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint endPointSnapshot, SocketAddress socketAddress, OverlappedAsyncResult asyncResult) at System.Net.Sockets.Socket.BeginSendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint remoteEP, AsyncCallback callback, Object state) at libsecondlife.UDPBase.AsyncBeginSend(UDPPacketBuffer buf) in D:\dev\libsecondlife\libsecondlife\UDPBase.cs:line 368) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070801/72387db1/attachment-0001.htm From webmaster at ligosworld.com Thu Aug 2 00:54:49 2007 From: webmaster at ligosworld.com (Andreas Lichtenberger) Date: Thu Aug 2 00:54:59 2007 Subject: [sldev] bandwidth usage In-Reply-To: <00b501c7d460$d0ea3f70$7400a8c0@eaurouge> References: <46B09225.5050804@ligosworld.com> <00b501c7d460$d0ea3f70$7400a8c0@eaurouge> Message-ID: <46B18DC9.5060203@ligosworld.com> That?s just the smallest part of my question. Much more exiting is: How much for Objekts, how much for Agentupdates, how much for Textures and so on..... I hope someone can explain it exactly to me! Andi Sylvio Deutsch schrieb: > I?ve run for some months with a 256kb connection. Slow, but worked. > A friend that works helping newbies report many people on dial up > connection arriving, but all on default bodies, only once she saw one > of these be able to load the correct body). She saw also people on > 100kb connections being able to run SL. > > > {}Overtake > > > > ----- Original Message ----- From: "Andreas Lichtenberger" > > To: > Sent: Wednesday, August 01, 2007 11:01 AM > Subject: [sldev] bandwidth usage > > >> Hi, >> >> can anyone explain me exactly how much bandwidth is used by second >> life and how it is used? >> which messages are sended how often? >> how much percent of the bandwitch is used for textures or sound? >> how much percent for the messages? >> what is the minimum of bandwitch sl will run width? >> >> regards >> Andi >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From yazzgoth at gmail.com Thu Aug 2 01:18:29 2007 From: yazzgoth at gmail.com (Bartosz Ptaszynski) Date: Thu Aug 2 01:18:31 2007 Subject: [sldev] bandwidth usage In-Reply-To: <46B18DC9.5060203@ligosworld.com> References: <46B09225.5050804@ligosworld.com> <00b501c7d460$d0ea3f70$7400a8c0@eaurouge> <46B18DC9.5060203@ligosworld.com> Message-ID: Hi Andreas, There is no easy answer to your question as it depends on the sim you are currently on and the amount of prims, textures and agents (and their attachments) near you. The amount of requests and bandwidth used will grow also with the max visibility distance you have set up in properties (default 128meters). If you want to have a look at what is the bandwidth usage, frame rates, tris drawn etc etc press ctrl-shift-1 while in SL - note that there are sub menus in that window showing more detailed information. Also press ctrl-alt-shift-d to enable the debug menu and play around with the Client tab - there are few hidden windows accessible from there (there are shortcuts ctrl-shift and from numbers from 1 to 5 or 6 - I don't remember right now) with useful information on what's going on with your client at the moment. Regards, Bart P.S. On 8/2/07, Andreas Lichtenberger wrote: > > That?s just the smallest part of my question. > Much more exiting is: How much for Objekts, how much for Agentupdates, > how much for Textures and so on..... > > I hope someone can explain it exactly to me! > > Andi > > Sylvio Deutsch schrieb: > > I?ve run for some months with a 256kb connection. Slow, but worked. > > A friend that works helping newbies report many people on dial up > > connection arriving, but all on default bodies, only once she saw one > > of these be able to load the correct body). She saw also people on > > 100kb connections being able to run SL. > > > > > > {}Overtake > > > > > > > > ----- Original Message ----- From: "Andreas Lichtenberger" > > > > To: > > Sent: Wednesday, August 01, 2007 11:01 AM > > Subject: [sldev] bandwidth usage > > > > > >> Hi, > >> > >> can anyone explain me exactly how much bandwidth is used by second > >> life and how it is used? > >> which messages are sended how often? > >> how much percent of the bandwitch is used for textures or sound? > >> how much percent for the messages? > >> what is the minimum of bandwitch sl will run width? > >> > >> regards > >> Andi > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070802/f8de81e3/attachment.htm From tateru.nino at gmail.com Thu Aug 2 01:22:58 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Aug 2 01:23:06 2007 Subject: [sldev] bandwidth usage In-Reply-To: <46B18DC9.5060203@ligosworld.com> References: <46B09225.5050804@ligosworld.com> <00b501c7d460$d0ea3f70$7400a8c0@eaurouge> <46B18DC9.5060203@ligosworld.com> Message-ID: <46B19462.6010704@gmail.com> At best, I would say "Highly variable and circumstantial". It depends. How much bandwidth for me, won't be the same as for you, even if we're standing a few metres apart - simply because my settings are different and I have different network latencies to you (my higher latency would promote some steep throttling), and because our slightly different positions bring different parts of the world into view. How much for 'an object'? It depends on which object. Objects come in a wide variety of sizes. How much for textures? It depends on which texture - and on network conditions between the viewer and SL, and whether the viewer already has the texture cached. Andreas Lichtenberger wrote: > That?s just the smallest part of my question. > Much more exiting is: How much for Objekts, how much for Agentupdates, > how much for Textures and so on..... > > I hope someone can explain it exactly to me! > > Andi > > Sylvio Deutsch schrieb: >> I?ve run for some months with a 256kb connection. Slow, but worked. >> A friend that works helping newbies report many people on dial up >> connection arriving, but all on default bodies, only once she saw one >> of these be able to load the correct body). She saw also people on >> 100kb connections being able to run SL. >> >> >> {}Overtake >> >> >> >> ----- Original Message ----- From: "Andreas Lichtenberger" >> >> To: >> Sent: Wednesday, August 01, 2007 11:01 AM >> Subject: [sldev] bandwidth usage >> >> >>> Hi, >>> >>> can anyone explain me exactly how much bandwidth is used by second >>> life and how it is used? >>> which messages are sended how often? >>> how much percent of the bandwitch is used for textures or sound? >>> how much percent for the messages? >>> what is the minimum of bandwitch sl will run width? >>> >>> regards >>> Andi >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From matthew.dowd at hotmail.co.uk Thu Aug 2 02:05:45 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Aug 2 02:05:46 2007 Subject: [sldev] Voice Message-ID: > > I assume it's less noticeable with actually using voice, because I > guess using voice will draw the attention away from the screen anyway > ... equally fundamental but probably less noticeably for those who > do, because people who tend to use voice, seem to tend to use SL in > a less immersive way anyway. I guess these are more those kind of > people who write articles about SL saying it's a chatroom with > 3D avatars and now it's going to be Skype with pictures. That's also my concern with voice - I suspect if someone produces a secondlife viewer which will allow you to teleport and use voice but without the graphics (indeed this is essentially Sleek plus voice), they'd be happy. If were were allowed to wager ;-), I'd even put a bet that we'll see something like this as a feature request in the forums or jira! However, > It sort of reduces the in-world stuff to an animated background > wallpaper. I noticed this already when using the voice viewer, it > is a sublte cause, but for me has a fundamental effect on the way > I use SL. This is the point I made in the jira issue I created to capture votes from those who want the new interface abandoned rather than fixed. Farallon's screenshots, Brenda's commentary and indeed the idea of docking windows, all revolve around the philosophy that the SL viewer as a whoe is the communication media - that the raison d'etre of SL is that it is an immersive communication medium and that all components of the enviroment (visual, audio, spatial, etc) are equally important integrated components of that communication. The new UI seems very much driven by the idea of "lets create a skype like application within the SL viewer" and as a result it starts segragating these different components components of communitication and breaks the unity between them; worse it enforces this seperation onto the user rather than providing an experience where the user moves naturally between them without even noticing - and for me, that goes against the entire philosophy behind virtual 3D environments. And that is fundamentally, why the new UI has had such a negative reaction. There are some nice features in there, such as the ability to see the list of all people involved in a group IM session, but the fundamental motivation and philosophy behind the new UI is wrong (IMHO). Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From robin.cornelius at gmail.com Thu Aug 2 03:51:40 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 2 03:51:56 2007 Subject: [sldev] Crash when sorting through inventory Message-ID: <46B1B73C.40506@gmail.com> Hi Guys Linux, Debian Unstable SL i686_1_18_0_6 (DEBUG BUILD) Whilst trying to find some stuff in my inventory i get a debug assertion. Just got it twice in a row. Unfortunately i don't seem to have gdb configured correctly so it cannot see the source files. Hope this is of some use (gdb) bt #0 LLError::crashAndLoop (message=@0xbf8e9710) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-releasefordownload/llcommon/llerror.cpp:1063 #1 0x09052a90 in errorCallback (error_string=@0xbf8e9710) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/viewer.cpp:6626 #2 0xb7d9ecb3 in LLError::Log::flush (out=0xbf8e9624, site=@0x9ca6730) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-releasefordownload/llcommon/llerror.cpp:991 #3 0x085574b5 in LLFolderViewFolder::recursiveDeselect (this=0xc508340, deselect_self=0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:1600 #4 0x0855c82f in LLFolderView::clearSelection (this=0xc508340) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:3086 #5 0x0855c014 in LLFolderView::setSelection (this=0xc508340, selection=0xc493420, open=0, take_keyboard_focus=0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:2899 #6 0x08704c5b in LLSelectFirstFilteredItem::doItem (this=0xbf8e98b0, item=0xc493420) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llinventoryview.cpp:616 #7 0x08558a6a in LLFolderViewFolder::applyFunctorRecursively (this=0xc486680, functor=@0xbf8e98b0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:2025 #8 0x085589dc in LLFolderViewFolder::applyFunctorRecursively (this=0xc40b1a0, functor=@0xbf8e98b0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:2019 #9 0x085589dc in LLFolderViewFolder::applyFunctorRecursively (this=0xc508340, functor=@0xbf8e98b0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:2019 #10 0x085604c5 in LLFolderView::idle (user_data=0xc508340) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llfolderview.cpp:4270 #11 0x080f8590 in LLCallbackList::callFunctions (this=0x9bf61d0) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/llcallbacklist.cpp:116 #12 0x0904406c in idle () at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/viewer.cpp:3730 #13 0x0903d16e in main_loop () at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/viewer.cpp:1836 #14 0x0903c97e in main (argc=1, argv=0xbf8ea254) at /tmp/robin/home/robin/SL/linden/indra/i686-linux-client-debug/newview/viewer.cpp:1712 -- Robin Cornelius http://www.byteme.org.uk From robin.cornelius at gmail.com Thu Aug 2 04:10:53 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 2 04:11:00 2007 Subject: [sldev] Crash when sorting through inventory In-Reply-To: <46B1B73C.40506@gmail.com> References: <46B1B73C.40506@gmail.com> Message-ID: <46B1BBBD.4060403@gmail.com> Robin Cornelius wrote: > > Hi Guys > > Linux, Debian Unstable SL i686_1_18_0_6 (DEBUG BUILD) > > Whilst trying to find some stuff in my inventory i get a debug > assertion. Just got it twice in a row. I can do this every time now, open inventory window. Select "My Inventory" at the top then try to search for something by typing in the box, this shows be lots of matching inventory for the first few letters. As i then delete the letters i get this assertion. -- Robin Cornelius http://www.byteme.org.uk From nicholaz at blueflash.cc Thu Aug 2 05:07:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Aug 2 05:07:54 2007 Subject: [sldev] Voice In-Reply-To: References: Message-ID: <46B1C910.5090505@blueflash.cc> Matthew Dowd wrote: > That's also my concern with voice - I suspect if someone produces a secondlife viewer which will allow you to teleport and use voice but without the graphics (indeed this is essentially Sleek plus voice), they'd be happy. > > If were were allowed to wager ;-), I'd even put a bet that we'll see something like this as a feature request in the forums or jira! Well, if someone wants to use it that way, I'm fine as long as they let me use the program my way (and I think this is the bottom line in many posts). >> It sort of reduces the in-world stuff to an animated background >> wallpaper. I noticed this already when using the voice viewer, it >> is a sublte cause, but for me has a fundamental effect on the way >> I use SL. > > This is the point I made in the jira issue I created to capture votes from those who want the new interface abandoned rather than fixed. Farallon's screenshots, Brenda's commentary and indeed the idea of docking windows, all revolve around the philosophy that the SL viewer as a whoe is the communication media - that the raison d'etre of SL is that it is an immersive communication medium and that all components of the enviroment (visual, audio, spatial, etc) are equally important integrated components of that communication. > > The new UI seems very much driven by the idea of "lets create a skype like application within the SL viewer" and as a result it starts segragating these different components components of communitication and breaks the unity between them; worse it enforces this seperation onto the user rather than providing an experience where the user moves naturally between them without even noticing - and for me, that goes against the entire philosophy behind virtual 3D environments. > > And that is fundamentally, why the new UI has had such a negative reaction. There are some nice features in there, such as the ability to see the list of all people involved in a group IM session, but the fundamental motivation and philosophy behind the new UI is wrong (IMHO). That's an excellent analysis. Couldn't have worded it any better, kudos! Nick From jhurliman at wsu.edu Thu Aug 2 05:39:00 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Aug 2 05:39:31 2007 Subject: [sldev] DiamondWare Thin Voice Client Protocol? In-Reply-To: <46B1C910.5090505@blueflash.cc> References: <46B1C910.5090505@blueflash.cc> Message-ID: <46B1D064.30504@wsu.edu> Any word on when documentation will be released for the "Thin Voice Client" protocol to communicate with the voice daemon that ships with SL? John Hurliman From lenglish5 at cox.net Thu Aug 2 06:27:06 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 06:27:09 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B15694.7050507@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> Message-ID: <46B1DBAA.30606@cox.net> Dzonatas wrote: > Lawson English wrote: >> What should be scriptable by such an interface? How it should >> accomidate/facilitate plug-ins? > A scriptable interface allows us to use higher-level plug-in easier. > The script engine has to exist as a binary plug-in at a lower level. > > Binary plug-ins have to be somewhat isolated in name-space. I have > made the C++ class LLDynamicSharedLibrary to help with binary plug-in > models. > > The problem is that STL code prevents us from having a stable viewer, > but we are working on it. It is a matter of library/API compatibility. > Plug-ins need the STL to use a more higher-level API. A very low-level > API is possible, but such is much harder to port across platforms and > is much harder to maintain. > You said on the forums that you were working on a Python plug-in. Why specifically Python, rather than Lua, given the relative simplicity of implementing Lua as a plug-in scripting language (that is what it is designed for) compared to implementing a Python plug-in, and the fact that Lua is already used as the scripting language for the Worlds of Warcraft client and has a proven track record for scripting such a system? Please keep in mind that I use neither language. My question is purely a technical one about the relative simplicity and cleanliness of the plug-in. From dzonatas at dzonux.net Thu Aug 2 07:32:54 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 07:31:48 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1DBAA.30606@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> Message-ID: <46B1EB16.30405@dzonux.net> Lawson English wrote: > You said on the forums that you were working on a Python plug-in. Why > specifically Python, rather than Lua, given the relative simplicity of > implementing Lua as a plug-in scripting language (that is what it is > designed for) compared to implementing a Python plug-in, and the fact > that Lua is already used as the scripting language for the Worlds of > Warcraft client and has a proven track record for scripting such a > system? > > Please keep in mind that I use neither language. My question is purely > a technical one about the relative simplicity and cleanliness of the > plug-in. > Several reasons exist to answer your question. There was a notice somewhere posted awhile back that LL has internally accepted python as the main scripting language for development. That was mainly in the build and maintenance process and didn't reflect LSL. The action set a due weight on python to integrate it with the viewer, furthermore. The sources reveal that some work has already been done to integrate python. Since it appeared the integration appeared to be stale, I took the initiative to continue that progress from what I noticed has been already done. Any implementation at such lower-level, be it included in the main exe or as a binary plug-in, has to have license compatibility with LL's terms. The implementation of python that is already done does carry an already accepted license. There is some integration between Maya scripts and python, and that is a benefit to artist and sculptie creators. There is already a well established interface between Blender and python, and that is a powerful tool to many artists. There is already ample work (Iron Python) to integrate python compiled scripts with mono/ecma, which we known mono is already another preferred scripting basis. This hints that it is probably easy to move from the license model now established to one that also includes mono/ecma basis in the viewer, if desired. Another item to consider is cost. While I'm not against many other languages, they may be more costly to support. Since python has rooted a precedence in use, it appears less costly to continue with such route than to completely switch to a new scripting language. If you want to continue with Lua, I suggest to creat a jira task and gather votes. From there, we can create sub-tasks to cover the other details needed to implement and support another scripting language under the open source model. Others have expressed desire for their choice in scripting languages, too. That means the binary plug-in API needs to evolve to allow such robustness. -- Power to Change the Void From tateru.nino at gmail.com Thu Aug 2 07:38:37 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Aug 2 07:38:44 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1EB16.30405@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> Message-ID: <46B1EC6D.4070806@gmail.com> It's also a common scripting language for games. I can name four or five major titles where much of the game is built in python over the engine. Dzonatas wrote: > Lawson English wrote: >> You said on the forums that you were working on a Python plug-in. >> Why specifically Python, rather than Lua, given the relative >> simplicity of implementing Lua as a plug-in scripting language (that >> is what it is designed for) compared to implementing a Python >> plug-in, and the fact that Lua is already used as the scripting >> language for the Worlds of Warcraft client and has a proven track >> record for scripting such a system? >> >> Please keep in mind that I use neither language. My question is >> purely a technical one about the relative simplicity and cleanliness >> of the plug-in. >> > > Several reasons exist to answer your question. > > There was a notice somewhere posted awhile back that LL has internally > accepted python as the main scripting language for development. That > was mainly in the build and maintenance process and didn't reflect > LSL. The action set a due weight on python to integrate it with the > viewer, furthermore. > > The sources reveal that some work has already been done to integrate > python. Since it appeared the integration appeared to be stale, I took > the initiative to continue that progress from what I noticed has been > already done. > > Any implementation at such lower-level, be it included in the main exe > or as a binary plug-in, has to have license compatibility with LL's > terms. The implementation of python that is already done does carry an > already accepted license. > > There is some integration between Maya scripts and python, and that is > a benefit to artist and sculptie creators. > > There is already a well established interface between Blender and > python, and that is a powerful tool to many artists. > > There is already ample work (Iron Python) to integrate python compiled > scripts with mono/ecma, which we known mono is already another > preferred scripting basis. This hints that it is probably easy to move > from the license model now established to one that also includes > mono/ecma basis in the viewer, if desired. > > Another item to consider is cost. While I'm not against many other > languages, they may be more costly to support. Since python has rooted > a precedence in use, it appears less costly to continue with such > route than to completely switch to a new scripting language. > > If you want to continue with Lua, I suggest to creat a jira task and > gather votes. From there, we can create sub-tasks to cover the other > details needed to implement and support another scripting language > under the open source model. > > Others have expressed desire for their choice in scripting languages, > too. That means the binary plug-in API needs to evolve to allow such > robustness. > -- Tateru Nino http://dwellonit.blogspot.com/ From mattk at electricsheepcompany.com Thu Aug 2 07:44:08 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Aug 2 07:44:08 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1EB16.30405@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> Message-ID: <46B1EDB8.4060903@electricsheepcompany.com> If we're already thinking forward to a day when the client runs a Mono VM, it seems to me like it might be worth setting that as a goal now, rather than going through the pain of integrating traditional Python and later replacing it with Mono/IronPython. In my mind, Mono has a number of advantages as a scripting solution, chief among them being the fact that it provides a very well-sandboxed execution environment, a trust and security model (from the Silverlight port), and that, with a bit of extra effort, we could probably support many different CIL-compilable languages. Imagine being able to script the client in your choice of IronPython, C#, the upcoming CIL-compiled Ruby, and so forth... -Matt Dzonatas wrote: > Lawson English wrote: >> You said on the forums that you were working on a Python plug-in. Why >> specifically Python, rather than Lua, given the relative simplicity of >> implementing Lua as a plug-in scripting language (that is what it is >> designed for) compared to implementing a Python plug-in, and the fact >> that Lua is already used as the scripting language for the Worlds of >> Warcraft client and has a proven track record for scripting such a >> system? >> >> Please keep in mind that I use neither language. My question is purely >> a technical one about the relative simplicity and cleanliness of the >> plug-in. >> > > Several reasons exist to answer your question. > > There was a notice somewhere posted awhile back that LL has internally > accepted python as the main scripting language for development. That was > mainly in the build and maintenance process and didn't reflect LSL. The > action set a due weight on python to integrate it with the viewer, > furthermore. > > The sources reveal that some work has already been done to integrate > python. Since it appeared the integration appeared to be stale, I took > the initiative to continue that progress from what I noticed has been > already done. > > Any implementation at such lower-level, be it included in the main exe > or as a binary plug-in, has to have license compatibility with LL's > terms. The implementation of python that is already done does carry an > already accepted license. > > There is some integration between Maya scripts and python, and that is a > benefit to artist and sculptie creators. > > There is already a well established interface between Blender and > python, and that is a powerful tool to many artists. > > There is already ample work (Iron Python) to integrate python compiled > scripts with mono/ecma, which we known mono is already another preferred > scripting basis. This hints that it is probably easy to move from the > license model now established to one that also includes mono/ecma basis > in the viewer, if desired. > > Another item to consider is cost. While I'm not against many other > languages, they may be more costly to support. Since python has rooted a > precedence in use, it appears less costly to continue with such route > than to completely switch to a new scripting language. > > If you want to continue with Lua, I suggest to creat a jira task and > gather votes. From there, we can create sub-tasks to cover the other > details needed to implement and support another scripting language > under the open source model. > > Others have expressed desire for their choice in scripting languages, > too. That means the binary plug-in API needs to evolve to allow such > robustness. > From dzonatas at dzonux.net Thu Aug 2 08:14:48 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 08:13:41 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1EDB8.4060903@electricsheepcompany.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> <46B1EDB8.4060903@electricsheepcompany.com> Message-ID: <46B1F4E8.5090507@dzonux.net> Matt Kimmel wrote: > If we're already thinking forward to a day when the client runs a Mono > VM, it seems to me like it might be worth setting that as a goal now, > rather than going through the pain of integrating traditional Python and > later replacing it with Mono/IronPython. Mmhmm. Has there been any research done to determine if Mono/.NET runs on the same number of platforms as python 2.5? Python can solve the immediate features demands. Its implementation should be limited to that. From there when those demands have been met and those pains healed, I suggest to decide to continue with greater integration of python or move to a goal like Mono as you suggest, which I think the later will happen. There is a lot of benefits to have Mono/.NET in the viewer, which I'll remain subtle about because of potential security concerns. More visibility on such managed code basis no doubt will lead to greater security awareness and further VM improvement. The ECMA VM is an abstracted layer that can be abstracted again when needed. =) -- Power to Change the Void From mattk at electricsheepcompany.com Thu Aug 2 08:21:26 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Aug 2 08:21:27 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1F4E8.5090507@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> <46B1EDB8.4060903@electricsheepcompany.com> <46B1F4E8.5090507@dzonux.net> Message-ID: <46B1F676.5090406@electricsheepcompany.com> I do see your point. Adding mono and its security concerns certainly opens up a can of worms, though perhaps one that can be closed with some effort, to take the metaphor a bit too far. :-) For what it's worth, Mono runs on all the officially supported platforms (Windows, Mac, Linux x86), as well as Linux x86_64. I'm not sure what its status is on other client platforms that I've heard people discuss, such as Solaris and FreeBSD. -Matt Dzonatas wrote: > Matt Kimmel wrote: >> If we're already thinking forward to a day when the client runs a Mono >> VM, it seems to me like it might be worth setting that as a goal now, >> rather than going through the pain of integrating traditional Python and >> later replacing it with Mono/IronPython. > > Mmhmm. Has there been any research done to determine if Mono/.NET runs > on the same number of platforms as python 2.5? > > Python can solve the immediate features demands. Its implementation > should be limited to that. From there when those demands have been met > and those pains healed, I suggest to decide to continue with greater > integration of python or move to a goal like Mono as you suggest, which > I think the later will happen. > > There is a lot of benefits to have Mono/.NET in the viewer, which I'll > remain subtle about because of potential security concerns. More > visibility on such managed code basis no doubt will lead to greater > security awareness and further VM improvement. The ECMA VM is an > abstracted layer that can be abstracted again when needed. =) > From tofu.linden at lindenlab.com Thu Aug 2 08:31:16 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Aug 2 08:31:29 2007 Subject: [sldev] Crash when sorting through inventory In-Reply-To: <46B1BBBD.4060403@gmail.com> References: <46B1B73C.40506@gmail.com> <46B1BBBD.4060403@gmail.com> Message-ID: <46B1F8C4.1020603@lindenlab.com> Robin Cornelius wrote: > Robin Cornelius wrote: >> >> Hi Guys >> >> Linux, Debian Unstable SL i686_1_18_0_6 (DEBUG BUILD) >> >> Whilst trying to find some stuff in my inventory i get a debug >> assertion. Just got it twice in a row. > > I can do this every time now, open inventory window. Select "My > Inventory" at the top then try to search for something by typing in the > box, this shows be lots of matching inventory for the first few letters. > As i then delete the letters i get this assertion. Unfortunately (or fortunately), I can't reproduce this in a recent releasefordownload build. I'm going to take a closer look at the 1_18_0_6 source snapshot. Thanks, -Tofu From tofu.linden at lindenlab.com Thu Aug 2 08:43:09 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Aug 2 08:43:18 2007 Subject: [sldev] Crash when sorting through inventory In-Reply-To: <46B1F8C4.1020603@lindenlab.com> References: <46B1B73C.40506@gmail.com> <46B1BBBD.4060403@gmail.com> <46B1F8C4.1020603@lindenlab.com> Message-ID: <46B1FB8D.9030506@lindenlab.com> Tofu Linden wrote: > Unfortunately (or fortunately), I can't reproduce this in a > recent releasefordownload build. I'm going to take a closer look > at the 1_18_0_6 source snapshot. Oh, it really is an llassert - and it does look quite serious that this is firing. I'll look into it. http://jira.secondlife.com/browse/VWR-1974 Thanks, -Tofu From dale at daleglass.net Thu Aug 2 08:53:53 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Aug 2 08:54:04 2007 Subject: [sldev] Group IM broken in released source? Message-ID: <20070802155353.GA20663@bruno.sbruno> It looks like group IM now doesn't work in the released source. Took me a long time to realize because I very rarely start one myself, and I left most groups that used it often. Here's what I see here: Can't start conference with friends Can't start group IM Can't receive group IM at all I'm using the source from SVN. Thought it might have been grid problems, but it looks like it works fine for other people. I'm asking here in case it's something I maanged to screw up somehow. If anybody else is seeing this, I'll file a bug on jira. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070802/78dac7c8/attachment.pgp From lenglish5 at cox.net Thu Aug 2 08:58:14 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 08:58:16 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B1EB16.30405@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> Message-ID: <46B1FF16.2030800@cox.net> Dzonatas wrote: > Lawson English wrote: >> You said on the forums that you were working on a Python plug-in. >> Why specifically Python, rather than Lua, given the relative >> simplicity of implementing Lua as a plug-in scripting language (that >> is what it is designed for) compared to implementing a Python >> plug-in, and the fact that Lua is already used as the scripting >> language for the Worlds of Warcraft client and has a proven track >> record for scripting such a system? >> >> Please keep in mind that I use neither language. My question is >> purely a technical one about the relative simplicity and cleanliness >> of the plug-in. >> > > Several reasons exist to answer your question. > > There was a notice somewhere posted awhile back that LL has internally > accepted python as the main scripting language for development. That > was mainly in the build and maintenance process and didn't reflect > LSL. The action set a due weight on python to integrate it with the > viewer, furthermore. > > The sources reveal that some work has already been done to integrate > python. Since it appeared the integration appeared to be stale, I took > the initiative to continue that progress from what I noticed has been > already done. > > Any implementation at such lower-level, be it included in the main exe > or as a binary plug-in, has to have license compatibility with LL's > terms. The implementation of python that is already done does carry an > already accepted license. > I doubt that Lua's is any less acceptable. > There is some integration between Maya scripts and python, and that is > a benefit to artist and sculptie creators. > /shrug. Not all Maya developers appreciate Python. > There is already a well established interface between Blender and > python, and that is a powerful tool to many artists. > > There is already ample work (Iron Python) to integrate python compiled > scripts with mono/ecma, which we known mono is already another > preferred scripting basis. This hints that it is probably easy to move > from the license model now established to one that also includes > mono/ecma basis in the viewer, if desired. > Ironpython is, by its nature, slower than native python, or any almost other native scripting system, for that matter. > Another item to consider is cost. While I'm not against many other > languages, they may be more costly to support. Since python has rooted > a precedence in use, it appears less costly to continue with such > route than to completely switch to a new scripting language. > Perhaps. Lua was designed to be a lightweight scripting add-on, and is claimed to be faster at most executable tasks than almost any other scripting language out there. What is the cost of maintaining Python vs maintaining Lua? How does someone determine that? Were these questions ever asked when deciding to implement Python as the first scripting language for the SL client? > If you want to continue with Lua, I suggest to creat a jira task and > gather votes. From there, we can create sub-tasks to cover the other > details needed to implement and support another scripting language > under the open source model. > > Others have expressed desire for their choice in scripting languages, > too. That means the binary plug-in API needs to evolve to allow such > robustness. > I'm even more concerned about what is expected to be accessible via such an API. The Worlds of Warcraft client API exposes virtually everything. Is this the plan for scripting in the SL client? Will anything more than control of GUI widgets be offered? What guidelines are used to decide what should or should not be scriptable? My REAL concern is that there appears to have been no real public discussion of these issues, let alone any public discussion of what design of the client-architecture might make sense in the long-term and how scripting and plug-ins should be implemented, both now and under some future (hopefully better) architecture. Will implementing client-scripting under the current architecture of the client make it difficult or even impossible to change the design of the client to something better? Etc. From bos at lindenlab.com Thu Aug 2 09:32:56 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Aug 2 09:33:04 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B13402.4030804@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> Message-ID: <46B20738.9080508@lindenlab.com> Lawson English wrote: > Is there a design team or thread for how to add scripting to the client, > ala Lua and/or Python and/or Perl etc? We're in the early stages of kicking this idea around internally. As you might know, we're going to switch to Mono for LSL scripting on the server side; that's overwhelmingly likely to be the direction we'll take on the viewer side, too, because of its multilingual capabilities. References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B15694.7050507@dzonux.net> <46B1DBAA.30606@cox.net> <46B1EB16.30405@dzonux.net> <46B1FF16.2030800@cox.net> Message-ID: <46B20DB6.5040207@dzonux.net> Lawson English wrote: > Perhaps. Lua was designed to be a lightweight scripting add-on, and is > claimed to be faster at most executable tasks than almost any other > scripting language out there. What is the cost of maintaining Python > vs maintaining Lua? How does someone determine that? Were these > questions ever asked when deciding to implement Python as the first > scripting language for the SL client? As for lightweight and speed, there are highly optimized VMs much more suited for the job besides these more popular languages. The optimized VMs add additional cost as it requires everybody to be follow accord with it, and the cost not only reflects the provider but also the consumer. I don't think there ever was a mandate to implement python as the first scripting language. It appears python was a choice of consolidation. Someone else with TheOfficialWord(tm) can correct me there. =) Based on hints of previous documents, that, under the current solid exe model, an exposed API is too risky to implement. (I know some who want to overlook that risk.) Therefore, binary plug-ins (similar to ABIs) have been needed in order to isolate a particular program space away from the solid-core exe model. As stated many times on this list, however, there is much friction to add any additional DLL, DSO, DYNLIB or likewise to be officially distributed along with a Second Life installation. In reality under the hood, think of it more like python is being completely exiled from the solid-core exe and put into its own space rather than being the first scripting language. This particular effort has fallen into the hands of open source developers, which I have take an initiative to develop since I already have other works with similar binary plug-in needs. > I'm even more concerned about what is expected to be accessible via > such an API. > > The Worlds of Warcraft client API exposes virtually everything. Is > this the plan for scripting in the SL client? Will anything more than > control of GUI widgets be offered? What guidelines are used to decide > what should or should not be scriptable? The votes tallied in jira issues are helpful to what is immediately needed. > > My REAL concern is that there appears to have been no real public > discussion of these issues, let alone any public discussion of what > design of the client-architecture might make sense in the long-term > and how scripting and plug-ins should be implemented, both now and > under some future (hopefully better) architecture. There has been, but it keeps going stale. Several resources on the wiki, here is some: https://wiki.secondlife.com/wiki/Plugin_architecture_survey https://wiki.secondlife.com/wiki/SLDev-Traffic_1#C.2B.2B_motivated_Plugin_Bindings https://wiki.secondlife.com/wiki/Sculpted_Prims:_3d_Software_Guide (search for "plugins" on this page) https://wiki.secondlife.com/wiki/Plugin_architecture_Security https://wiki.secondlife.com/wiki/Sculptie_Dev https://wiki.secondlife.com/wiki/Plugin_architecture https://wiki.secondlife.com/wiki/User_Interface_Roadmap And, some InternalWord(tm): Bryan O'Sullivan wrote: > Lawson English wrote: >> Is there a design team or thread for how to add scripting to the >> client, ala Lua and/or Python and/or Perl etc? > > We're in the early stages of kicking this idea around internally. As > you might know, we're going to switch to Mono for LSL scripting on the > server side; that's overwhelmingly likely to be the direction we'll > take on the viewer side, too, because of its multilingual capabilities. From here I can recommend that any forward direction taken needs a proof-of-concept in its path. -- Power to Change the Void From lenglish5 at cox.net Thu Aug 2 10:43:32 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 10:43:33 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B20738.9080508@lindenlab.com> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B20738.9080508@lindenlab.com> Message-ID: <46B217C4.2000606@cox.net> Bryan O'Sullivan wrote: > Lawson English wrote: >> Is there a design team or thread for how to add scripting to the >> client, ala Lua and/or Python and/or Perl etc? > > We're in the early stages of kicking this idea around internally. As > you might know, we're going to switch to Mono for LSL scripting on the > server side; that's overwhelmingly likely to be the direction we'll > take on the viewer side, too, because of its multilingual capabilities. > > So... Just how robust will the Mac version of this mono interpreter be? From lenglish5 at cox.net Thu Aug 2 13:40:54 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 13:40:56 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B217C4.2000606@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B20738.9080508@lindenlab.com> <46B217C4.2000606@cox.net> Message-ID: <46B24156.6030705@cox.net> Lawson English wrote: > Bryan O'Sullivan wrote: >> Lawson English wrote: >>> Is there a design team or thread for how to add scripting to the >>> client, ala Lua and/or Python and/or Perl etc? >> >> We're in the early stages of kicking this idea around internally. As >> you might know, we're going to switch to Mono for LSL scripting on >> the server side; that's overwhelmingly likely to be the direction >> we'll take on the viewer side, too, because of its multilingual >> capabilities. >> >> > > > So... Just how robust will the Mac version of this mono interpreter be? OK, the only real reason I can see to release a mono interpreter on the client-side is if they're planning on letting the clients host their own mini-sims, ala Croquet. That would be cool but is rather far off. From secret.argent at gmail.com Thu Aug 2 14:25:16 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 2 14:24:55 2007 Subject: [sldev] Scripting the client In-Reply-To: <20070802053031.039DD41B0A8@stupor.lindenlab.com> References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> Message-ID: Lawson English: > Is there a design team or thread for how to add scripting to the > client, > ala Lua and/or Python and/or Perl etc? > > What should be scriptable by such an interface? How it should > accomidate/facilitate plug-ins? > > And so on and so on and so forth? > > *Etcetera, etcetera, etcetera... --spoken with best royal Yul Brynner > accent There's several different things that people might be looking for in scripting the client, and they probably don't have the same solution. 1. More control over the client from LSL, this includes things like HTML notecards, improved dialogs (including notecard-driven HTML dialogs, my favorite), as well as communication between LSL and local executing programs and pushing scripts into the client from LSL. 2. More control over the client from local software, plugins, and so on. 3. Extending the user interface with scripted extensions to the XML user interface, similar to Firefox extensions, Konfabulator or Dashboard widgets, and so on. I think that the first section should be severely limited in scope, for security reasons, and a separate extension from the other two. The same language and interpreter could be used (and there's already a Javascript interpreter in the client from Gecko), but there should be a separate instance of it that doesn't have access to any extensions available to locally installed software. Best would be to make it something like "Safe Tcl", where the symbol table available to the untrusted interpreter doesn't even provide entry points for any routine that isn't either fully internal (like math functions) or restricted to only allow safe operations. From secret.argent at gmail.com Thu Aug 2 14:43:49 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 2 14:43:27 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <20070802153130.A403041B0C2@stupor.lindenlab.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> Message-ID: <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> Lawson English: > You said on the forums that you were working on a Python plug-in. Why > specifically Python, rather than Lua, given the relative simplicity of > implementing Lua as a plug-in scripting language (that is what it is > designed for) compared to implementing a Python plug-in, and the fact > that Lua is already used as the scripting language for the Worlds of > Warcraft client and has a proven track record for scripting such a > system? The language I would rather see would be Tcl. It was designed from the start as a glue language, has been ported widely (and even to as limited environments as the old Palm III), and has standard mechanisms (Safe Tcl) for creating restricted interpreters that *can not* be broken out of because it creates fully sandboxed interpreters that do not even have unsafe APIs exposed through them. Failing that, it should be possible to create similarly sandboxed ECMAscript interpreters, and the client already supports Javascript and there is an extensive base of developers experienced in both Javascript and Actionscript. I do not think we should trust Microsoft's partial sandbox design: for the last decade the same high level security model as implemented in IE and ActiveX has been broken again and again by exploiting *design flaws* that are inherent to the whole "security zone" model. From gigstaggart at gmail.com Thu Aug 2 14:52:23 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 2 14:52:10 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> Message-ID: <46B25217.10702@gmail.com> Argent Stonecutter wrote: > Failing that, it should be possible to create similarly sandboxed > ECMAscript interpreters, and the client already supports Javascript and Something to ponder, SVG can fully support ECMAScript, killing like 100 birds with one stone. :) SVG-on-a-prim just makes sense. -Jason From odysseus654 at gmail.com Thu Aug 2 14:56:35 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Thu Aug 2 14:56:36 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <46B25217.10702@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B25217.10702@gmail.com> Message-ID: <1674f6c70708021456n3d4873d0s35a198b4059799bf@mail.gmail.com> Another input with the whole python thing, I evaluated python as a possible scripting language for our own product and was extremely disappointed of its distinct lack of security or the ability to put the language in a sandbox. The language looks like it was designed to thwart any attempts to do so... On 8/2/07, Jason Giglio wrote: > > Argent Stonecutter wrote: > > Failing that, it should be possible to create similarly sandboxed > > ECMAscript interpreters, and the client already supports Javascript and > > Something to ponder, SVG can fully support ECMAScript, killing like 100 > birds with one stone. :) > > SVG-on-a-prim just makes sense. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070802/145a8f4e/attachment.htm From secret.argent at gmail.com Thu Aug 2 15:19:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 2 15:18:41 2007 Subject: [sldev] Re: Scripting the client, and sculpties... things that make you go hmmm... In-Reply-To: <46B25217.10702@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B25217.10702@gmail.com> Message-ID: On 02-Aug-2007, at 16:52, Jason Giglio wrote: > Something to ponder, SVG can fully support ECMAScript, killing like > 100 birds with one stone. :) > > SVG-on-a-prim just makes sense. So long as it can be done purely from within the game, without requiring HTTP access or resources otherwise fetched from an external server that would have to be maintained indefinitely, you have my vote. Considering the current trends in SL... llApplyLinkSVG(integer link,integer face,string code); // If the code starts with "<" it is assumed to be inline, otherwise it is the name or UUID of a notecard // The SVG provided will be treated as an overlay for the texture on the face, which would allowing you to render // multiple frames that can be reliably cached and animated purely client-side without any further script execution // either on the client or server. // The special face value FACE_SCULPT would allow the SVG to modify the sculpt texture of a sculpted prim. // FACE_SCULPT should of course also be an option for llSetTextureAnimation() :) From soft at lindenlab.com Thu Aug 2 15:23:39 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Aug 2 15:23:41 2007 Subject: [sldev] Improving VS2005 builds -- what's needed? Message-ID: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> Dzonatas Sol brought up that VS2005 builds are unusuable during today's open source office hours. What's the scope of the breakage? >From comments, it sounded like there was more than just missing files in the project. While we're continuing to use VS2003 internally owing to using a monolithic solution file that includes old VS2003 library dependencies, I we can't commit to having someone building and running QA on 2005 yet. Still, is there anything we can do/include to simplify things if there are other manual repair and update steps you're taking? It would be great if updates were as simple as pulling down a community-updated VS2005 project file from a pJIRA. From anthony at lindenlab.com Thu Aug 2 15:32:19 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Aug 2 15:32:38 2007 Subject: [sldev] Source release for 1.18.1.2 Message-ID: <46B25B73.2000807@lindenlab.com> Hello everyone, It's been a while since I've done one of these, so let me know if I miss anything. 1.18.1.2 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 Release note information provided below. Blog announcement: http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ Checksums: 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip SVN checkout: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 Enjoy. -Anthony Release Notes for Second Life 1.18.1(2) August 2, 2007 ===================================== New Features: * In-World Voice Chat ** In-world Voice Chat is now part of the main viewer. ** You can see and manage all voice settings in Edit > Preferences > Voice Chat. ** Voice is off by default. To enable (and disable) voice, visit Edit > Preferences > Voice Chat and check/uncheck the box beside "Enable voice chat". ** A voice set-up wizard appears during first voice use to help residents set up voice and adjust their mic volume and tuning. You should run the voice set-up wizard even if you only want the ability to hear others and do not wish to speak. ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by default, which means Resident mics are OFF by default. ** Speech gestures for voice are included in the Library, in Gestures > Speech Gestures. These gestures need to be activated in order to work; they are off by default. * Streaming video support for Linux client. Changes: * Shortcut keys for menu items in the Client & Server menus are now disabled if the menus are hidden. * Text from objects can be muted. Bug fixes: * VWR-1797: Remove mention of "Live Help" from Crash Logger * VWR-1732: Pressing Enter, with multiple inventory objects selected, crashes viewer * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack on Windows build * VWR-1723: Possible crash in llvopartgroup * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler warning #4065 for 'switch' statements * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry * VWR-1698: Clean up parcel flag manipulation * VWR-1655: Script Warnings/errors window is hard to resize, resets size after closing tabs. * VWR-1646: Possible crash when login server is unavailable. * VWR-1626: Patch to avoid IM window from resizing when sessions open or close * VWR-1613: Overuse of virtual * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats tuning * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp * VWR-1578: Two quirks in IM regarding "xxxx is typing" * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing on first use when "only select own objects" is enabled * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are disabled when opening friends list window * VWR-1468: LoginPacketNeverReceived dialog text is incorrect * VWR-1462: Order of right-click menu on Inventory is confusing * VWR-1453: A few old-school changes for llviewerregion.cpp * VWR-1434: Null pointer crash when terraforming * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 * VWR-1382: Some scripted objects are highlighted in red while pressing Alt with tools open * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build fails. * VWR-1358: Physical objects remain red if tools window is closed while holding Alt key * VWR-1358: Physical objects remain red if tools window is closed while holding Alt key * VWR-1353: Misleading variable names in LLTextEditor * VWR-1344: Reverse order of popups, so that new ones appear underneath existing ones rather than on top. * VWR-1318: Selecting Cancel while saving a snapshot to disk still triggers snapshot gesture * VWR-1314: Multiple selection then individual deselection of attachments broken * VWR-1294: Possibly threads not fully cleaned up at end of program * VWR-1289: On logging in, sound volume for stream is low, despite the actual setting in the music control * VWR-1282: Better error handling when fonts are missing * VWR-1270: Script error window keeps reverting to a very small size * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key * VWR-1105: Set internal limit of particle count to max value from GUI preferences. * VWR-1092: Disable mouse hover text on HUDs, since it always only shows the owner's name and generally gets in the way of HUD functionality. * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: ... resizeable and minimizable) * VWR-447: Allow minimized windows to be repositioned in client * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu * VWR-349: Change keyboard shortcuts, because entering { [ ] } on German and some other international keyboards (AltGr 7, 8, 9, 0) triggers Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 (previously resulting in unstable viewer) * VWR-238: Permissions of Roles and Rights in the german version are mased up. * VWR-102: md5 slow * SVC-371: Fix the legibility and grammar/consistency of the new llOwnerSay implementation * SVC-193: llParticleSystem - halo of rogue particles around original particle system after 1.15 update* SVC-373: Deleting a script's code results in a non-existent file and "missing from database" error * Fixed preference for showing or hiding server combo box was not preserved * Fixed residents with negative L$ balance can't purchase items set for sale "Original" or "Copy" that are being sold for L$0 * "Copy SLURL to clipboard" is now enabled for an avatar's current coordinates * Macintosh viewer now correctly opens the map and selects the destination on a SLURL request * Leading and trailing spaces are now automatically trimmed from parcel media URLs * Corrected the spacing of the yellow "next dialog" chevron (was partially blocked by the Mute button) * Corrected the error message shown when adding 11th Estate Manager * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo * "Set Window Size..." setting is now correctly resumed after being minimized * Added link to Qa wiki in the viewer bug reporter menu. * Updated text in Second Life Crash Logger with new support portal information * Corrected an issue with UI font scaling in the bug reporter window From mattk at electricsheepcompany.com Thu Aug 2 15:43:31 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Aug 2 15:43:30 2007 Subject: [sldev] Improving VS2005 builds -- what's needed? In-Reply-To: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> References: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> Message-ID: <46B25E13.3000602@electricsheepcompany.com> Hi Soft, A great starting place is VWR-1151; that JIRA issue contains VS2005 project files that Nicholaz and I have put together for recent releases, as well as some good notes about problems we (and others) have encountered. That might provide the basis for the inclusion of updated VS2005 project files in the open source viewer, at least. Others may chime in with their experiences, but most of the issues I've encountered in using VS2005 builds have to do with subtle differences between VS2003 and VS2005's STL implementations. I wrote up some notes on a big one in VWR-1151. With that said, I've had pretty good luck running my own homegrown VS2005 builds, using the fixed project files in that JIRA issue. I'd be curious to hear other VS2005 users' thoughts. -Matt Soft Linden wrote: > Dzonatas Sol brought up that VS2005 builds are unusuable during > today's open source office hours. What's the scope of the breakage? >>From comments, it sounded like there was more than just missing files > in the project. > > While we're continuing to use VS2003 internally owing to using a > monolithic solution file that includes old VS2003 library > dependencies, I we can't commit to having someone building and running > QA on 2005 yet. Still, is there anything we can do/include to simplify > things if there are other manual repair and update steps you're > taking? It would be great if updates were as simple as pulling down a > community-updated VS2005 project file from a pJIRA. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From gigstaggart at gmail.com Thu Aug 2 15:43:47 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 2 15:43:34 2007 Subject: [sldev] Re: Scripting the client, and sculpties... things that make you go hmmm... In-Reply-To: References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B25217.10702@gmail.com> Message-ID: <46B25E23.1020809@gmail.com> Argent Stonecutter wrote: > On 02-Aug-2007, at 16:52, Jason Giglio wrote: >> Something to ponder, SVG can fully support ECMAScript, killing like >> 100 birds with one stone. :) >> >> SVG-on-a-prim just makes sense. > > So long as it can be done purely from within the game, without requiring > HTTP access or resources otherwise fetched from an external server that > would have to be maintained indefinitely, you have my vote. > Right, SVG-on-a-prim is distinct from web textures (but not mutually exclusive). SVG is inherently low-bandwidth and could be easily served from LL servers. -Jason From blakar at gmail.com Thu Aug 2 15:47:40 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Aug 2 15:47:43 2007 Subject: [sldev] Improving VS2005 builds -- what's needed? In-Reply-To: <46B25E13.3000602@electricsheepcompany.com> References: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> <46B25E13.3000602@electricsheepcompany.com> Message-ID: <7992d0d60708021547p1c4f9f6ah169f4b2a3cf2a8d3@mail.gmail.com> I've my own project files for VS2005 too and they work fine. Migration is not always easy but I need my own files also because I've added more build options (I have a build with settings specifically for profiling purposes). I haven't tried latest viewer source yet but I guess it should work just as well with some tweaking. Dirk aka Blakar Ogre On 8/3/07, Matt Kimmel wrote: > Hi Soft, > > A great starting place is VWR-1151; that JIRA issue contains VS2005 > project files that Nicholaz and I have put together for recent releases, > as well as some good notes about problems we (and others) have > encountered. That might provide the basis for the inclusion of updated > VS2005 project files in the open source viewer, at least. > > Others may chime in with their experiences, but most of the issues I've > encountered in using VS2005 builds have to do with subtle differences > between VS2003 and VS2005's STL implementations. I wrote up some notes > on a big one in VWR-1151. > > With that said, I've had pretty good luck running my own homegrown > VS2005 builds, using the fixed project files in that JIRA issue. I'd be > curious to hear other VS2005 users' thoughts. > > -Matt > > Soft Linden wrote: > > Dzonatas Sol brought up that VS2005 builds are unusuable during > > today's open source office hours. What's the scope of the breakage? > >>From comments, it sounded like there was more than just missing files > > in the project. > > > > While we're continuing to use VS2003 internally owing to using a > > monolithic solution file that includes old VS2003 library > > dependencies, I we can't commit to having someone building and running > > QA on 2005 yet. Still, is there anything we can do/include to simplify > > things if there are other manual repair and update steps you're > > taking? It would be great if updates were as simple as pulling down a > > community-updated VS2005 project file from a pJIRA. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Matt Kimmel, Software Alchemist > The Electric Sheep Company > ------------------------------------- > Email: mattk@electricsheepcompany.com > SL: Feep Larsson > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Thu Aug 2 15:56:01 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Aug 2 15:56:28 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <46B25B73.2000807@lindenlab.com> References: <46B25B73.2000807@lindenlab.com> Message-ID: <46B26101.4050102@wsu.edu> Anthony Foster wrote: > Hello everyone, > > It's been a while since I've done one of these, so let me know if I > miss anything. > > > SVN checkout: > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 > > Enjoy. > -Anthony > Does this URL work for anyone else? In branches/ I see: * .. * 2007/ * Branch_1-14-0/ * Branch_1-15-0/ * Branch_1-15-1/ * Branch_1-16-0/ * Branch_1-17-0/ * Branch_1-18-0/ * maintenance/ * release-candidate/ From robla at lindenlab.com Thu Aug 2 16:06:38 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Aug 2 16:06:46 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <46B26101.4050102@wsu.edu> References: <46B25B73.2000807@lindenlab.com> <46B26101.4050102@wsu.edu> Message-ID: <46B2637E.6030102@lindenlab.com> It will in a bit Sorry for falling out of sync here. Rob On 8/2/07 3:56 PM, John Hurliman wrote: > Anthony Foster wrote: >> Hello everyone, >> >> It's been a while since I've done one of these, so let me know if I >> miss anything. >> >> >> SVN checkout: >> http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 >> >> Enjoy. >> -Anthony >> > > Does this URL work for anyone else? In branches/ I see: > > * .. > * 2007/ > * Branch_1-14-0/ > > * Branch_1-15-0/ > > * Branch_1-15-1/ > > * Branch_1-16-0/ > > * Branch_1-17-0/ > > * Branch_1-18-0/ > > * maintenance/ > > * release-candidate/ > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070802/62259c32/signature.pgp From soft at lindenlab.com Thu Aug 2 16:06:51 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Aug 2 16:06:53 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <46B26101.4050102@wsu.edu> References: <46B25B73.2000807@lindenlab.com> <46B26101.4050102@wsu.edu> Message-ID: <9e6e5c9e0708021606r34992deat11291f504219bd63@mail.gmail.com> The branch isn't there, or isn't publicly accessible yet. Pinging on this - I suspect that URL got filled in in advance of the svn commit though. :) On 8/2/07, John Hurliman wrote: > Anthony Foster wrote: > > Hello everyone, > > > > It's been a while since I've done one of these, so let me know if I > > miss anything. > > > > > > SVN checkout: > > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 > > > > Enjoy. > > -Anthony > > > > Does this URL work for anyone else? In branches/ I see: > > * .. > * 2007/ > * Branch_1-14-0/ > > * Branch_1-15-0/ > > * Branch_1-15-1/ > > * Branch_1-16-0/ > > * Branch_1-17-0/ > > * Branch_1-18-0/ > > * maintenance/ > > * release-candidate/ > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Thu Aug 2 16:09:23 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Aug 2 16:09:25 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <9e6e5c9e0708021606r34992deat11291f504219bd63@mail.gmail.com> References: <46B25B73.2000807@lindenlab.com> <46B26101.4050102@wsu.edu> <9e6e5c9e0708021606r34992deat11291f504219bd63@mail.gmail.com> Message-ID: <9e6e5c9e0708021609m45c85f99v738ae46a3a67a987@mail.gmail.com> Rob's committing now. In case any don't know -- svn is atomic, so when the URL appears, it's done. No need to wait to be sure it's fully populated. On 8/2/07, Soft Linden wrote: > The branch isn't there, or isn't publicly accessible yet. Pinging on > this - I suspect that URL got filled in in advance of the svn commit > though. :) > > On 8/2/07, John Hurliman wrote: > > Anthony Foster wrote: > > > Hello everyone, > > > > > > It's been a while since I've done one of these, so let me know if I > > > miss anything. > > > > > > > > > SVN checkout: > > > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 > > > > > > Enjoy. > > > -Anthony > > > > > > > Does this URL work for anyone else? In branches/ I see: > > > > * .. > > * 2007/ > > * Branch_1-14-0/ > > > > * Branch_1-15-0/ > > > > * Branch_1-15-1/ > > > > * Branch_1-16-0/ > > > > * Branch_1-17-0/ > > > > * Branch_1-18-0/ > > > > * maintenance/ > > > > * release-candidate/ > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From robla at lindenlab.com Thu Aug 2 16:29:40 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Aug 2 16:31:02 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <46B25B73.2000807@lindenlab.com> References: <46B25B73.2000807@lindenlab.com> Message-ID: <46B268E4.9050804@lindenlab.com> This is now in svn.secondlife.com: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1/ revision 68 Rob On 8/2/07 3:32 PM, Anthony Foster wrote: > Hello everyone, > > It's been a while since I've done one of these, so let me know if I > miss anything. > > 1.18.1.2 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 > Release note information provided below. > Blog announcement: > http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ > > > Checksums: > > 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz > ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz > 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz > 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip > d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip > b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip > > > > SVN checkout: > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 > > Enjoy. > -Anthony > > > > > > Release Notes for Second Life 1.18.1(2) August 2, 2007 > ===================================== > > New Features: > * In-World Voice Chat > ** In-world Voice Chat is now part of the main viewer. > ** You can see and manage all voice settings in Edit > Preferences > > Voice Chat. > ** Voice is off by default. To enable (and disable) voice, visit Edit > > Preferences > Voice Chat and check/uncheck the box beside "Enable > voice chat". > ** A voice set-up wizard appears during first voice use to help > residents set up voice and adjust their mic volume and tuning. You > should run the voice set-up wizard even if you only want the ability > to hear others and do not wish to speak. > ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by > default, which means Resident mics are OFF by default. > ** Speech gestures for voice are included in the Library, in Gestures > > Speech Gestures. These gestures need to be activated in order to > work; they are off by default. > * Streaming video support for Linux client. > > Changes: > * Shortcut keys for menu items in the Client & Server menus are now > disabled if the menus are hidden. > * Text from objects can be muted. > > Bug fixes: > * VWR-1797: Remove mention of "Live Help" from Crash Logger > * VWR-1732: Pressing Enter, with multiple inventory objects selected, > crashes viewer > * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack > on Windows build > * VWR-1723: Possible crash in llvopartgroup > * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp > * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler > warning #4065 for 'switch' statements > * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry > * VWR-1698: Clean up parcel flag manipulation > * VWR-1655: Script Warnings/errors window is hard to resize, resets > size after closing tabs. > * VWR-1646: Possible crash when login server is unavailable. > * VWR-1626: Patch to avoid IM window from resizing when sessions open > or close > * VWR-1613: Overuse of virtual > * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats > tuning > * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp > * VWR-1578: Two quirks in IM regarding "xxxx is typing" > * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing > on first use when "only select own objects" is enabled > * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are > disabled when opening friends list window > * VWR-1468: LoginPacketNeverReceived dialog text is incorrect > * VWR-1462: Order of right-click menu on Inventory is confusing > * VWR-1453: A few old-school changes for llviewerregion.cpp > * VWR-1434: Null pointer crash when terraforming > * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 > * VWR-1382: Some scripted objects are highlighted in red while > pressing Alt with tools open > * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build > fails. > * VWR-1358: Physical objects remain red if tools window is closed > while holding Alt key > * VWR-1358: Physical objects remain red if tools window is closed > while holding Alt key > * VWR-1353: Misleading variable names in LLTextEditor > * VWR-1344: Reverse order of popups, so that new ones appear > underneath existing ones rather than on top. > * VWR-1318: Selecting Cancel while saving a snapshot to disk still > triggers snapshot gesture > * VWR-1314: Multiple selection then individual deselection of > attachments broken > * VWR-1294: Possibly threads not fully cleaned up at end of program > * VWR-1289: On logging in, sound volume for stream is low, despite the > actual setting in the music control > * VWR-1282: Better error handling when fonts are missing > * VWR-1270: Script error window keeps reverting to a very small size > * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key > * VWR-1105: Set internal limit of particle count to max value from GUI > preferences. > * VWR-1092: Disable mouse hover text on HUDs, since it always only > shows the owner's name and generally gets in the way of HUD > functionality. > * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: > ... resizeable and minimizable) > * VWR-447: Allow minimized windows to be repositioned in client > * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu > * VWR-349: Change keyboard shortcuts, because entering { [ ] } on > German and some other international keyboards (AltGr 7, 8, 9, 0) > triggers Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 > (previously resulting in unstable viewer) > * VWR-238: Permissions of Roles and Rights in the german version are > mased up. > * VWR-102: md5 slow > * SVC-371: Fix the legibility and grammar/consistency of the new > llOwnerSay implementation > * SVC-193: llParticleSystem - halo of rogue particles around original > particle system after 1.15 update* SVC-373: Deleting a script's code > results in a non-existent file and "missing from database" error > * Fixed preference for showing or hiding server combo box was not > preserved > * Fixed residents with negative L$ balance can't purchase items set > for sale "Original" or "Copy" that are being sold for L$0 > * "Copy SLURL to clipboard" is now enabled for an avatar's current > coordinates > * Macintosh viewer now correctly opens the map and selects the > destination on a SLURL request > * Leading and trailing spaces are now automatically trimmed from > parcel media URLs > * Corrected the spacing of the yellow "next dialog" chevron (was > partially blocked by the Mute button) > * Corrected the error message shown when adding 11th Estate Manager > * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo > * "Set Window Size..." setting is now correctly resumed after being > minimized > * Added link to Qa wiki in the viewer bug reporter menu. > * Updated text in Second Life Crash Logger with new support portal > information > * Corrected an issue with UI font scaling in the bug reporter window > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070802/cfcd4b43/signature-0001.pgp From sl at phoca.com Thu Aug 2 17:48:44 2007 From: sl at phoca.com (Second Life) Date: Thu Aug 2 17:49:03 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: <46B25B73.2000807@lindenlab.com> References: <46B25B73.2000807@lindenlab.com> Message-ID: <205B4A63D2844BBB89E05ED8C7513943@SanMiguel> I don't remember seeing any warning of an public release of voice today. That pretty much kills any chance of fixing the worst problems of the chatter box :( Is it time to start talking about an alternative UI for real SL users? Besides unbreaking the chatterbox there was always HUGE room for improvement of the SL UI and chat features such as customizable syntax/user highlighting etc. Is it time for me to write "Phoca for SL"? Anyone interested in what that might entail? :( Farallon ----- Original Message ----- From: "Anthony Foster" To: Sent: Thursday, August 02, 2007 3:32 PM Subject: [sldev] Source release for 1.18.1.2 > Hello everyone, > > It's been a while since I've done one of these, so let me know if I miss > anything. > > 1.18.1.2 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 > Release note information provided below. > Blog announcement: > http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ > > Checksums: > > 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz > ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz > 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz > 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip > d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip > b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip > > > > SVN checkout: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 > at r67242 > > Enjoy. > -Anthony > > > > > > Release Notes for Second Life 1.18.1(2) August 2, 2007 > ===================================== > > New Features: > * In-World Voice Chat > ** In-world Voice Chat is now part of the main viewer. > ** You can see and manage all voice settings in Edit > Preferences > Voice > Chat. > ** Voice is off by default. To enable (and disable) voice, visit Edit > > Preferences > Voice Chat and check/uncheck the box beside "Enable voice > chat". > ** A voice set-up wizard appears during first voice use to help residents > set up voice and adjust their mic volume and tuning. You should run the > voice set-up wizard even if you only want the ability to hear others and > do not wish to speak. > ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by > default, which means Resident mics are OFF by default. > ** Speech gestures for voice are included in the Library, in Gestures > > Speech Gestures. These gestures need to be activated in order to work; > they are off by default. > * Streaming video support for Linux client. > > Changes: > * Shortcut keys for menu items in the Client & Server menus are now > disabled if the menus are hidden. > * Text from objects can be muted. > > Bug fixes: > * VWR-1797: Remove mention of "Live Help" from Crash Logger > * VWR-1732: Pressing Enter, with multiple inventory objects selected, > crashes viewer > * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack on > Windows build > * VWR-1723: Possible crash in llvopartgroup > * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp > * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler > warning #4065 for 'switch' statements > * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry > * VWR-1698: Clean up parcel flag manipulation > * VWR-1655: Script Warnings/errors window is hard to resize, resets size > after closing tabs. > * VWR-1646: Possible crash when login server is unavailable. > * VWR-1626: Patch to avoid IM window from resizing when sessions open or > close > * VWR-1613: Overuse of virtual > * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats > tuning > * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp > * VWR-1578: Two quirks in IM regarding "xxxx is typing" > * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing on > first use when "only select own objects" is enabled > * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are > disabled when opening friends list window > * VWR-1468: LoginPacketNeverReceived dialog text is incorrect > * VWR-1462: Order of right-click menu on Inventory is confusing > * VWR-1453: A few old-school changes for llviewerregion.cpp > * VWR-1434: Null pointer crash when terraforming > * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 > * VWR-1382: Some scripted objects are highlighted in red while pressing > Alt with tools open > * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build fails. > * VWR-1358: Physical objects remain red if tools window is closed while > holding Alt key > * VWR-1358: Physical objects remain red if tools window is closed while > holding Alt key > * VWR-1353: Misleading variable names in LLTextEditor > * VWR-1344: Reverse order of popups, so that new ones appear underneath > existing ones rather than on top. > * VWR-1318: Selecting Cancel while saving a snapshot to disk still > triggers snapshot gesture > * VWR-1314: Multiple selection then individual deselection of attachments > broken > * VWR-1294: Possibly threads not fully cleaned up at end of program > * VWR-1289: On logging in, sound volume for stream is low, despite the > actual setting in the music control > * VWR-1282: Better error handling when fonts are missing > * VWR-1270: Script error window keeps reverting to a very small size > * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key > * VWR-1105: Set internal limit of particle count to max value from GUI > preferences. > * VWR-1092: Disable mouse hover text on HUDs, since it always only shows > the owner's name and generally gets in the way of HUD functionality. > * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: ... > resizeable and minimizable) > * VWR-447: Allow minimized windows to be repositioned in client > * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu > * VWR-349: Change keyboard shortcuts, because entering { [ ] } on German > and some other international keyboards (AltGr 7, 8, 9, 0) triggers > Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 (previously resulting > in unstable viewer) > * VWR-238: Permissions of Roles and Rights in the german version are mased > up. > * VWR-102: md5 slow > * SVC-371: Fix the legibility and grammar/consistency of the new > llOwnerSay implementation > * SVC-193: llParticleSystem - halo of rogue particles around original > particle system after 1.15 update* SVC-373: Deleting a script's code > results in a non-existent file and "missing from database" error > * Fixed preference for showing or hiding server combo box was not > preserved > * Fixed residents with negative L$ balance can't purchase items set for > sale "Original" or "Copy" that are being sold for L$0 > * "Copy SLURL to clipboard" is now enabled for an avatar's current > coordinates > * Macintosh viewer now correctly opens the map and selects the destination > on a SLURL request > * Leading and trailing spaces are now automatically trimmed from parcel > media URLs > * Corrected the spacing of the yellow "next dialog" chevron (was partially > blocked by the Mute button) > * Corrected the error message shown when adding 11th Estate Manager > * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo > * "Set Window Size..." setting is now correctly resumed after being > minimized > * Added link to Qa wiki in the viewer bug reporter menu. > * Updated text in Second Life Crash Logger with new support portal > information > * Corrected an issue with UI font scaling in the bug reporter window > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Thu Aug 2 17:51:05 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 17:49:56 2007 Subject: [sldev] Improving VS2005 builds -- what's needed? In-Reply-To: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> References: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> Message-ID: <46B27BF9.7030605@dzonux.net> Soft Linden wrote: > Dzonatas Sol brought up that VS2005 builds are unusuable during > today's open source office hours. VS2005 builds of the current source release are not fully usable. Such product is not practically usable. It can be used, but that is about it. You can build from project files posted on jira, but that only builds the viewer and not all the libraries. If you mix VS2003 built libraries with a VS2005 built viewer, you will find errors. Try to run 1.18.0.6.OS.3 as found on OSLCC and you will find an error with llviewersse2.dll that won't allow SL to start on Vista. In contrary to your SLDev wiki: https://wiki.secondlife.com/wiki/SLDev-Traffic_21#OpenAL_Patch_-_Windows_Testing_Wanted ... the problem is STL and STDC under MSVS, not FMOD or other such. It's the freakin' compiler that is the problem. Microsoft is well aware of the pain they caused: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Open_Source_Libraries The 1.18.0.6.OS.3 *CLEANY* exploits the problem on Vista. The llviersersse2.dll links in in find and starts just fine. The optimization code works perfectly. However, as soon as an API call is made that uses STL, Microsoft's code says "[Hey... we aren't going to let you do this.. click here to end this application]" It isn't even a crash with a unknown cause... its a freak'n compliancy check built-in! > While we're continuing to use VS2003 internally owing to using a > monolithic solution file that includes old VS2003 library > dependencies, I we can't commit to having someone building and running > QA on 2005 yet. That is exactly why this "unusable" issue has gone ignored. LL employees can not say they completely do not understand this when it is plainly obvious that LL employees have said libraries like Havok depend on VS2003. That essentially states it is well known the reason why there has been no move to VS2005. That essentially further claims that LL employee do know that people who attempt to build the viewer with MSVS besides VS2003 will have problems that LL claims they won't support ("due to dependencies"). >It would be great if updates were as simple as pulling down a community-updated VS2005 project file from a pJIRA. I've already started that here: http://oslcc.svn.sourceforge.net/svnroot/oslcc/sandbox/branches/os/trunk In that repository exists SConstruct and *.sconscript files to build the viewer under unix-like and under VS2005. For VS2005, it builds everything... including all the libraries. If you don't have the source, it downloads them. Best thing about that script, it even exploits how the viewer should not link to STDC. One thing to point out, STDC is safer on Linux (with glibc and etc), but under Microsoft... it is a nightmare of security concerns. With the study on this, I can tell you that the makers of glibc make it so that their libraries are harder to link to out of security reasons than because they want to be GPL greedy. Microsoft has obviously finally realized this and said.. "[OOPS! Well will just do a client-side update and the enforce the legalities of linking code with a compliancy check!]" > Still, is there anything we can do/include to simplify > things if there are other manual repair and update steps you're > taking? Lindens rejoiced at dia de la liberacion, but then what has been liberated? The viewer dependency build against the server? Obviously it has not been liberated one bit when LL has to ask open source devs (whom LL has push on the street or turned down employment) how to liberate their code. Think of that business like instead of some tizzy fit and see the reality of what I'm saying. I pointed out a start in the scons above. It is a start. If I attribute that idea to anybody... the credit goes to Rob Linden as he is the one who subtly encouraged me to create those scons scripts. It freak'n wasted a lot of my time to test them, however. I've fucking saved that LL that time. Don't get me any of the crap that it costs LL devs their time unless you want to now officially recognize me as an LL software developer! Second... split the server build to VS2003 and exclude the viewer from the VS2003 so that it is mandatory to build the viewer under VS2005. You'll find a hell hole of security issues as can be found in the revision 98 checkin of http://oslcc.svn.sourceforge.net/svnroot/oslcc/sandbox/branches/os/trunk Cheers! -- Power to Change the Void From gigstaggart at gmail.com Thu Aug 2 17:50:52 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 2 17:50:38 2007 Subject: [sldev] Openjpeg bug Message-ID: <46B27BEC.4060101@gmail.com> Does anyone know if this OpenJPEG bug is already addressed in one of the patches I likely do not have? *** glibc detected *** bin/do-not-directly-run-secondlife-bin: double free or corruption (fasttop): 0x0c4ee640 *** ======= Backtrace: ========= /lib/tls/i686/cmov/libc.so.6[0xb72fad35] /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb72fe7d0] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb74c2d81] /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0xb749e90d] /usr/lib/libstdc++.so.6(_ZNSs6assignERKSs+0xa6)[0xb74a0106] /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN11LLImageBase12allocateDataEi+0x6d)[0xb7ef5b9f] /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN10LLImageRaw12allocateDataEi+0x29)[0xb7ef601b] /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN11LLImageBase16allocateDataSizeEiiii+0x46)[0xb7ef2864] /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN10LLImageRawC1Etta+0x6a)[0xb7ef29fa] Google says this usually is caused by a bad (or nonexisting) copy constructor that causes a double free. From sl at phoca.com Thu Aug 2 17:58:02 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Thu Aug 2 17:58:16 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: <46B27C3D.4030802@gmail.com> References: <46B25B73.2000807@lindenlab.com> <205B4A63D2844BBB89E05ED8C7513943@SanMiguel> <46B27C3D.4030802@gmail.com> Message-ID: Optional or not it'll bug every SL user every time they launch to upgrade which means the adoption rate will be swift and large and THEN making changes becomes 10x harder. And.. heh ok, changed the account name Farallon ----- Original Message ----- From: "Jason Giglio" To: "Second Life" Sent: Thursday, August 02, 2007 5:52 PM Subject: Re: [sldev] Uh... what was with the sudden voice release? > Second Life wrote: >> I don't remember seeing any warning of an public release of voice today. > > It's optional. > > On a personal note, could you put some kind of name in your email client > for mail to this list, so you don't just show up as "Second Life"? :) > > Doesn't have to be your real name, just something. > > -Jason From dzonatas at dzonux.net Thu Aug 2 18:05:54 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 18:04:46 2007 Subject: [sldev] Improving VS2005 builds -- what's needed? In-Reply-To: <46B27BF9.7030605@dzonux.net> References: <9e6e5c9e0708021523v5aa4aa99td21821a301fabbde@mail.gmail.com> <46B27BF9.7030605@dzonux.net> Message-ID: <46B27F72.3050202@dzonux.net> Dzonatas wrote: > It isn't even a crash with a unknown cause... its a freak'n compliancy > check built-in! Forgot to mention.... this is like Microsoft trying to politely say... your software is not legit on how you want it to link. In the words of Liana, "AAAaaargggh" -- Power to Change the Void From dzonatas at dzonux.net Thu Aug 2 18:08:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 18:07:42 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B24156.6030705@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B20738.9080508@lindenlab.com> <46B217C4.2000606@cox.net> <46B24156.6030705@cox.net> Message-ID: <46B28023.1070406@dzonux.net> Lawson English wrote: > OK, the only real reason I can see to release a mono interpreter on > the client-side is if they're planning on letting the clients host > their own mini-sims, ala Croquet. That would be cool but is rather far > off. > Lawson, your idea to use scripts to run in the build process for QA test plans is freak'n awesome! -- Power to Change the Void From lenglish5 at cox.net Thu Aug 2 19:27:52 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:27:55 2007 Subject: [sldev] Scripting the client In-Reply-To: References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> Message-ID: <46B292A8.3060509@cox.net> Argent Stonecutter wrote: > Lawson English: >> Is there a design team or thread for how to add scripting to the client, >> ala Lua and/or Python and/or Perl etc? >> >> What should be scriptable by such an interface? How it should >> accomidate/facilitate plug-ins? >> >> And so on and so on and so forth? >> >> *Etcetera, etcetera, etcetera... --spoken with best royal Yul Brynner >> accent > > There's several different things that people might be looking for in > scripting the client, and they probably don't have the same solution. > > 1. More control over the client from LSL, this includes things like > HTML notecards, improved dialogs (including notecard-driven HTML > dialogs, my favorite), as well as communication between LSL and local > executing programs and pushing scripts into the client from LSL. > > 2. More control over the client from local software, plugins, and so on. > > 3. Extending the user interface with scripted extensions to the XML > user interface, similar to Firefox extensions, Konfabulator or > Dashboard widgets, and so on. > > I think that the first section should be severely limited in scope, > for security reasons, and a separate extension from the other two. The > same language and interpreter could be used (and there's already a > Javascript interpreter in the client from Gecko), but there should be > a separate instance of it that doesn't have access to any extensions > available to locally installed software. Best would be to make it > something like "Safe Tcl", where the symbol table available to the > untrusted interpreter doesn't even provide entry points for any > routine that isn't either fully internal (like math functions) or > restricted to only allow safe operations. > The ultimate scripted client would be something like the WoW solution. That's the main reason I would say to use Lua: it's quick and easy to do and we know it works, at least at this level. Any scripting language, including one based o mono, would do just as well, of course: http://www.wowwiki.com/World_of_Warcraft_API The level of GUI control you're looking for should approach (or exceed) this: http://www.wowwiki.com/Widget_API Security issues exist in all aspects of this thing. HUDs should be able to use existing GUI widgits, but only as graphical devices that send I/O back to the world via LSL, not as things that can interact directly with the client API. My solution to import/export chat and IM in and out of Croquet is trival on its face (someone from IBM wrote an external language interpreter for the client and I'm copying their solultion) but if you let just *any* application have access to IM via a plug-in, you run the risk of rebroadcasting private IM on an open channel. I may have to get around this in Croquet by not letting external chat/IM enter the Croquet world at all, since the normal model is to broadcast a copy of ALL objects to every participant in a Croquet world. I'm a nice guy and don't want IMs to get passed around, but exposing chat/IM to inport/export would allow trivial plugins to be written to do exactly what private IM is supposed to prevent. It would also allow REAL translation solutions, far better than Babbler. So should it be included in the plug-in API or not? From gigstaggart at gmail.com Thu Aug 2 19:31:03 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 2 19:30:48 2007 Subject: [sldev] Wow! Message-ID: <46B29367.3050807@gmail.com> Hey did everyone notice, the blog says "Voice is open source". Good going getting Vivox to release their source code! The MOTD also says "SL is fully voice enabled". That must mean Linux support is done! I'm compiling that 1.18.1.2 Linux client that has voice now! From lenglish5 at cox.net Thu Aug 2 19:33:52 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:33:54 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> Message-ID: <46B29410.7070103@cox.net> Argent Stonecutter wrote: > Lawson English: >> You said on the forums that you were working on a Python plug-in. Why >> specifically Python, rather than Lua, given the relative simplicity of >> implementing Lua as a plug-in scripting language (that is what it is >> designed for) compared to implementing a Python plug-in, and the fact >> that Lua is already used as the scripting language for the Worlds of >> Warcraft client and has a proven track record for scripting such a >> system? > > The language I would rather see would be Tcl. It was designed from the > start as a glue language, has been ported widely (and even to as > limited environments as the old Palm III), and has standard mechanisms > (Safe Tcl) for creating restricted interpreters that *can not* be > broken out of because it creates fully sandboxed interpreters that do > not even have unsafe APIs exposed through them. Another option, of course. Best would be something that would allow complete flexability in choice of language, of course. > > Failing that, it should be possible to create similarly sandboxed > ECMAscript interpreters, and the client already supports Javascript > and there is an extensive base of developers experienced in both > Javascript and Actionscript. Is there an opensource drop-in library for ECMAscript? The fact that there is an interpreter in the browser doesn't mean it would be easy to use it for a non-web-based purpose, I would think. > > I do not think we should trust Microsoft's partial sandbox design: for > the last decade the same high level security model as implemented in > IE and ActiveX has been broken again and again by exploiting *design > flaws* that are inherent to the whole "security zone" model. From lenglish5 at cox.net Thu Aug 2 19:35:23 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:35:25 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <46B25217.10702@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B25217.10702@gmail.com> Message-ID: <46B2946B.5050208@cox.net> Jason Giglio wrote: > Argent Stonecutter wrote: >> Failing that, it should be possible to create similarly sandboxed >> ECMAscript interpreters, and the client already supports Javascript and > > Something to ponder, SVG can fully support ECMAScript, killing like > 100 birds with one stone. :) > > SVG-on-a-prim just makes sense. I like SVG-on-a-prim as a way of allowing more elaborate text and graphics in-world, but anything that allows web access runs into the same server limitations as html-on-prim. From lenglish5 at cox.net Thu Aug 2 19:39:17 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:39:19 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B28023.1070406@dzonux.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B20738.9080508@lindenlab.com> <46B217C4.2000606@cox.net> <46B24156.6030705@cox.net> <46B28023.1070406@dzonux.net> Message-ID: <46B29555.6000405@cox.net> Dzonatas wrote: > Lawson English wrote: >> OK, the only real reason I can see to release a mono interpreter on >> the client-side is if they're planning on letting the clients host >> their own mini-sims, ala Croquet. That would be cool but is rather >> far off. >> > > > Lawson, your idea to use scripts to run in the build process for QA > test plans is freak'n awesome! > > Er, it is? I was thinking more along the line of LL using scriptable avatars and other scripted client-side activities to test things further along in the process. From lenglish5 at cox.net Thu Aug 2 19:42:59 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:43:05 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: <205B4A63D2844BBB89E05ED8C7513943@SanMiguel> References: <46B25B73.2000807@lindenlab.com> <205B4A63D2844BBB89E05ED8C7513943@SanMiguel> Message-ID: <46B29633.4060901@cox.net> Second Life wrote: > I don't remember seeing any warning of an public release of voice today. > > That pretty much kills any chance of fixing the worst problems of the > chatter box :( > > Is it time to start talking about an alternative UI for real SL users? > > Besides unbreaking the chatterbox there was always HUGE room for > improvement of the SL UI and chat features such as customizable > syntax/user highlighting etc. > > Is it time for me to write "Phoca for SL"? Anyone interested in what > that might entail? > :( > > Farallon The roadmap said that Voice was to be released yesterday. Obviously, the troubles over the weekend pushed its release back until today. Which leads one to wonder: why not wait until next Wendesday for this, since everyone is used to "patch Wednesday." Is something really spiffy being released on Wednesday that they don't want to delay? Next week's meeting at Zero's is about mono. Hmmmm... From secret.argent at gmail.com Thu Aug 2 19:45:51 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 2 19:45:30 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B292A8.3060509@cox.net> References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> <46B292A8.3060509@cox.net> Message-ID: <8699E486-A070-476A-8C0D-2DF02C0ED78D@gmail.com> Lawson English: > The ultimate scripted client would be something like the WoW > solution. That's the main reason I would say to use Lua: it's > quick and easy to do and we know it works, at least at this level. We ALSO know that Javascript works at this level (everything from Konfabulator and Dashboard widgets to AJAX), it's already in the client, and we know it can be secured. I prefer Tcl. You prefer Lua. But Javascript is already there. > If you let just *any* application have access to IM via a plug-in, > you run the risk of rebroadcasting private IM on an open channel. You let the user request it. Not the application, the user. In a preference option, "let these plugins access IM", with a list of plugins that have been made visible to the client, and a checkbox for each one. From secret.argent at gmail.com Thu Aug 2 19:49:22 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 2 19:49:00 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <46B29410.7070103@cox.net> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B29410.7070103@cox.net> Message-ID: <58F13EAA-D966-427C-A19B-55B34CDED04A@gmail.com> On 02-Aug-2007, at 21:33, Lawson English wrote: > Is there an opensource drop-in library for ECMAscript? The fact > that there is an interpreter in the browser doesn't mean it would > be easy to use it for a non-web-based purpose, I would think. "SpiderMonkey is Gecko's JavaScript engine written in C. It is used in various Mozilla products, including Firefox, and is available under MPL/GPL/LGPL tri-license." And "JavaScript C Engine Embedder's Guide This guide provides an overview of SpiderMonkey and describes how you can embed engine calls in your applications to make them JavaScript- aware." http://developer.mozilla.org/en/docs/SpiderMonkey From lenglish5 at cox.net Thu Aug 2 19:52:05 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:52:06 2007 Subject: [sldev] Scripting the client In-Reply-To: <8699E486-A070-476A-8C0D-2DF02C0ED78D@gmail.com> References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> <46B292A8.3060509@cox.net> <8699E486-A070-476A-8C0D-2DF02C0ED78D@gmail.com> Message-ID: <46B29855.8060707@cox.net> Argent Stonecutter wrote: > Lawson English: >> The ultimate scripted client would be something like the WoW >> solution. That's the main reason I would say to use Lua: it's quick >> and easy to do and we know it works, at least at this level. > > We ALSO know that Javascript works at this level (everything from > Konfabulator and Dashboard widgets to AJAX), it's already in the > client, and we know it can be secured. I prefer Tcl. You prefer Lua. > But Javascript is already there. > I don't "prefer" Lua. I've never used it. I just assumed it was easy to implement as a drop-in scripting language since it was designed that way. I'm still not sure that JavaScript's presence in the browser qualifies JavaScript as an easy solution to client-level scripting. /shrug. >> If you let just *any* application have access to IM via a plug-in, >> you run the risk of rebroadcasting private IM on an open channel. > > You let the user request it. Not the application, the user. In a > preference option, "let these plugins access IM", with a list of > plugins that have been made visible to the client, and a checkbox for > each one. Most users are trustworthy. I'm just worried that there will be a class of griefers who are not technical savvy enough to compile the viewer with a couple of extra lines of code to export private IM to a rebroadcaster who ARE technical enough to drop in a plug-in that does it for them with a click of a button. Likewise with many other possible plug-ins that could be created. /shrug. It's a a tradeoff. Are the benefits worth the downside of exposing private IM to such trivial solutions for rebroadcast? Likewise with everything else that could be abused via the plug-ins. From lenglish5 at cox.net Thu Aug 2 19:53:16 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:53:18 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: <46B29633.4060901@cox.net> References: <46B25B73.2000807@lindenlab.com> <205B4A63D2844BBB89E05ED8C7513943@SanMiguel> <46B29633.4060901@cox.net> Message-ID: <46B2989C.2080309@cox.net> Lawson English wrote: > Second Life wrote: >> I don't remember seeing any warning of an public release of voice today. >> >> That pretty much kills any chance of fixing the worst problems of >> the chatter box :( >> >> Is it time to start talking about an alternative UI for real SL users? >> >> Besides unbreaking the chatterbox there was always HUGE room for >> improvement of the SL UI and chat features such as customizable >> syntax/user highlighting etc. >> >> Is it time for me to write "Phoca for SL"? Anyone interested in what >> that might entail? >> :( >> >> Farallon > The roadmap said that Voice was to be released yesterday. Obviously, > the troubles over the weekend pushed its release back until today. > > > Which leads one to wonder: why not wait until next Wendesday for this, > since everyone is used to "patch Wednesday." Is something really > spiffy being released on Wednesday that they don't want to delay? Next > week's meeting at Zero's is about mono. > > > Hmmmm... Eh, nothing so earth-shattering. The new First Look will be a revised Windlight FL. From lenglish5 at cox.net Thu Aug 2 19:54:15 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 19:54:17 2007 Subject: [sldev] Re: Scripting the client In-Reply-To: <58F13EAA-D966-427C-A19B-55B34CDED04A@gmail.com> References: <20070802153130.A403041B0C2@stupor.lindenlab.com> <0ED37CF8-604E-4CFB-AB33-8D760C4CFF86@gmail.com> <46B29410.7070103@cox.net> <58F13EAA-D966-427C-A19B-55B34CDED04A@gmail.com> Message-ID: <46B298D7.7030001@cox.net> Argent Stonecutter wrote: > On 02-Aug-2007, at 21:33, Lawson English wrote: >> Is there an opensource drop-in library for ECMAscript? The fact that >> there is an interpreter in the browser doesn't mean it would be easy >> to use it for a non-web-based purpose, I would think. > > "SpiderMonkey is Gecko's JavaScript engine written in C. It is used in > various Mozilla products, including Firefox, and is available under > MPL/GPL/LGPL tri-license." > > And > > "JavaScript C Engine Embedder's Guide > This guide provides an overview of SpiderMonkey and describes how you > can embed engine calls in your applications to make them > JavaScript-aware." > OK, that satisfies that issue quite nicely, thanks. From gigstaggart at gmail.com Thu Aug 2 20:45:31 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 2 20:45:16 2007 Subject: [sldev] Voice problem, 401 Unauthorized. Message-ID: <46B2A4DB.3020105@gmail.com> Can't get voice working on my wife's computer, this 401 Unauthorized error seems to be the problem: INFO: LLVoiceClient::loginResponse: Account.Login response (401): Unauthorized INFO: LLVoiceClient::loginResponse: Account.Login response failure (401): Unauthorized Any Ideas? Full Log: 2007-08-03T03:39:48Z INFO: LLVoiceClient::setState: entering state stateStart 2007-08-03T03:39:48Z INFO: LLVoiceClient::setState: entering state stateDaemonLaunched 2007-08-03T03:39:49Z WARNING: ll_apr_warn_status: APR: Invalid argument 2007-08-03T03:39:49Z WARNING: ll_apr_warn_status: APR: Invalid argument 2007-08-03T03:39:49Z WARNING: ll_apr_warn_status: APR: Invalid argument 2007-08-03T03:39:49Z WARNING: ll_apr_warn_status: APR: Invalid argument 2007-08-03T03:39:49Z INFO: LLVoiceClient::setState: entering state stateConnecting 2007-08-03T03:39:49Z INFO: LLVoiceClient::setState: entering state stateIdle 2007-08-03T03:39:49Z INFO: LLVoiceClient::setState: entering state stateConnectorStart 2007-08-03T03:39:49Z INFO: LLVoiceClient::setState: entering state stateConnectorStarting 2007-08-03T03:39:49Z INFO: LLVoiceClient::clearCaptureDevices: called 2007-08-03T03:39:49Z INFO: LLVoiceClient::addCaptureDevice: Realtek AC97 Audio 2007-08-03T03:39:49Z INFO: LLVoiceClient::addCaptureDevice: Logitech Microphone (Pro 5000) 2007-08-03T03:39:49Z INFO: LLVoiceClient::clearRenderDevices: called 2007-08-03T03:39:49Z INFO: LLVoiceClient::addRenderDevice: Realtek AC97 Audio 2007-08-03T03:39:53Z INFO: LLVoiceClient::setState: entering state stateConnectorStarted 2007-08-03T03:39:53Z INFO: LLVoiceClient::setState: entering state stateNeedsLogin 2007-08-03T03:39:54Z INFO: `anonymous-namespace'::LLEventPollResponder::result: LLEventPollResponder::completed <1> 1events (id 143 ) 2007-08-03T03:39:54Z INFO: LLVoiceClient::setState: entering state stateLoggingIn 2007-08-03T03:39:55Z INFO: LLVoiceClient::loginResponse: Account.Login response (401): Unauthorized 2007-08-03T03:39:55Z INFO: LLVoiceClient::loginResponse: Account.Login response failure (401): Unauthorized 2007-08-03T03:39:55Z INFO: LLVoiceClient::setState: entering state stateLoginRetry 2007-08-03T03:39:55Z INFO: LLVoiceClient::notifyStatusObservers: UNKNOWN, session URI 2007-08-03T03:39:55Z INFO: LLVoiceClient::stateMachine: will retry login in 10 seconds. 2007-08-03T03:39:55Z INFO: LLVoiceClient::setState: entering state stateLoginRetryWait 2007-08-03T03:40:05Z INFO: LLVoiceClient::setState: entering state stateNeedsLogin 2007-08-03T03:40:05Z INFO: LLVoiceClient::setState: entering state stateLoggingIn From dzonatas at dzonux.net Thu Aug 2 20:55:00 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Aug 2 20:53:52 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B29555.6000405@cox.net> References: <46AB4C2B.9040305@blueflash.cc> <9e6e5c9e0707311757r6b61727ay4f8a3b7d96d91606@mail.gmail.com> <1185944953.18603.47.camel@localhost> <46B027D1.4030608@ucsd.edu> <9e6e5c9e0708011228i6dd68406n600a0ed5195d2659@mail.gmail.com> <46B10F42.4000904@ucsd.edu> <46B13402.4030804@cox.net> <46B20738.9080508@lindenlab.com> <46B217C4.2000606@cox.net> <46B24156.6030705@cox.net> <46B28023.1070406@dzonux.net> <46B29555.6000405@cox.net> Message-ID: <46B2A714.6050402@dzonux.net> Lawson English wrote: >> > Er, it is? I was thinking more along the line of LL using scriptable > avatars and other scripted client-side activities to test things > further along in the process. > > Exactly. I'm sure that idea will dependently need automation from the start. A build request includes the scripts to test the new features as soon as the build is done. Is there a reason why testing, as you describe, should wait after a build is done? Essentially, there is a lot of the build and QA phases that can be automated together. I believe your idea combined with some of the work I've done will help LL get passed an oversighted legal blunder. (blooper?) We LL won't like it at first for the tediousness. Pardon my earlier rap. It's one of my silly ways of showing security issues without giving away the answer. (If that hasn't been predictable by now!) Just think as the idea evolves. Someone in-world could request support assistance, and then a scripted avatar (or bot) teleports-in and helps them. The bot itself becomes kinda-sorta a new "UI" to SL. It could do anything from walkthroughs to control a sim that the person requested support on to showing someone how to put on an attachment. Even better yet, someone reports abuse and the bot independently records video on the scene (!!!). It can't be any more tedious then... teaching a baby to walk. Just one's own real life baby is more enjoyable to teach. -- Power to Change the Void From jhurliman at wsu.edu Thu Aug 2 21:14:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Aug 2 21:14:56 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B29855.8060707@cox.net> References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> <46B292A8.3060509@cox.net> <8699E486-A070-476A-8C0D-2DF02C0ED78D@gmail.com> <46B29855.8060707@cox.net> Message-ID: <46B2ABAA.9040805@wsu.edu> Lawson English wrote: > > Most users are trustworthy. I'm just worried that there will be a > class of griefers who are not technical savvy enough to compile the > viewer with a couple of extra lines of code to export private IM to a > rebroadcaster who ARE technical enough to drop in a plug-in that does > it for them with a click of a button. > That class of griefers just asks their friends who have commit access to ShoopedLife to add the features they want; I think this is a bit of a strawman argument. John Hurliman From lenglish5 at cox.net Thu Aug 2 22:34:17 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 2 22:34:18 2007 Subject: [sldev] Scripting the client In-Reply-To: <46B2ABAA.9040805@wsu.edu> References: <20070802053031.039DD41B0A8@stupor.lindenlab.com> <46B292A8.3060509@cox.net> <8699E486-A070-476A-8C0D-2DF02C0ED78D@gmail.com> <46B29855.8060707@cox.net> <46B2ABAA.9040805@wsu.edu> Message-ID: <46B2BE59.3010202@cox.net> John Hurliman wrote: > Lawson English wrote: >> >> Most users are trustworthy. I'm just worried that there will be a >> class of griefers who are not technical savvy enough to compile the >> viewer with a couple of extra lines of code to export private IM to a >> rebroadcaster who ARE technical enough to drop in a plug-in that does >> it for them with a click of a button. >> > > That class of griefers just asks their friends who have commit access > to ShoopedLife to add the features they want; I think this is a bit of > a strawman argument. Didn't mean it to be. It's something I've had to consider when working on the Croquet IM thing. The base object for Croquet is a TeaTime object which distribtues a clone of itself to every client. That kinda destroys the whole concept of private IM. A non-TObject is a relatively poorly supported afterthought in Croquet, currently, so I may have to just make IM a separate Smalltalk text window outside the Croquet view. From seg at haxxed.com Thu Aug 2 22:39:48 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Aug 2 22:40:04 2007 Subject: [sldev] Openjpeg bug In-Reply-To: <46B27BEC.4060101@gmail.com> References: <46B27BEC.4060101@gmail.com> Message-ID: <1186119588.6750.16.camel@localhost> On Thu, 2007-08-02 at 20:50 -0400, Jason Giglio wrote: > Does anyone know if this OpenJPEG bug is already addressed in one of the > patches I likely do not have? > > > *** glibc detected *** bin/do-not-directly-run-secondlife-bin: double > free or corruption (fasttop): 0x0c4ee640 *** > ======= Backtrace: ========= > /lib/tls/i686/cmov/libc.so.6[0xb72fad35] > /lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb72fe7d0] > /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb74c2d81] > /usr/lib/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1d)[0xb749e90d] > /usr/lib/libstdc++.so.6(_ZNSs6assignERKSs+0xa6)[0xb74a0106] > /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN11LLImageBase12allocateDataEi+0x6d)[0xb7ef5b9f] > /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN10LLImageRaw12allocateDataEi+0x29)[0xb7ef601b] > /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN11LLImageBase16allocateDataSizeEiiii+0x46)[0xb7ef2864] > /home/jgiglio/opensl/SecondLife_i686_1_18_0_6/lib/libllimage.so(_ZN10LLImageRawC1Etta+0x6a)[0xb7ef29fa] > > Google says this usually is caused by a bad (or nonexisting) copy > constructor that causes a double free. I don't see OpenJPEG in the trace. This is glibc detecting corruption of its heap pointers, typically caused by a buffer overrun somewhere. http://www.redhat.com/magazine/009jul05/features/execshield/#overflows Unfortunately it only detects it after the fact, when a block is freed, and really does nothing to tell you where the overrun (the actual bug) happened, it could have been anywhere, in any part of the client, or somewhere in any of the libraries. I've seen this a lot, it seems to happen when rapidly crossing sim borders, but damned if I can get it to happen while running under valgrind. You can't do anything rapidly in valgrind... Should probably Jira this, even with the total lack of information... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070803/b685bd0a/attachment.pgp From jhurliman at wsu.edu Thu Aug 2 22:52:20 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Aug 2 22:52:42 2007 Subject: [sldev] Questions for the bHear team Message-ID: <46B2C294.9010801@wsu.edu> Aux.RenderAudioStart.1 doesn't seem to return a reply for me, yet Aux.RenderAudioStop.1 will return a successful reply. I've tried with Loop set to both 0 and 1 and a relative and absolute path to a small wave file. Is RenderAudioStart implemented, and if so is the SoundFilePath expecting a relative or absolute (or either) file path, and what file format should the audio be in? Aux.SetSpeakerLevel.1 interprets Level values oddly. Through guess and check I found the valid range is between 0 and 100 (integer), but when I send 75 it says I sent 87. Is this an issue with how fine-grained the volume is able to be set on my system, or something else going on? Is there any kind of timeframe to documentation being released for this protocol? I noticed that the license file for the libraries package doesn't include the license for vivoxsdk, SLVoice, or SLVoiceAgent. Can we distribute these binaries or will open source clients not have voice capabilities? John Hurliman From pnolan at dsl.pipex.com Fri Aug 3 02:28:24 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Fri Aug 3 02:28:43 2007 Subject: [sldev] Source release for 1.18.1.2 In-Reply-To: <46B268E4.9050804@lindenlab.com> Message-ID: Hi, There are some components missing from the source distribution set Llaudiostatus.cpp, .h and llvolumesliderctrl.cpp, .h I tried the version form branch 1-18-0 but without success Currently can't build 1.18.1.2 Paul -- Paul Nolan RL == Paul Churchill SL It was 3/8/07 00:29, when "Rob Lanphier" wrote: > This is now in svn.secondlife.com: > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1/ > revision 68 > > Rob > > > On 8/2/07 3:32 PM, Anthony Foster wrote: >> Hello everyone, >> >> It's been a while since I've done one of these, so let me know if I >> miss anything. >> >> 1.18.1.2 source release available here: >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 >> Release note information provided below. >> Blog announcement: >> http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ >> >> >> Checksums: >> >> 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz >> ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz >> 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz >> 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip >> d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip >> b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip >> >> >> >> SVN checkout: >> http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 >> >> Enjoy. >> -Anthony >> >> >> >> >> >> Release Notes for Second Life 1.18.1(2) August 2, 2007 >> ===================================== >> >> New Features: >> * In-World Voice Chat >> ** In-world Voice Chat is now part of the main viewer. >> ** You can see and manage all voice settings in Edit > Preferences > >> Voice Chat. >> ** Voice is off by default. To enable (and disable) voice, visit Edit >>> Preferences > Voice Chat and check/uncheck the box beside "Enable >> voice chat". >> ** A voice set-up wizard appears during first voice use to help >> residents set up voice and adjust their mic volume and tuning. You >> should run the voice set-up wizard even if you only want the ability >> to hear others and do not wish to speak. >> ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by >> default, which means Resident mics are OFF by default. >> ** Speech gestures for voice are included in the Library, in Gestures >>> Speech Gestures. These gestures need to be activated in order to >> work; they are off by default. >> * Streaming video support for Linux client. >> >> Changes: >> * Shortcut keys for menu items in the Client & Server menus are now >> disabled if the menus are hidden. >> * Text from objects can be muted. >> >> Bug fixes: >> * VWR-1797: Remove mention of "Live Help" from Crash Logger >> * VWR-1732: Pressing Enter, with multiple inventory objects selected, >> crashes viewer >> * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack >> on Windows build >> * VWR-1723: Possible crash in llvopartgroup >> * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp >> * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler >> warning #4065 for 'switch' statements >> * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry >> * VWR-1698: Clean up parcel flag manipulation >> * VWR-1655: Script Warnings/errors window is hard to resize, resets >> size after closing tabs. >> * VWR-1646: Possible crash when login server is unavailable. >> * VWR-1626: Patch to avoid IM window from resizing when sessions open >> or close >> * VWR-1613: Overuse of virtual >> * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats >> tuning >> * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp >> * VWR-1578: Two quirks in IM regarding "xxxx is typing" >> * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing >> on first use when "only select own objects" is enabled >> * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are >> disabled when opening friends list window >> * VWR-1468: LoginPacketNeverReceived dialog text is incorrect >> * VWR-1462: Order of right-click menu on Inventory is confusing >> * VWR-1453: A few old-school changes for llviewerregion.cpp >> * VWR-1434: Null pointer crash when terraforming >> * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 >> * VWR-1382: Some scripted objects are highlighted in red while >> pressing Alt with tools open >> * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build >> fails. >> * VWR-1358: Physical objects remain red if tools window is closed >> while holding Alt key >> * VWR-1358: Physical objects remain red if tools window is closed >> while holding Alt key >> * VWR-1353: Misleading variable names in LLTextEditor >> * VWR-1344: Reverse order of popups, so that new ones appear >> underneath existing ones rather than on top. >> * VWR-1318: Selecting Cancel while saving a snapshot to disk still >> triggers snapshot gesture >> * VWR-1314: Multiple selection then individual deselection of >> attachments broken >> * VWR-1294: Possibly threads not fully cleaned up at end of program >> * VWR-1289: On logging in, sound volume for stream is low, despite the >> actual setting in the music control >> * VWR-1282: Better error handling when fonts are missing >> * VWR-1270: Script error window keeps reverting to a very small size >> * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key >> * VWR-1105: Set internal limit of particle count to max value from GUI >> preferences. >> * VWR-1092: Disable mouse hover text on HUDs, since it always only >> shows the owner's name and generally gets in the way of HUD >> functionality. >> * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: >> ... resizeable and minimizable) >> * VWR-447: Allow minimized windows to be repositioned in client >> * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu >> * VWR-349: Change keyboard shortcuts, because entering { [ ] } on >> German and some other international keyboards (AltGr 7, 8, 9, 0) >> triggers Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 >> (previously resulting in unstable viewer) >> * VWR-238: Permissions of Roles and Rights in the german version are >> mased up. >> * VWR-102: md5 slow >> * SVC-371: Fix the legibility and grammar/consistency of the new >> llOwnerSay implementation >> * SVC-193: llParticleSystem - halo of rogue particles around original >> particle system after 1.15 update* SVC-373: Deleting a script's code >> results in a non-existent file and "missing from database" error >> * Fixed preference for showing or hiding server combo box was not >> preserved >> * Fixed residents with negative L$ balance can't purchase items set >> for sale "Original" or "Copy" that are being sold for L$0 >> * "Copy SLURL to clipboard" is now enabled for an avatar's current >> coordinates >> * Macintosh viewer now correctly opens the map and selects the >> destination on a SLURL request >> * Leading and trailing spaces are now automatically trimmed from >> parcel media URLs >> * Corrected the spacing of the yellow "next dialog" chevron (was >> partially blocked by the Mute button) >> * Corrected the error message shown when adding 11th Estate Manager >> * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo >> * "Set Window Size..." setting is now correctly resumed after being >> minimized >> * Added link to Qa wiki in the viewer bug reporter menu. >> * Updated text in Second Life Crash Logger with new support portal >> information >> * Corrected an issue with UI font scaling in the bug reporter window >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Fri Aug 3 02:29:05 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Aug 3 02:29:06 2007 Subject: [sldev] Uh... what was with the sudden voice release? Message-ID: It seems rather rushed - apart from the chatterbox issues, there are also firewall issues (the FAQ is wrong - it implies that if you are firewall router you only need to enable 5060 and possible 5062. This is incorrect. It looks like the SLVoice.exe does the initial handshake over 5060/5062 but then establishes the voip connections themselves over UDP ports which afaict are picked at random within the 12000-16000 range. If you firewall does not have this range open by default for outgoing messages, not only does VOIP not work but you get spammed with "Connecting to inworld voice..." every few minutes in the chat history log). Anyway, looks like this weekend, I'll be looking at the new chatterbox source code... Matthew ---------------------------------------- > From: sl@phoca.com > To: sldev@lists.secondlife.com > Date: Thu, 2 Aug 2007 17:48:44 -0700 > Subject: [sldev] Uh... what was with the sudden voice release? > > I don't remember seeing any warning of an public release of voice today. > > That pretty much kills any chance of fixing the worst problems of the > chatter box :( > > Is it time to start talking about an alternative UI for real SL users? > > Besides unbreaking the chatterbox there was always HUGE room for improvement > of the SL UI and chat features such as customizable syntax/user highlighting > etc. > > Is it time for me to write "Phoca for SL"? Anyone interested in what that > might entail? > :( > > Farallon > > ----- Original Message ----- > From: "Anthony Foster" > To: > Sent: Thursday, August 02, 2007 3:32 PM > Subject: [sldev] Source release for 1.18.1.2 > > > > Hello everyone, > > > > It's been a while since I've done one of these, so let me know if I miss > > anything. > > > > 1.18.1.2 source release available here: > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 > > Release note information provided below. > > Blog announcement: > > http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ > > > > Checksums: > > > > 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz > > ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz > > 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz > > 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip > > d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip > > b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip > > > > > > > > SVN checkout: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 > > at r67242 > > > > Enjoy. > > -Anthony > > > > > > > > > > > > Release Notes for Second Life 1.18.1(2) August 2, 2007 > > ===================================== > > > > New Features: > > * In-World Voice Chat > > ** In-world Voice Chat is now part of the main viewer. > > ** You can see and manage all voice settings in Edit > Preferences > Voice > > Chat. > > ** Voice is off by default. To enable (and disable) voice, visit Edit > > > Preferences > Voice Chat and check/uncheck the box beside "Enable voice > > chat". > > ** A voice set-up wizard appears during first voice use to help residents > > set up voice and adjust their mic volume and tuning. You should run the > > voice set-up wizard even if you only want the ability to hear others and > > do not wish to speak. > > ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by > > default, which means Resident mics are OFF by default. > > ** Speech gestures for voice are included in the Library, in Gestures > > > Speech Gestures. These gestures need to be activated in order to work; > > they are off by default. > > * Streaming video support for Linux client. > > > > Changes: > > * Shortcut keys for menu items in the Client & Server menus are now > > disabled if the menus are hidden. > > * Text from objects can be muted. > > > > Bug fixes: > > * VWR-1797: Remove mention of "Live Help" from Crash Logger > > * VWR-1732: Pressing Enter, with multiple inventory objects selected, > > crashes viewer > > * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack on > > Windows build > > * VWR-1723: Possible crash in llvopartgroup > > * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp > > * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler > > warning #4065 for 'switch' statements > > * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry > > * VWR-1698: Clean up parcel flag manipulation > > * VWR-1655: Script Warnings/errors window is hard to resize, resets size > > after closing tabs. > > * VWR-1646: Possible crash when login server is unavailable. > > * VWR-1626: Patch to avoid IM window from resizing when sessions open or > > close > > * VWR-1613: Overuse of virtual > > * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats > > tuning > > * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp > > * VWR-1578: Two quirks in IM regarding "xxxx is typing" > > * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing on > > first use when "only select own objects" is enabled > > * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are > > disabled when opening friends list window > > * VWR-1468: LoginPacketNeverReceived dialog text is incorrect > > * VWR-1462: Order of right-click menu on Inventory is confusing > > * VWR-1453: A few old-school changes for llviewerregion.cpp > > * VWR-1434: Null pointer crash when terraforming > > * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 > > * VWR-1382: Some scripted objects are highlighted in red while pressing > > Alt with tools open > > * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build fails. > > * VWR-1358: Physical objects remain red if tools window is closed while > > holding Alt key > > * VWR-1358: Physical objects remain red if tools window is closed while > > holding Alt key > > * VWR-1353: Misleading variable names in LLTextEditor > > * VWR-1344: Reverse order of popups, so that new ones appear underneath > > existing ones rather than on top. > > * VWR-1318: Selecting Cancel while saving a snapshot to disk still > > triggers snapshot gesture > > * VWR-1314: Multiple selection then individual deselection of attachments > > broken > > * VWR-1294: Possibly threads not fully cleaned up at end of program > > * VWR-1289: On logging in, sound volume for stream is low, despite the > > actual setting in the music control > > * VWR-1282: Better error handling when fonts are missing > > * VWR-1270: Script error window keeps reverting to a very small size > > * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key > > * VWR-1105: Set internal limit of particle count to max value from GUI > > preferences. > > * VWR-1092: Disable mouse hover text on HUDs, since it always only shows > > the owner's name and generally gets in the way of HUD functionality. > > * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: ... > > resizeable and minimizable) > > * VWR-447: Allow minimized windows to be repositioned in client > > * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu > > * VWR-349: Change keyboard shortcuts, because entering { [ ] } on German > > and some other international keyboards (AltGr 7, 8, 9, 0) triggers > > Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 (previously resulting > > in unstable viewer) > > * VWR-238: Permissions of Roles and Rights in the german version are mased > > up. > > * VWR-102: md5 slow > > * SVC-371: Fix the legibility and grammar/consistency of the new > > llOwnerSay implementation > > * SVC-193: llParticleSystem - halo of rogue particles around original > > particle system after 1.15 update* SVC-373: Deleting a script's code > > results in a non-existent file and "missing from database" error > > * Fixed preference for showing or hiding server combo box was not > > preserved > > * Fixed residents with negative L$ balance can't purchase items set for > > sale "Original" or "Copy" that are being sold for L$0 > > * "Copy SLURL to clipboard" is now enabled for an avatar's current > > coordinates > > * Macintosh viewer now correctly opens the map and selects the destination > > on a SLURL request > > * Leading and trailing spaces are now automatically trimmed from parcel > > media URLs > > * Corrected the spacing of the yellow "next dialog" chevron (was partially > > blocked by the Mute button) > > * Corrected the error message shown when adding 11th Estate Manager > > * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo > > * "Set Window Size..." setting is now correctly resumed after being > > minimized > > * Added link to Qa wiki in the viewer bug reporter menu. > > * Updated text in Second Life Crash Logger with new support portal > > information > > * Corrected an issue with UI font scaling in the bug reporter window > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From nicholaz at blueflash.cc Fri Aug 3 02:38:00 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Aug 3 02:38:07 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: References: Message-ID: <46B2F778.2030508@blueflash.cc> Matt, Matthew Dowd wrote: > Anyway, looks like this weekend, I'll be looking at the new chatterbox source code... I'll do the same. I saw that the user list is still a floater, so it'll hopefully be possible to revert to the old behavior quickly and without changing GUI files (which I usually try to avoid). Anyone else interested in this and making collaborating on this? Does anyone got a platform for discussing progress and findings? I guess it'll possibly spam this list. Hijacking a Wiki discussion pages maybe? Nick From matthew.dowd at hotmail.co.uk Fri Aug 3 04:07:11 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Aug 3 04:07:13 2007 Subject: [sldev] Source release for 1.18.1.2 Message-ID: I don't think those files are needed - are you trying to build under VS2005 by any chance. Those files are in the project files you can get for 1.18.0 in jira but those files don't quite work under 1.18.1. In particular there are a few new files in 1.18.1 which aren't in those proj files and a few which are which are no longer needed. (I think - I've got a successfull build of 1.18.1 through VS2005 now, but not yet tested running it...) Matthew ---------------------------------------- > Date: Fri, 3 Aug 2007 10:28:24 +0100 > Subject: Re: [sldev] Source release for 1.18.1.2 > From: pnolan@dsl.pipex.com > To: robla@lindenlab.com; sldev@lists.secondlife.com > > Hi, > > There are some components missing from the source distribution set > > Llaudiostatus.cpp, .h and llvolumesliderctrl.cpp, .h > > I tried the version form branch 1-18-0 but without success > > Currently can't build 1.18.1.2 > > Paul > > -- > Paul Nolan RL == Paul Churchill SL > > > > It was 3/8/07 00:29, when "Rob Lanphier" wrote: > > > This is now in svn.secondlife.com: > > http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1/ > > revision 68 > > > > Rob > > > > > > On 8/2/07 3:32 PM, Anthony Foster wrote: > >> Hello everyone, > >> > >> It's been a while since I've done one of these, so let me know if I > >> miss anything. > >> > >> 1.18.1.2 source release available here: > >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 > >> Release note information provided below. > >> Blog announcement: > >> http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ > >> > >> > >> Checksums: > >> > >> 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz > >> ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz > >> 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz > >> 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip > >> d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip > >> b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip > >> > >> > >> > >> SVN checkout: > >> http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 at r67242 > >> > >> Enjoy. > >> -Anthony > >> > >> > >> > >> > >> > >> Release Notes for Second Life 1.18.1(2) August 2, 2007 > >> ===================================== > >> > >> New Features: > >> * In-World Voice Chat > >> ** In-world Voice Chat is now part of the main viewer. > >> ** You can see and manage all voice settings in Edit > Preferences > > >> Voice Chat. > >> ** Voice is off by default. To enable (and disable) voice, visit Edit > >>> Preferences > Voice Chat and check/uncheck the box beside "Enable > >> voice chat". > >> ** A voice set-up wizard appears during first voice use to help > >> residents set up voice and adjust their mic volume and tuning. You > >> should run the voice set-up wizard even if you only want the ability > >> to hear others and do not wish to speak. > >> ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by > >> default, which means Resident mics are OFF by default. > >> ** Speech gestures for voice are included in the Library, in Gestures > >>> Speech Gestures. These gestures need to be activated in order to > >> work; they are off by default. > >> * Streaming video support for Linux client. > >> > >> Changes: > >> * Shortcut keys for menu items in the Client & Server menus are now > >> disabled if the menus are hidden. > >> * Text from objects can be muted. > >> > >> Bug fixes: > >> * VWR-1797: Remove mention of "Live Help" from Crash Logger > >> * VWR-1732: Pressing Enter, with multiple inventory objects selected, > >> crashes viewer > >> * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack > >> on Windows build > >> * VWR-1723: Possible crash in llvopartgroup > >> * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp > >> * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler > >> warning #4065 for 'switch' statements > >> * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry > >> * VWR-1698: Clean up parcel flag manipulation > >> * VWR-1655: Script Warnings/errors window is hard to resize, resets > >> size after closing tabs. > >> * VWR-1646: Possible crash when login server is unavailable. > >> * VWR-1626: Patch to avoid IM window from resizing when sessions open > >> or close > >> * VWR-1613: Overuse of virtual > >> * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats > >> tuning > >> * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp > >> * VWR-1578: Two quirks in IM regarding "xxxx is typing" > >> * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing > >> on first use when "only select own objects" is enabled > >> * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are > >> disabled when opening friends list window > >> * VWR-1468: LoginPacketNeverReceived dialog text is incorrect > >> * VWR-1462: Order of right-click menu on Inventory is confusing > >> * VWR-1453: A few old-school changes for llviewerregion.cpp > >> * VWR-1434: Null pointer crash when terraforming > >> * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 > >> * VWR-1382: Some scripted objects are highlighted in red while > >> pressing Alt with tools open > >> * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build > >> fails. > >> * VWR-1358: Physical objects remain red if tools window is closed > >> while holding Alt key > >> * VWR-1358: Physical objects remain red if tools window is closed > >> while holding Alt key > >> * VWR-1353: Misleading variable names in LLTextEditor > >> * VWR-1344: Reverse order of popups, so that new ones appear > >> underneath existing ones rather than on top. > >> * VWR-1318: Selecting Cancel while saving a snapshot to disk still > >> triggers snapshot gesture > >> * VWR-1314: Multiple selection then individual deselection of > >> attachments broken > >> * VWR-1294: Possibly threads not fully cleaned up at end of program > >> * VWR-1289: On logging in, sound volume for stream is low, despite the > >> actual setting in the music control > >> * VWR-1282: Better error handling when fonts are missing > >> * VWR-1270: Script error window keeps reverting to a very small size > >> * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key > >> * VWR-1105: Set internal limit of particle count to max value from GUI > >> preferences. > >> * VWR-1092: Disable mouse hover text on HUDs, since it always only > >> shows the owner's name and generally gets in the way of HUD > >> functionality. > >> * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: > >> ... resizeable and minimizable) > >> * VWR-447: Allow minimized windows to be repositioned in client > >> * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu > >> * VWR-349: Change keyboard shortcuts, because entering { [ ] } on > >> German and some other international keyboards (AltGr 7, 8, 9, 0) > >> triggers Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 > >> (previously resulting in unstable viewer) > >> * VWR-238: Permissions of Roles and Rights in the german version are > >> mased up. > >> * VWR-102: md5 slow > >> * SVC-371: Fix the legibility and grammar/consistency of the new > >> llOwnerSay implementation > >> * SVC-193: llParticleSystem - halo of rogue particles around original > >> particle system after 1.15 update* SVC-373: Deleting a script's code > >> results in a non-existent file and "missing from database" error > >> * Fixed preference for showing or hiding server combo box was not > >> preserved > >> * Fixed residents with negative L$ balance can't purchase items set > >> for sale "Original" or "Copy" that are being sold for L$0 > >> * "Copy SLURL to clipboard" is now enabled for an avatar's current > >> coordinates > >> * Macintosh viewer now correctly opens the map and selects the > >> destination on a SLURL request > >> * Leading and trailing spaces are now automatically trimmed from > >> parcel media URLs > >> * Corrected the spacing of the yellow "next dialog" chevron (was > >> partially blocked by the Mute button) > >> * Corrected the error message shown when adding 11th Estate Manager > >> * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo > >> * "Set Window Size..." setting is now correctly resumed after being > >> minimized > >> * Added link to Qa wiki in the viewer bug reporter menu. > >> * Updated text in Second Life Crash Logger with new support portal > >> information > >> * Corrected an issue with UI font scaling in the bug reporter window > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From matthew.dowd at hotmail.co.uk Fri Aug 3 04:28:07 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Aug 3 04:28:08 2007 Subject: VS2005 - RE: [sldev] Source release for 1.18.1.2 Message-ID: OK for building the new source under VS2005, if you use the project files in Jira for 1.18.06 under VS2005 but replace the newview_vc8.vcproj with the attached it should work. (hopefully...) Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com -------------- next part -------------- A non-text attachment was scrubbed... Name: newview_vc8.vcproj Type: application/octet-stream Size: 84497 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070803/6949d459/newview_vc8-0001.obj From pnolan at dsl.pipex.com Fri Aug 3 04:46:35 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Fri Aug 3 04:46:53 2007 Subject: VS2005 - RE: [sldev] Source release for 1.18.1.2 In-Reply-To: Message-ID: Matthew, You made a great call earlier, when I went through and resolved the extra/missing files in the project it all compiled and linked beautifully. Thanks, Paul -- Paul Nolan RL == Paul Churchill SL It was 3/8/07 12:28, when "Matthew Dowd" wrote: > > OK for building the new source under VS2005, if you use the project files in > Jira for 1.18.06 under VS2005 but replace the newview_vc8.vcproj with the > attached it should work. > > (hopefully...) > > Matthew > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jhurliman at wsu.edu Fri Aug 3 05:19:22 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Aug 3 05:19:46 2007 Subject: [sldev] Typo in llvoiceclient.cpp? Message-ID: <46B31D4A.1050804@wsu.edu> llvoiceclient.cpp:463: else if (strcmp("ParticipantTyppe", tag) == 0) Looks like a typo, but I'm not sure if this typo exist in SLVoice.exe and SL is mirroring it, or if it would actually cause problems. John Hurliman From tateru.nino at gmail.com Fri Aug 3 05:43:51 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Aug 3 05:43:58 2007 Subject: [sldev] Typo in llvoiceclient.cpp? In-Reply-To: <46B31D4A.1050804@wsu.edu> References: <46B31D4A.1050804@wsu.edu> Message-ID: <46B32307.1020701@gmail.com> Neither "ParticipantType" nor "ParticipantTyppe" appear to be strings in the SLVoice.exe John Hurliman wrote: > llvoiceclient.cpp:463: else if (strcmp("ParticipantTyppe", tag) == 0) > > Looks like a typo, but I'm not sure if this typo exist in SLVoice.exe > and SL is mirroring it, or if it would actually cause problems. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From robin.cornelius at gmail.com Fri Aug 3 06:22:40 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 3 06:22:45 2007 Subject: [sldev] audio_update_wind() not protected against NULL gAudiop Message-ID: <46B32C20.60209@gmail.com> Hi Guys, In the latest main stream source, 1.18.1.2 there is a bug that only seems to show its head when you compile yourself on linux (anyway no idea for windows) Anyway if kAUDIO_ENABLE_WIND is defined then the function body of audio_update_wind() in viewer.cpp:4202 is enabled and if like me you have sound issues and have all 3 sound servers disabled in the start up script you have a NULL gAudiop. In the distributed viewer it does not crash this way, and I am not sure when and how kAUDIO_ENABLE_WIND gets enabled but it did when i built a linux debug build. a quick fix is to patch line viewer.cpp:4902 from if (region) to if (region && gAudiop) Regards -- Robin Cornelius http://www.byteme.org.uk From robin.cornelius at gmail.com Fri Aug 3 06:32:04 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 3 06:32:04 2007 Subject: [sldev] Crash when sorting through inventory In-Reply-To: <46B1FB8D.9030506@lindenlab.com> References: <46B1B73C.40506@gmail.com> <46B1BBBD.4060403@gmail.com> <46B1F8C4.1020603@lindenlab.com> <46B1FB8D.9030506@lindenlab.com> Message-ID: <46B32E54.8030705@gmail.com> Tofu Linden wrote: > Tofu Linden wrote: >> Unfortunately (or fortunately), I can't reproduce this in a >> recent releasefordownload build. I'm going to take a closer look >> at the 1_18_0_6 source snapshot. > > Oh, it really is an llassert - and it does look quite serious > that this is firing. I'll look into it. > http://jira.secondlife.com/browse/VWR-1974 > Verified and repeated for 1.18.1.2 -- Robin Cornelius http://www.byteme.org.uk From pnolan at dsl.pipex.com Fri Aug 3 06:34:04 2007 From: pnolan at dsl.pipex.com (Paul Nolan) Date: Fri Aug 3 06:34:13 2007 Subject: [sldev] Typo in llvoiceclient.cpp? In-Reply-To: <46B32307.1020701@gmail.com> Message-ID: Looks like a typo to me. If this test were to be successful, llvoiceclient.cpp:464 set participantType accordingly. This is used by processResponse to call participantStateChangeEvent (line 550) which makes no use of the parameter. Seems to be dead code which would fail should it ever become reachable. My ?0.02 Paul -- Paul Nolan RL == Paul Churchill SL It was 3/8/07 13:43, when "Tateru Nino" wrote: > Neither "ParticipantType" nor "ParticipantTyppe" appear to be strings in > the SLVoice.exe > > John Hurliman wrote: >> llvoiceclient.cpp:463: else if (strcmp("ParticipantTyppe", tag) == 0) >> >> Looks like a typo, but I'm not sure if this typo exist in SLVoice.exe >> and SL is mirroring it, or if it would actually cause problems. >> >> John Hurliman >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From nicholaz at blueflash.cc Fri Aug 3 08:16:55 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Aug 3 08:17:04 2007 Subject: [sldev] Voice with old style gui Message-ID: <46B346E7.2010907@blueflash.cc> If anyone is working on this already or plans to, you might want to hold off a bit. I just spent a bit of time on this and it looks quite good already ... shouldn't be too messy. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From soft at lindenlab.com Fri Aug 3 08:56:44 2007 From: soft at lindenlab.com (Soft Linden) Date: Fri Aug 3 08:56:45 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: References: Message-ID: <9e6e5c9e0708030856u5eb109cej150c16fbd0f70dca@mail.gmail.com> I passed the previous notes on firewall ports in the knowledgebase to bHear - I'll get this additional information out their way as well. Thanks for posting this On 8/3/07, Matthew Dowd wrote: > > > It seems rather rushed - apart from the chatterbox issues, there are also firewall issues (the FAQ is wrong - it implies that if you are firewall router you only need to enable 5060 and possible 5062. This is incorrect. It looks like the SLVoice.exe does the initial handshake over 5060/5062 but then establishes the voip connections themselves over UDP ports which afaict are picked at random within the 12000-16000 range. If you firewall does not have this range open by default for outgoing messages, not only does VOIP not work but you get spammed with "Connecting to inworld voice..." every few minutes in the chat history log). > > Anyway, looks like this weekend, I'll be looking at the new chatterbox source code... > > Matthew > > > > ---------------------------------------- > > From: sl@phoca.com > > To: sldev@lists.secondlife.com > > Date: Thu, 2 Aug 2007 17:48:44 -0700 > > Subject: [sldev] Uh... what was with the sudden voice release? > > > > I don't remember seeing any warning of an public release of voice today. > > > > That pretty much kills any chance of fixing the worst problems of the > > chatter box :( > > > > Is it time to start talking about an alternative UI for real SL users? > > > > Besides unbreaking the chatterbox there was always HUGE room for improvement > > of the SL UI and chat features such as customizable syntax/user highlighting > > etc. > > > > Is it time for me to write "Phoca for SL"? Anyone interested in what that > > might entail? > > :( > > > > Farallon > > > > ----- Original Message ----- > > From: "Anthony Foster" > > To: > > Sent: Thursday, August 02, 2007 3:32 PM > > Subject: [sldev] Source release for 1.18.1.2 > > > > > > > Hello everyone, > > > > > > It's been a while since I've done one of these, so let me know if I miss > > > anything. > > > > > > 1.18.1.2 source release available here: > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.1.2 > > > Release note information provided below. > > > Blog announcement: > > > http://blog.secondlife.com/2007/08/02/the-second-life-voice-viewer-is-live/ > > > > > > Checksums: > > > > > > 883d476214d94d44b4b969b9c1c06608 slviewer-darwin-libs-1.18.1.2.tar.gz > > > ea533712c4affc2a4d3001ced6588be2 slviewer-linux-libs-1.18.1.2.tar.gz > > > 2764ac8f80358130f2252cf5857aec49 slviewer-src-1.18.1.2.tar.gz > > > 44130dede071a42542894e0ab2844f96 slviewer-artwork-1.18.1.2.zip > > > d3d3800b4f5eaf389c3c27ff12ec9273 slviewer-src-1.18.1.2.zip > > > b555560a15586f3cf1d6dd068f39057b slviewer-win32-libs-1.18.1.2.zip > > > > > > > > > > > > SVN checkout: http://svn.secondlife.com/svn/linden/branches/Branch_1-18-1 > > > at r67242 > > > > > > Enjoy. > > > -Anthony > > > > > > > > > > > > > > > > > > Release Notes for Second Life 1.18.1(2) August 2, 2007 > > > ===================================== > > > > > > New Features: > > > * In-World Voice Chat > > > ** In-world Voice Chat is now part of the main viewer. > > > ** You can see and manage all voice settings in Edit > Preferences > Voice > > > Chat. > > > ** Voice is off by default. To enable (and disable) voice, visit Edit > > > > Preferences > Voice Chat and check/uncheck the box beside "Enable voice > > > chat". > > > ** A voice set-up wizard appears during first voice use to help residents > > > set up voice and adjust their mic volume and tuning. You should run the > > > voice set-up wizard even if you only want the ability to hear others and > > > do not wish to speak. > > > ** Push-to-Talk is part of the Voice feature. Push-to-Talk is ON by > > > default, which means Resident mics are OFF by default. > > > ** Speech gestures for voice are included in the Library, in Gestures > > > > Speech Gestures. These gestures need to be activated in order to work; > > > they are off by default. > > > * Streaming video support for Linux client. > > > > > > Changes: > > > * Shortcut keys for menu items in the Client & Server menus are now > > > disabled if the menus are hidden. > > > * Text from objects can be muted. > > > > > > Bug fixes: > > > * VWR-1797: Remove mention of "Live Help" from Crash Logger > > > * VWR-1732: Pressing Enter, with multiple inventory objects selected, > > > crashes viewer > > > * VWR-1729: indra/lscript/lscript_compile/indra.l: avoid yyunput hack on > > > Windows build > > > * VWR-1723: Possible crash in llvopartgroup > > > * VWR-1706: Minor quirk (and cleanup) in llfloater.cpp > > > * VWR-1705: indra/lscript/lscript_compile/indra.y: disable compiler > > > warning #4065 for 'switch' statements > > > * VWR-1704: indra/llui/files.lst: delete llhtmlhelp.h entry > > > * VWR-1698: Clean up parcel flag manipulation > > > * VWR-1655: Script Warnings/errors window is hard to resize, resets size > > > after closing tabs. > > > * VWR-1646: Possible crash when login server is unavailable. > > > * VWR-1626: Patch to avoid IM window from resizing when sessions open or > > > close > > > * VWR-1613: Overuse of virtual > > > * VWR-1612: LLRenderPass::Pushbatch and LLViewerImage::addTextureStats > > > tuning > > > * VWR-1586: Mismatched delete in llviewerparcelmgr.cpp > > > * VWR-1578: Two quirks in IM regarding "xxxx is typing" > > > * VWR-1471: Inspect (Pie menu > More > More > Inspect) shows nothing on > > > first use when "only select own objects" is enabled > > > * VWR-1470: Buttons (IM, Teleport, Profile, ...) in friends list are > > > disabled when opening friends list window > > > * VWR-1468: LoginPacketNeverReceived dialog text is incorrect > > > * VWR-1462: Order of right-click menu on Inventory is confusing > > > * VWR-1453: A few old-school changes for llviewerregion.cpp > > > * VWR-1434: Null pointer crash when terraforming > > > * VWR-1406: Unchecking "Go Away/AFK when idle" has no effect in 1.17.2.0 > > > * VWR-1382: Some scripted objects are highlighted in red while pressing > > > Alt with tools open > > > * VWR-1381: libpng12.a for MacOS X is missing in 1.17.1.0 and build fails. > > > * VWR-1358: Physical objects remain red if tools window is closed while > > > holding Alt key > > > * VWR-1358: Physical objects remain red if tools window is closed while > > > holding Alt key > > > * VWR-1353: Misleading variable names in LLTextEditor > > > * VWR-1344: Reverse order of popups, so that new ones appear underneath > > > existing ones rather than on top. > > > * VWR-1318: Selecting Cancel while saving a snapshot to disk still > > > triggers snapshot gesture > > > * VWR-1314: Multiple selection then individual deselection of attachments > > > broken > > > * VWR-1294: Possibly threads not fully cleaned up at end of program > > > * VWR-1289: On logging in, sound volume for stream is low, despite the > > > actual setting in the music control > > > * VWR-1282: Better error handling when fonts are missing > > > * VWR-1270: Script error window keeps reverting to a very small size > > > * VWR-1246: Mac: File menu > Snapshot to Disk lists wrong shortcut key > > > * VWR-1105: Set internal limit of particle count to max value from GUI > > > preferences. > > > * VWR-1092: Disable mouse hover text on HUDs, since it always only shows > > > the owner's name and generally gets in the way of HUD functionality. > > > * VWR-727: Torn of IM windows should be minimizable (was re: VWR-233: ... > > > resizeable and minimizable) > > > * VWR-447: Allow minimized windows to be repositioned in client > > > * VWR-353: Rebake command - add a keyboard shortcut and put in tools menu > > > * VWR-349: Change keyboard shortcuts, because entering { [ ] } on German > > > and some other international keyboards (AltGr 7, 8, 9, 0) triggers > > > Rendering Features accelerators Ctrl-Alt-7, 8, 9, 0 (previously resulting > > > in unstable viewer) > > > * VWR-238: Permissions of Roles and Rights in the german version are mased > > > up. > > > * VWR-102: md5 slow > > > * SVC-371: Fix the legibility and grammar/consistency of the new > > > llOwnerSay implementation > > > * SVC-193: llParticleSystem - halo of rogue particles around original > > > particle system after 1.15 update* SVC-373: Deleting a script's code > > > results in a non-existent file and "missing from database" error > > > * Fixed preference for showing or hiding server combo box was not > > > preserved > > > * Fixed residents with negative L$ balance can't purchase items set for > > > sale "Original" or "Copy" that are being sold for L$0 > > > * "Copy SLURL to clipboard" is now enabled for an avatar's current > > > coordinates > > > * Macintosh viewer now correctly opens the map and selects the destination > > > on a SLURL request > > > * Leading and trailing spaces are now automatically trimmed from parcel > > > media URLs > > > * Corrected the spacing of the yellow "next dialog" chevron (was partially > > > blocked by the Mute button) > > > * Corrected the error message shown when adding 11th Estate Manager > > > * Added CPU detection for Intel Core Duo/Solo and Intel Core 2 Duo > > > * "Set Window Size..." setting is now correctly resumed after being > > > minimized > > > * Added link to Qa wiki in the viewer bug reporter menu. > > > * Updated text in Second Life Crash Logger with new support portal > > > information > > > * Corrected an issue with UI font scaling in the bug reporter window > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > 100's of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Fri Aug 3 09:07:32 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Aug 3 09:08:04 2007 Subject: [sldev] Uh... what was with the sudden voice release? In-Reply-To: <9e6e5c9e0708030856u5eb109cej150c16fbd0f70dca@mail.gmail.com> References: <9e6e5c9e0708030856u5eb109cej150c16fbd0f70dca@mail.gmail.com> Message-ID: <46B352C4.8050607@wsu.edu> Are you sure the range is always 12000-16000? I got this reply from the Vivox gateway during testing: 2286022892 Not sure if that port range is for the server or the client or both, or if it is even used, but SIP/RTP are definitely going to be using a couple different ports here and there. John Soft Linden wrote: > I passed the previous notes on firewall ports in the knowledgebase to > bHear - I'll get this additional information out their way as well. > Thanks for posting this > > On 8/3/07, Matthew Dowd wrote: > >> It seems rather rushed - apart from the chatterbox issues, there are also firewall issues (the FAQ is wrong - it implies that if you are firewall router you only need to enable 5060 and possible 5062. This is incorrect. It looks like the SLVoice.exe does the initial handshake over 5060/5062 but then establishes the voip connections themselves over UDP ports which afaict are picked at random within the 12000-16000 range. If you firewall does not have this range open by default for outgoing messages, not only does VOIP not work but you get spammed with "Connecting to inworld voice..." every few minutes in the chat history log). >> >> Anyway, looks like this weekend, I'll be looking at the new chatterbox source code... >> >> Matthew >> From jhurliman at wsu.edu Fri Aug 3 09:11:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Aug 3 09:11:41 2007 Subject: [sldev] bHear team: Account.Login.1 return/status codes? In-Reply-To: <9e6e5c9e0708030856u5eb109cej150c16fbd0f70dca@mail.gmail.com> References: <9e6e5c9e0708030856u5eb109cej150c16fbd0f70dca@mail.gmail.com> Message-ID: <46B353A4.5000107@wsu.edu> What does status code 20202 mean in reply to Account.Login.1? Here is the output from my program, I can't get any further until I figure out how to successfully login: ---- Capture Devices: 0. "Microphone (Realtek High Defini" 1. "Realtek Digital Input (Realtek " Render Devices: 0. "Speakers (Realtek High Definiti" 1. "Realtek Digital Output (Realtek" Creating voice connector... Voice connector handle: c1_m1000 Asking the current simulator to create a provisional account... Provisional account created. Username: xCIPiYTFGSQakOpyG1F8ndA==, Password: bWV00GTSLAUUWLUXQWL0UR0 Logging in to voice server bhr.vivox.com Login failed, error code: 20202 Press any key to continue... ---- Am I connecting to the wrong voice server possibly? John Hurliman From gigstaggart at gmail.com Fri Aug 3 09:36:59 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Aug 3 09:36:45 2007 Subject: [sldev] audio_update_wind() not protected against NULL gAudiop In-Reply-To: <46B32C20.60209@gmail.com> References: <46B32C20.60209@gmail.com> Message-ID: <46B359AB.2000605@gmail.com> Robin Cornelius wrote: > > Hi Guys, > > In the latest main stream source, 1.18.1.2 there is a bug that only > seems to show its head when you compile yourself on linux (anyway no > idea for windows) > > Anyway if kAUDIO_ENABLE_WIND is defined then the function body of > audio_update_wind() in viewer.cpp:4202 is enabled and if like me you > have sound issues and have all 3 sound servers disabled in the start up > script you have a NULL gAudiop. > > In the distributed viewer it does not crash this way, and I am not sure > when and how kAUDIO_ENABLE_WIND gets enabled but it did when i built a > linux debug build. > > > a quick fix is to patch line viewer.cpp:4902 > > from > > if (region) > > to > > if (region && gAudiop) > I wouldn't do only that. I put a patch on Jira that follows the existing conventions better, and also avoids running other dangerous audio functions when no subsystem is present. An extra check in audio_update_wind wouldn't hurt, though. http://jira.secondlife.com/browse/VWR-1987 From matthew.dowd at hotmail.co.uk Fri Aug 3 10:15:18 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Aug 3 10:15:20 2007 Subject: [sldev] Voice with old style gui Message-ID: Ah, I've already been working on this along the lines outlined here: http://jira.secondlife.com/browse/VWR-1917 i.e. making the menu options for Groups and Friends open new windows rather than the chatterbox. An initial diff of this is attached. Matthew ---------------------------------------- > Date: Fri, 3 Aug 2007 17:16:55 +0200 > From: nicholaz@blueflash.cc > To: sldev@lists.secondlife.com > Subject: [sldev] Voice with old style gui > > > If anyone is working on this already or plans > to, you might want to hold off a bit. I just > spent a bit of time on this and it looks quite > good already ... shouldn't be too messy. > > > Nick > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb -------------- next part -------------- --- base\linden\indra\newview\llviewermenu.cpp 2007-08-02 14:16:00.000000000 +0100 +++ mod\linden\indra\newview\llviewermenu.cpp 2007-08-03 15:39:43.390774800 +0100 @@ -5378,7 +5378,11 @@ } else if (floater_name == "friends") { - LLFloaterMyFriends::toggleInstance(0); + LLFloaterFriendsOnly::toggleInstance(0); + } + else if (floater_name == "groups") + { + LLFloaterGroupsOnly::toggleInstance(0); } else if (floater_name == "preferences") { @@ -5520,7 +5524,11 @@ bool new_value = false; if (floater_name == "friends") { - new_value = LLFloaterMyFriends::instanceVisible(0); + new_value = LLFloaterFriendsOnly::instanceVisible(0); + } + if (floater_name == "groups") + { + new_value = LLFloaterGroupsOnly::instanceVisible(0); } else if (floater_name == "toolbar") { @@ -5670,7 +5678,7 @@ { bool handleEvent(LLPointer event, const LLSD& userdata) { - LLFloaterMyFriends::toggleInstance(1); + LLFloaterMyFriends::showInstance(LLSD(gAgent.getID())); return true; } }; --- base\linden\indra\newview\llfloaterchatterbox.h 2007-08-02 14:16:00.000000000 +0100 +++ mod\linden\indra\newview\llfloaterchatterbox.h 2007-08-03 17:29:51.712554100 +0100 @@ -58,6 +58,29 @@ LLTabContainerCommon* mTabs; }; +class LLFloaterFriendsOnly : public LLFloater, public LLUISingleton +{ +public: + LLFloaterFriendsOnly(const LLSD& seed); + virtual ~LLFloaterFriendsOnly(); + static BOOL instanceVisible(const LLSD& id); + void onClose(bool app_quitting); + + static void* createFriendsPanel(void* data); +}; + +class LLFloaterGroupsOnly : public LLFloater, public LLUISingleton +{ +public: + LLFloaterGroupsOnly(const LLSD& seed); + virtual ~LLFloaterGroupsOnly(); + static BOOL instanceVisible(const LLSD& id); + void onClose(bool app_quitting); + + static void* createGroupsPanel(void* data); +}; + + class LLFloaterChatterBox : public LLMultiFloater, public LLUISingleton { public: --- base\linden\indra\newview\llfloaterchatterbox.cpp 2007-08-02 14:16:00.000000000 +0100 +++ mod\linden\indra\newview\llfloaterchatterbox.cpp 2007-08-03 18:03:48.421331300 +0100 @@ -112,6 +112,76 @@ return new LLPanelGroups(); } +// LLFloaterFriendsOnly +// +LLFloaterFriendsOnly::LLFloaterFriendsOnly(const LLSD& seed) +{ + mFactoryMap["friends_panel"] = LLCallbackMap(LLFloaterFriendsOnly::createFriendsPanel, NULL); + BOOL no_open = FALSE; + gUICtrlFactory->buildFloater(this, "floater_friends.xml", &getFactoryMap(), no_open); +} + +//static +void* LLFloaterFriendsOnly::createFriendsPanel(void* data) +{ + return new LLPanelFriends(); +} + +LLFloaterFriendsOnly::~LLFloaterFriendsOnly() +{ +} + +// is the specified panel currently visible +//static +BOOL LLFloaterFriendsOnly::instanceVisible(const LLSD& id) +{ + // if singleton not created yet, trivially return false + if (!findInstance(id)) return FALSE; + + LLFloaterFriendsOnly* floaterp = getInstance(id); + return floaterp->isInVisibleChain(); +} + +void LLFloaterFriendsOnly::onClose(bool app_quitting) +{ + setVisible(FALSE); +} + +// LLFloaterGroupsOnly +// +LLFloaterGroupsOnly::LLFloaterGroupsOnly(const LLSD& seed) +{ + mFactoryMap["groups_panel"] = LLCallbackMap(LLFloaterGroupsOnly::createGroupsPanel, NULL); + BOOL no_open = FALSE; + gUICtrlFactory->buildFloater(this, "floater_groups.xml", &getFactoryMap(), no_open); +} + +LLFloaterGroupsOnly::~LLFloaterGroupsOnly() +{ +} + +//static +void* LLFloaterGroupsOnly::createGroupsPanel(void* data) +{ + return new LLPanelGroups(); +} + +// is the specified panel currently visible +//static +BOOL LLFloaterGroupsOnly::instanceVisible(const LLSD& id) +{ + // if singleton not created yet, trivially return false + if (!findInstance(id)) return FALSE; + + LLFloaterGroupsOnly* floaterp = getInstance(id); + return floaterp->isInVisibleChain(); +} + +void LLFloaterGroupsOnly::onClose(bool app_quitting) +{ + setVisible(FALSE); +} + // // LLFloaterChatterBox // --- base\linden\indra\newview\skins\xui\en-us\menu_viewer.xml 2007-08-02 14:16:00.000000000 +0100 +++ mod\linden\indra\newview\skins\xui\en-us\menu_viewer.xml 2007-08-03 15:39:43.562724600 +0100 @@ -258,8 +258,9 @@