From GordonWendt at gmail.com Thu May 1 00:43:33 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu May 1 00:43:37 2008 Subject: [sldev] SL Database purge In-Reply-To: <481968F6.7020700@streamsense.net> References: <48167279.4090204@streamsense.net> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> <1209610340.4950.92.camel@localhost> <481968F6.7020700@streamsense.net> Message-ID: <493033a70805010043r2c0121a1w6394e9a1dca9e689@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No wonder the servers have so many problems. - -G.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFIGXStqJF30JM0FpARAiGCAKCIaLXA5PXgp/DjFFS4C8b1wucpiACfdrYz +Fb3ykPsftfRqO8sslox1lM= =oO3x -----END PGP SIGNATURE----- On Thu, May 1, 2008 at 2:53 AM, Thomas Grimshaw wrote: > > Nay, linden equipment is running Windows 3.11 for Workgroups > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080501/46ad84ef/attachment.htm From secret.argent at gmail.com Thu May 1 03:29:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu May 1 03:29:10 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <48194634.6070207@lindenlab.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207@lindenlab.com> Message-ID: <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> On 2008-04-30, at 23:25, Dave Parks wrote: > You're mixing direct lighting and ambient occlusion. Actually, I'm talking about a different approach. > Ambient occlusion is the approximation of shadows that would be > generated if light was coming from all directions. Direct > shadowing (creating shadows from the sun) is done with hardware > shadow maps, which complements SSAO very well but is a totally > separate technique. Not trying to create shadows, just to get rid of the excessive directional lighting from the sun when you're "inside". If the sun isn't visible to the avatar, you could assume you're "inside" and fall back to primarily ambient lighting. From marvin24 at gmx.de Thu May 1 08:34:21 2008 From: marvin24 at gmx.de (Marvin) Date: Thu May 1 08:34:27 2008 Subject: [sldev] slviewer, gcc-4.3 and scons >= 0.98 In-Reply-To: <481888FB.9080804@lindenlab.com> References: <200804301642.09130.marvin24@gmx.de> <481888FB.9080804@lindenlab.com> Message-ID: <200805011734.21956.marvin24@gmx.de> Hi, On Wednesday 30 April 2008 16:58:03 Tofu Linden wrote: > Robin Cornelius wrote: > > If your going to invest any time with the build system and > > gcc compatibility throw it at cmake-8 (VWR-2871) the last i heard > > cmake was due to switch in any time now really but i assume its backed > > up behind 1.20.X, any updated estimates for going live? I'm not planning to fix 1.19, but 1.20 may also have this problem. So the quick and dirty fix for me is, to use the old scons version until cmake arrives. > It's still cycling through QA. I'm guessing it'll just miss 1.21, > but will likely land before 1.22. yes, the timeline is important here. SuSE is targeted for release June, 19., and Fedora 9 for May, 13. (both using scons 0.98). Ubuntu 8.04 seems still to use 0.97, but 8.10 may not. As this only affects people, who want to build slviewer by themself, this may not be a big problem anyway. Marvin From qarl at lindenlab.com Thu May 1 08:41:07 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Thu May 1 08:41:10 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <20080501065400.AB1EE41B089@stupor.lindenlab.com> References: <20080501065400.AB1EE41B089@stupor.lindenlab.com> Message-ID: <6077CFC5-8402-4E3F-B57F-658D6774EEDD@lindenlab.com> > poppy wrote: > > i cannot emphasize enough how hot this is. +1 From jay_reynolds_freeman at mac.com Thu May 1 09:14:54 2008 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Thu May 1 09:14:59 2008 Subject: [sldev] Sources for 1.19.1.4? (... again, sorry ...) In-Reply-To: <6077CFC5-8402-4E3F-B57F-658D6774EEDD@lindenlab.com> References: <20080501065400.AB1EE41B089@stupor.lindenlab.com> <6077CFC5-8402-4E3F-B57F-658D6774EEDD@lindenlab.com> Message-ID: <3D1E823A-F866-4680-B24A-266219117921@mac.com> I seem to recall this matter being discussed here before, and I apologize that I was not listening carefully: The sources for at least the Macintosh version of the 1.19.1.4 viewer, that are posted on http://wiki.secondlife.com/wiki/Source_downloads, appear to be incomplete; that is, the contents of the viewer "src" tarball are much smaller than for, say, 1.18.6.2. Where can I find the whole source? Or do I misunderstand the problem. Thank you for your indulgence. If the answer is simple and has been discussed before, let me hear from you off line, perhaps? -- Jay Reynolds Freeman / CeeJay Tigerpaw --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From soft at lindenlab.com Thu May 1 09:29:58 2008 From: soft at lindenlab.com (Soft) Date: Thu May 1 09:30:02 2008 Subject: [sldev] Sources for 1.19.1.4? (... again, sorry ...) In-Reply-To: <3D1E823A-F866-4680-B24A-266219117921@mac.com> References: <20080501065400.AB1EE41B089@stupor.lindenlab.com> <6077CFC5-8402-4E3F-B57F-658D6774EEDD@lindenlab.com> <3D1E823A-F866-4680-B24A-266219117921@mac.com> Message-ID: On Thu, May 1, 2008 at 11:14 AM, Jay Reynolds Freeman wrote: > I seem to recall this matter being discussed here before, and I apologize > that I was not listening carefully: > > The sources for at least the Macintosh version of the 1.19.1.4 viewer, that > are posted on http://wiki.secondlife.com/wiki/Source_downloads, appear to be > incomplete; that is, the contents of the viewer "src" tarball are much > smaller than for, say, 1.18.6.2. Where can I find the whole source? Or do > I misunderstand the problem. > > Thank you for your indulgence. If the answer is simple and has been > discussed before, let me hear from you off line, perhaps? I don't recall a discussion about this, and I show the 1.19.1.4 Mac/Linux source as 5.5 megs to 1.18.6.4 at 5.3 megs, or about 200k bigger for 1.19.1.4. They also untar just fine. Would you indicate exactly which file URLs you're seeing this with? From soft at lindenlab.com Thu May 1 10:26:13 2008 From: soft at lindenlab.com (Soft) Date: Thu May 1 10:26:18 2008 Subject: [sldev] Sources for 1.19.1.4? (... again, sorry ...) In-Reply-To: <45F38910-3ADF-4012-AF1A-6347DADCEBF7@mac.com> References: <20080501065400.AB1EE41B089@stupor.lindenlab.com> <6077CFC5-8402-4E3F-B57F-658D6774EEDD@lindenlab.com> <3D1E823A-F866-4680-B24A-266219117921@mac.com> <45F38910-3ADF-4012-AF1A-6347DADCEBF7@mac.com> Message-ID: On Thu, May 1, 2008 at 12:17 PM, Jay Reynolds Freeman wrote: > > On further reflection, I am beginning to suspect that what I have got > for 1.19.1.4 -- that is, what the Linden site provides -- is a delta off a > full build tree that I do not have; thus for example, when I search through > the untarred src tarball that I got by downloading 1.19.1.4, I do not even > find an "xcodeproj" file, which is the Mac development environment > equivalent of a "makefile" for building things. > > The content of my linden/indra directory for 1.18.6.2 is about 1.4 > GByte; the corresponding value for what comes as 1.19.1.4 is about 60 MByte. It sounds like maybe you pulled only the library file, but not the source or artwork files. In total you need to download three files, all of which untar/unzip into the same directory: https://wiki.secondlife.com/wiki/Source_downloads There are detailed build instructions for all platforms linked from here that should help out too: https://wiki.secondlife.com/wiki/Get_source_and_compile#Compiling From tulla at lindenlab.com Thu May 1 11:20:48 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi Linden)) Date: Thu May 1 11:20:55 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com><48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> Message-ID: <481A0A00.6000909@lindenlab.com> Argent Stonecutter wrote: > Not trying to create shadows, just to get rid of the excessive > directional lighting from the sun when you're "inside". If the sun > isn't visible to the avatar, you could assume you're "inside" and fall > back to primarily ambient lighting. There is no good way to do that as a half measure. If you don't calculate shadowing in general, you would get horrible flickering of the entire scene any time *anything* gets between your avatar and the sun, such as a lamp post or a tree. The only other real solution would be to manually define areas that are indoors vs outdoors, but doing that would actually be more problematic than just doing shadowing to begin with. So, we're back to actual shadowing, which is exactly what Dave is playing around with. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Quidquid latine dictum sit, altum sonatur." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric M. Tulla tulla@lindenlab.com Graphics Programmer From gwardell at gwsystemsdns.net Thu May 1 15:08:54 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Thu May 1 15:09:00 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481A0A00.6000909@lindenlab.com> Message-ID: <02fe01c8abd7$f2d23580$a400000a@gwsystems2.com> Well, it is a little odd to be in a cave or enclosed skybox with no visible source of light and yet there is light that seems to change with the day/night settings. While it's not all that inconceivable that there is some general illumination (just like on Star Trek or Dr Who all the aliens speak English) it would be even worse if there was a visible shadow in such enclosed spaces that indicating a pin point light source that isn't there. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Eric M. Tulla > (BigPapi Linden) > Sent: Thu, May 01, 2008 2:21 PM > To: SL-Dev > Subject: Re: [sldev] Google Summer of Code 2008 update > > > Argent Stonecutter wrote: > > Not trying to create shadows, just to get rid of the excessive > > directional lighting from the sun when you're "inside". If the sun > > isn't visible to the avatar, you could assume you're > "inside" and fall > > back to primarily ambient lighting. > There is no good way to do that as a half measure. If you don't > calculate shadowing in general, you would get horrible > flickering of the > entire scene any time *anything* gets between your avatar and the sun, > such as a lamp post or a tree. > > The only other real solution would be to manually define > areas that are > indoors vs outdoors, but doing that would actually be more problematic > than just doing shadowing to begin with. So, we're back to actual > shadowing, which is exactly what Dave is playing around with. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Quidquid latine dictum sit, altum sonatur." > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Eric M. Tulla > tulla@lindenlab.com > Graphics Programmer > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tom at streamsense.net Thu May 1 15:15:24 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu May 1 15:16:16 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481A0A00.6000909@lindenlab.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com><48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> Message-ID: <481A40FC.1080406@streamsense.net> Eric M. Tulla (BigPapi Linden) wrote: > The only other real solution would be to manually define areas that are > indoors vs outdoors Or at least provide some sort of facility to allow folk to specify how much the ambient lighting affects their texture.. Change "full bright" to a percentage slider? This may even be required if shadows are introduced, so people can reduce the contrast of shadows on particular floors if they need.. Tom/ From stephany at lindenlab.com Thu May 1 16:19:01 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Thu May 1 16:19:03 2008 Subject: [sldev] Landmarks and Navigation Update 2008-05-01 Message-ID: <481A4FE5.6070502@lindenlab.com> *Save the Date: Rx Office Hour 2008-05-08* * "What do I do now?!" * Next week, the topic of Benjamin Linden's weekly office hour (Thursdays at 3 PM Pacific in Beaumont) will be the *"What do I do now?!" problem. ** New residents need to be able to see what's happening right now, during their first few moments in Second Life, and determine if they're interested in joining. * This is a huge problem after you mull it over a bit, and we'd love your feedback. * If you cannot attend next week's office hour, please email me directly or just hit sldev@. *Landmarks and Navigation Project Update* * This past week's responses to the wireframes was positive. We received some great technical feedback. * There was obvious concern over the five-word limitation on Primary meta-tags, but we do not believe we're clear on the ability to use unlimited personal secondary tags. * We're currently reviewing how many words the Primary need to be. * We're still reviewing JIRA for open issues regarding landmarks and navigation, as well as Second Life-related blogs for opinions on UI, navigation, organization, landmarks, the Viewer, etc. * To date, we've talked with over 200 residents and are compiling that data. * We're also getting support from these residents in agreeing to review proposed solutions in the future. Thank you! * We're currently assessing the technical feasibility of adding metadata to landmarks and other inventory assets; if not we need to create a new data structure so, in the future, residents can tag friends and clothes, etc. * In the wireframes we still need to address where and how to "SHARE" * We'll have 3-4 completed wireframes (concepts) by the end of this week. * Vectorform will visit Linden Lab in mid-May to present work completed thus far, and so we can move on to choosing and building prototypes before code implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080501/dfece9b6/attachment.htm From aysz88 at gmail.com Thu May 1 16:38:37 2008 From: aysz88 at gmail.com (AySz88/Soup) Date: Thu May 1 16:38:39 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <02fe01c8abd7$f2d23580$a400000a@gwsystems2.com> References: <481A0A00.6000909@lindenlab.com> <02fe01c8abd7$f2d23580$a400000a@gwsystems2.com> Message-ID: On Thu, May 1, 2008 at 6:08 PM, Gary Wardell wrote: > Well, it is a little odd to be in a cave or enclosed skybox with no visible source of light and yet there is light that seems to > change with the day/night settings. > > While it's not all that inconceivable that there is some general illumination (just like on Star Trek or Dr Who all the aliens > speak English) it would be even worse if there was a visible shadow in such enclosed spaces that indicating a pin point light > source that isn't there. > The walls and ceilings of the cave/skybox would shadow the interior, so that interior surfaces will already be shadowed (i.e. they can't be 'doubly-shadowed'). Unless I've misunderstood what your concern is? -- ~Alex and Cel From seg at haxxed.com Thu May 1 19:44:20 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu May 1 19:44:27 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481A40FC.1080406@streamsense.net> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> Message-ID: <1209696260.12336.23.camel@localhost> On Thu, 2008-05-01 at 23:15 +0100, Thomas Grimshaw wrote: > Eric M. Tulla (BigPapi Linden) wrote: > > The only other real solution would be to manually define areas that are > > indoors vs outdoors > Or at least provide some sort of facility to allow folk to specify how > much the ambient lighting affects their texture.. > > Change "full bright" to a percentage slider? This may even be required > if shadows are introduced, so people can reduce the contrast of shadows > on particular floors if they need.. Ever seen the surface editors in something like Lightwave or Maya? Guess what SL is missing... :) Not to mention they support shader plugins. I still think the future lies in supporting user-supplied GLSL shaders... (This is the cue for the sldev peanut gallery to shout me down and explain how I'm an idiot for even suggesting such a thing.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080501/6f378248/attachment.pgp From secret.argent at gmail.com Thu May 1 20:07:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu May 1 20:07:15 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481A0A00.6000909@lindenlab.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com><48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> Message-ID: <4D4877D7-C939-49D4-B924-F8B821B21D0F@gmail.com> On 2008-05-01, at 13:20, Eric M. Tulla (BigPapi Linden) wrote: > Argent Stonecutter wrote: >> Not trying to create shadows, just to get rid of the excessive >> directional lighting from the sun when you're "inside". If the sun >> isn't visible to the avatar, you could assume you're "inside" and >> fall back to primarily ambient lighting. > There is no good way to do that as a half measure. If you don't > calculate shadowing in general, you would get horrible flickering > of the > entire scene any time *anything* gets between your avatar and the sun, > such as a lamp post or a tree. That's an obvious problem, with an obvious solution, which is to base the "indoors" versus "outdoors" view on a tunable "X% of the sky within Y% of the sun is hidden". This has already been discussed in the Jira. From davep at lindenlab.com Thu May 1 20:36:00 2008 From: davep at lindenlab.com (Dave Parks) Date: Thu May 1 20:35:56 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <1209696260.12336.23.camel@localhost> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> Message-ID: <481A8C20.1020502@lindenlab.com> That's sort of where this rendering architecture is heading. Long term, yes, we want some way to let users specify their own materials (with shader code), but in an uncontrolled environment like Second Life, that's not a simple task. Besides the problem of protecting against malicious/poorly written shader code, you've got issues of scene complexity, overdraw, limited number of light sources, etc. In the mean time, you're going to see us push more shaders into the viewer that are custom fitted and hand written until we know exactly what context a shader driven material system will live in in our community, what techniques scale well with user created content, how to preserve the overall look of a material across a wide variety of hardware, etc. When that's done, it will be time to take a good look at how to enable residents to create their own custom shaders that fit into that framework. Callum Lerwick wrote: > Ever seen the surface editors in something like Lightwave or Maya? Guess > what SL is missing... :) Not to mention they support shader plugins. I > still think the future lies in supporting user-supplied GLSL shaders... > > (This is the cue for the sldev peanut gallery to shout me down and > explain how I'm an idiot for even suggesting such a thing.) > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tulla at lindenlab.com Fri May 2 07:18:05 2008 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi Linden)) Date: Fri May 2 07:18:13 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <4D4877D7-C939-49D4-B924-F8B821B21D0F@gmail.com> References: <4818F526.8030704@lindenlab.com><4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com><48194634.6070207@lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com><481A0A00.6000909@lindenlab.com> <4D4877D7-C939-49D4-B924-F8B821B21D0F@gmail.com> Message-ID: <481B229D.1000602@lindenlab.com> Argent Stonecutter wrote: > On 2008-05-01, at 13:20, Eric M. Tulla (BigPapi Linden) wrote: >> There is no good way to do that as a half measure. If you don't >> calculate shadowing in general, you would get horrible flickering of the >> entire scene any time *anything* gets between your avatar and the sun, >> such as a lamp post or a tree. > That's an obvious problem, with an obvious solution, which is to base > the "indoors" versus "outdoors" view on a tunable "X% of the sky > within Y% of the sun is hidden". This has already been discussed in > the Jira. Yes, that is an "obvious" solution, but that doesn't mean it's a computationally simple one. Abstractly knowing the percent of the sky that is hidden even within some smaller angle of the sun is easy for the human brain to know at a glance, but not even remotely easy to do within the context of 3d rendering. The complexity of calculating that on the fly would be similar to or worse than just calculating proper shadowing, which is what we're working on. This is one of those rare cases where the better looking solution can be made to run faster than other theoretically simpler but uglier solutions. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Quidquid latine dictum sit, altum sonatur." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric M. Tulla tulla@lindenlab.com Graphics Programmer Linden Lab From monkowsk at watson.ibm.com Fri May 2 08:21:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri May 2 08:25:21 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <1209696260.12336.23.camel@localhost> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> Message-ID: <481B3172.4080702@watson.ibm.com> Callum Lerwick wrote: > Ever seen the surface editors in something like Lightwave or Maya? Guess > what SL is missing... :) Not to mention they support shader plugins. I > still think the future lies in supporting user-supplied GLSL shaders... > > (This is the cue for the sldev peanut gallery to shout me down and > explain how I'm an idiot for even suggesting such a thing.) I don't understand why you would expect to be shouted down. I don't remember anyone objecting to plugins before. I don't know if there's been any discussion about shader plugins specifically, but shaders are just code. You have access to all of the GLSL code for the viewer. The only argument you might get is that you say "the future" and I would suggest it should be "the present." Why wait? Mike From qarl at lindenlab.com Fri May 2 08:53:34 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Fri May 2 08:53:36 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <20080502152523.BB54A41B3F1@stupor.lindenlab.com> References: <20080502152523.BB54A41B3F1@stupor.lindenlab.com> Message-ID: <77D77D6C-30F9-4B5E-9BE0-632F13A51D1B@lindenlab.com> > Callum Lerwick wrote: > Ever seen the surface editors in something like Lightwave or Maya? > Guess > what SL is missing... :) Not to mention they support shader plugins. I > still think the future lies in supporting user-supplied GLSL > shaders... i hear ya, brother. that is in fact the (long term) plan. probably via some nifty shader-editor system, ala mental mill or somesuch. http://www.mentalimages.com/2_4_mentalmill/index.html K. From jeska at lindenlab.com Fri May 2 10:35:26 2008 From: jeska at lindenlab.com (Jeska Dzwigalski) Date: Fri May 2 10:33:45 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! Message-ID: <481B50DE.8080500@lindenlab.com> Hello! You've been asking us to do better with inappropriate content and content classification and we've been listening. In an effort to make our abuse reporting system easier to access and more effective, we are planning to introduce a flagging system for our search results - and we'd love to get your feedback. The new flagging system will help Residents to flag inappropriate postings for rapid removal, while preserving everyone's ability to express themselves freely in world. *How it will work* * First, when you post a classified, group, event or parcel listing, you will have to self-declare if your content is mature or not. * Second, every listing will have a "Flag This" link. You can use this to report inappropriate or mis-classified content or nominate great content for the showcase. *Flag Categories* * Mature - /the listing is adult only content/ * Prohibited - /the listing contains content that is prohibited on SL/ * Spam - /irrelevant listings (examples: commercial posts in non-commercial venues, event postings for non-events)/ * Showcase - /nominate something for possible inclusion in the Second Life Showcase/ (http://secondlife.com/showcase)// /[All listings will still have to follow the Community Standards and Terms of Service .]/ *Types of listings that can be flagged* * Parcel listings * Classifieds * Events * You will not be able to flag avatar or group profiles *What happens when something is flagged* * Every flag counts as one vote for that flag category. While one (or few) votes does nothing, if a listing receives enough votes in that category, it will be auto-classified as reported. * Prohibited and spam content will be taken down immediately when it gets enough votes * When content is flagged several times, the content owner will be notified by SL support team and may be penalized according to Community Standards *Anything else?* * Residents will be allowed to flag a particular search listing only once. You cannot change your vote, so flag with care * There will be a limit to how many times a day a Resident can flag search listings * Anonymous basic residents or residents whose accounts are less than x days old will not be able to flag content * Residents will still be able to report abusive content from inworld via the Abuse Reporting system under the Help menu * Of course, no system can be perfect, so if you think something was flagged in error, you can always file a support ticket for review Thats it. We hope that this will make content flagging more effective and will help the community better regulate what is appropriate and what is not. Please reply to this email with your thoughts and feedback on this proposed design! Cheers, Jeska, Kalpana and the LL Search Team -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/860cb3c5/attachment.htm From zak.escher at gmail.com Fri May 2 10:40:55 2008 From: zak.escher at gmail.com (Zak Escher) Date: Fri May 2 10:41:00 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B50DE.8080500@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> Message-ID: <481B5227.4060703@gmail.com> Will there be any consequences for abusively flagging listings? ----- Zak From tom at streamsense.net Fri May 2 10:41:29 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri May 2 10:42:06 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B5227.4060703@gmail.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> Message-ID: <481B5249.3080700@streamsense.net> Zak Escher wrote: > Will there be any consequences for abusively flagging listings? Yes, my question too. The abuse reporting system has been obscenely misused as a griefing tool for a long time, i'd rather not add to this. Tom From jeska at lindenlab.com Fri May 2 11:02:08 2008 From: jeska at lindenlab.com (Jeska Dzwigalski) Date: Fri May 2 11:00:28 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B5249.3080700@streamsense.net> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> Message-ID: <481B5720.3030605@lindenlab.com> Heya! Repeatedly misusing/abusing the flagging tool (for example to target a particular Resident) would be considered harassment and handled by the Governance team per the Community Standards. Anyone else have thoughts or questions on the design? Cheers, Jeska Thomas Grimshaw wrote: > Zak Escher wrote: >> Will there be any consequences for abusively flagging listings? > Yes, my question too. > > The abuse reporting system has been obscenely misused as a griefing > tool for a long time, i'd rather not add to this. > > Tom > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- From me at signpostmarv.name Fri May 2 11:03:19 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri May 2 11:03:23 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B50DE.8080500@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> Message-ID: <481B5767.5080404@signpostmarv.name> Will there be any indication that content has been removed ? According to my records, there are 152,739 events IDs that "don't exist", and no reason for their non-existence is given. I suppose it's also good timing that I've just recently implemented SVC-184 and WEB-637 myself :-P (see http://marvulous.co.uk/event-flagging/ and http://svc.sl.net.marvulous.co.uk/event/1399 ) It would be handy for third party sites like sw.slr if the resources for flagging content was predictable and non-obfuscated, so that content reporting is handled by the first-party service rather than the third-party service. Jeska Dzwigalski wrote: > > The new flagging system will help Residents to flag inappropriate > postings for rapid removal, while preserving everyone's ability to > express themselves freely in world. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080502/072e3fd4/smime.bin From annagulaev at gmail.com Fri May 2 12:29:48 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 12:29:52 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt Message-ID: Building the linux client for the first time in a long time. Essentially starting from scratch from the 1.20RC5 source. I seem to be missing the library libboost_signals-gcc34-mt It is not in the easy linux dependencies, and it is not included in an install of libboost-dev and libboost-regex-dev. Can someone please tell me where this is supposed to be, and how it was supposed to have gotten there? Ubuntu 8.04 g++-3.4 -o linux_crash_logger/linux-crash-logger-i686-bin-globalsyms -m32 --no-keep-memory --reduce-memory-overheads /tmp/amy/home/amy/sl/1.20.rc5/linden/indra/i686-linux-client-release/llcrashlogger/llcrashlogger.o /tmp/amy/home/amy/sl/1.20.rc5/linden/indra/i686-linux-client-release/linux_crash_logger/linux_crash_logger.o /tmp/amy/home/amy/sl/1.20.rc5/linden/indra/i686-linux-client-release/linux_crash_logger/llcrashloggerlinux.o -Llib_release_client/i686-linux -L/home/amy/sl/1.20.rc5/linden/libraries/i686-linux/lib_release_client -L/home/amy/sl/1.20.rc5/linden/libraries/i686-linux -lllui -lllxml -lllmessage -lllvfs -lllmath -lllcommon -lcurl -lssl -lcrypto -laprutil-1 -lapr-1 -lcares -lexpat -ldb-4.2 -lgtk-x11-2.0 -lboost_signals-gcc34-mt /usr/bin/ld: cannot find -lboost_signals-gcc34-mt collect2: ld returned 1 exit status scons: *** [linux_crash_logger/linux-crash-logger-i686-bin-globalsyms] Error 1 scons: building terminated because of errors. Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/52800a02/attachment.htm From annagulaev at gmail.com Fri May 2 12:46:01 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 12:46:03 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481A40FC.1080406@streamsense.net> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> Message-ID: On Thu, May 1, 2008 at 6:15 PM, Thomas Grimshaw wrote: > Eric M. Tulla (BigPapi Linden) wrote: > > > The only other real solution would be to manually define areas that are > > indoors vs outdoors > > > Or at least provide some sort of facility to allow folk to specify how > much the ambient lighting affects their texture.. I always thought it'd be a good half-solution to allow builders to define a volume (a prim) as "indoor space". So, you'd place a few large prims inside your building to roughly fill the space (including the interior wall surfaces, but not the exterior), make them fully transparent, flag them as "interior volume", and any surface that was fully within one of those volumes would not receive sun/moon lighting or any local lighting that originated outside the volume. Likewise, any local light sources within one of these volumes would not effect any surfaces rendered outside. You'd probably also have to define an ambient light level for each volume. And, to avoid driving people nuts with camera goofiness, the volumes would be ignored by mouse/camera controls except in edit mode. But real shadows is even better. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/a88fb5d4/attachment.htm From darien_caldwell at comcast.net Fri May 2 12:48:44 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Fri May 2 12:48:47 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! Message-ID: <050220081948.2252.481B701C00015795000008CC221655140604040A990B040E0CA1020A079D0E0B@comcast.net> I am unsure how well this will function, given there are no solid 'rules' defining what constitutes Mature content. In other words, what one person considers Mature, another may not. And some are on a crusade to wipe out any and all Mature content from Second Life, They come and AR things in my sim on occasion, which I see thanks to the new abuse handling on Private Estates. This would simply be another tool in their arsenal to make SL a G rated environment. If this is implemented, there needs to be some pretty clear guidelines as to what is Mature, and what is not, IMHO -------------- Original message ---------------------- From: Jeska Dzwigalski > Heya! > > Repeatedly misusing/abusing the flagging tool (for example to target a > particular Resident) would be considered harassment and handled by the > Governance team per the Community Standards. > > Anyone else have thoughts or questions on the design? > > Cheers, > Jeska > > > Thomas Grimshaw wrote: > > Zak Escher wrote: > >> Will there be any consequences for abusively flagging listings? > > Yes, my question too. > > > > The abuse reporting system has been obscenely misused as a griefing > > tool for a long time, i'd rather not add to this. > > > > Tom > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Lab > jeska@lindenlab.com > http://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- From kfa at gmx.net Fri May 2 14:30:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri May 2 14:30:37 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B50DE.8080500@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> Message-ID: <481B87DB.6070001@gmx.net> I'm afraid this is like shouting against a tidal wave, and maybe off topic on a dev list. But since feedback is asked I have to seize the opportunity and say my opinion anyway. While appreciating LL's efforts to listen to the user community, it's that community that has me worried much more in this context. I am truly appalled by this correctness craze. People seem to be more scared of a breast popping on their screen than of nuclear bombs or legal systems going haywire. Maybe it has to do with where one comes from... but whenever I see such a thing being considered, I get a flashback of the so-called German Democratic Republic, where half the population made sure that the other half toed the line. To cut a long rant short, I am against any flagging, rating or other system that facilitates and encourages public denounciation of perceived aberrations. The only ones who should get a say in this matter are the immediate neighbours of a parcel, or those living in the same region or within visible render distance. Whether it's about the PG/Mature distinction or any individual local standard, the general public should not get to enforce a regional rule. But there seem to be so many people actually wanting this that we are led to believe applying the rule of democracy is the only right thing to do. Then I'm again reminded that democracy and liberty are two completely different things - even "good" democracies have the potential to turn hostile against minority opinions and forms of expression. If I don't like a place I have the liberty to go elsewhere, only their neighbours can't so easily, that's why they alone may object. Generally, the liberty of the creator weighs higher than the casual visitor's individual taste or decency threshold. But that seems to be just my lone opinion these days. Can't anyone see that we're going back to the middle ages when we didn't know to distinguish moral and criminal code...? Felix Jeska Dzwigalski wrote: > Hello! > > You've been asking us to do better with inappropriate content and > content classification and we've been listening. In an effort to make > our abuse reporting system easier to access and more effective, we are > planning to introduce a flagging system for our search results - and > we'd love to get your feedback. > > ... From seg at haxxed.com Fri May 2 14:30:40 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri May 2 14:30:48 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B5720.3030605@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> Message-ID: <1209763840.12336.66.camel@localhost> On Fri, 2008-05-02 at 11:02 -0700, Jeska Dzwigalski wrote: > Heya! > > Repeatedly misusing/abusing the flagging tool (for example to target a > particular Resident) would be considered harassment and handled by the > Governance team per the Community Standards. > > Anyone else have thoughts or questions on the design? Even one flagging should queue the listing for human review, by a team of people trained for such work, trusted and empowered to make the final decision in such matters. The listing remains up, the human reviewers can either take it down, or whitelist it as having been reviewed and deemed acceptable. If it gets more than X flags, then it gets automatically taken down, and it still goes to a human review team. They can either let the withdrawal stand, or put it back up and whitelist it as being reviewed and deemed acceptable. The idea is to keep a trusted human being in the loop, as only a human being can make a decision as to if a listing is legitimate, controversial but legitimate, or a victim of griefing. Last I checked the AI problem hasn't been solved. And in turn, the review team can review a user's flagging history, and revoke flagging privileges, or ban them altogether if a history of abuse is apparent. Also the idea is the review team doesn't have to review every single listing, which would have major scaling issues, only the ones the community calls in to question. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080502/fdec3ed6/attachment.pgp From matthew.dowd at hotmail.co.uk Fri May 2 14:39:36 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 14:39:38 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <050220081948.2252.481B701C00015795000008CC221655140604040A990B040E0CA1020A079D0E0B@comcast.net> References: <050220081948.2252.481B701C00015795000008CC221655140604040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: More importantly clearer guidelines on what is prohibited for similar reasons! There was never any clarification of the contradiction between Daniel Linden's blog post stating that "other broadly offensive content are never allowed or tolerated within Second Life" and the Community Standards (written, I gather, by Daniel Linden) which states "anything else broadly offensive must be contained within private land in areas rated Mature (M)", and as Darien says, some groups took this as an invitation to AR anything they didn't like. Also how many votes contribute enough to take action. It would be quite easy for a group to organise themselves to all vote to prohibit things they didn't like or agree with. I think social tagging may have a role in determining search relevancy - but I'm not convinced this tagging would work particularly well. Matthew > From: darien_caldwell@comcast.net> To: jeska@lindenlab.com; sldev@lists.secondlife.com> Subject: Re: [sldev] Your Feedback Wanted on Search Flagging !> Date: Fri, 2 May 2008 19:48:44 +0000> > > I am unsure how well this will function, given there are no solid 'rules' defining what constitutes Mature content. > In other words, what one person considers Mature, another may not. And some are on a crusade to wipe out any and all> Mature content from Second Life, They come and AR things in my sim on occasion, which I see thanks to the new abuse handling on Private Estates. > This would simply be another tool in their arsenal to make SL a G rated environment. > > If this is implemented, there needs to be some pretty clear guidelines as to what is Mature, and what is not, IMHO> > > -------------- Original message ----------------------> From: Jeska Dzwigalski > > Heya!> > > > Repeatedly misusing/abusing the flagging tool (for example to target a> > particular Resident) would be considered harassment and handled by the> > Governance team per the Community Standards.> > > > Anyone else have thoughts or questions on the design?> > > > Cheers,> > Jeska> > > > > > Thomas Grimshaw wrote:> > > Zak Escher wrote:> > >> Will there be any consequences for abusively flagging listings?> > > Yes, my question too.> > >> > > The abuse reporting system has been obscenely misused as a griefing> > > tool for a long time, i'd rather not add to this.> > >> > > Tom> > > _______________________________________________> > > Click here to unsubscribe or manage your list subscription:> > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> > > > -- > > ------------------------> > Jeska Dzwigalski> > Community and Product Development, Linden Lab> > jeska@lindenlab.com> > http://www.secondlife.com> > Visit my Office in Second Life: http://tinyurl.com/nmhsa> > -------------------------> > > _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ All new Live Search at Live.com http://clk.atdmt.com/UKM/go/msnnkmgl0010000006ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/b5fe286a/attachment-0001.htm From tom at streamsense.net Fri May 2 14:39:01 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri May 2 14:39:42 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B87DB.6070001@gmx.net> References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> Message-ID: <481B89F5.2070509@streamsense.net> Felix Duesenburg wrote: > Can't > anyone see that we're going back to the middle ages when we didn't know > to distinguish moral and criminal code...? > > Felix > Felix, I very much agree with your sentiments, however we do unfortunately still live in a world where some people are backwards enough to need people to censor content for them. Some people see it as a basic human right to be able to experience content without the possibility of coming accross material which they happen to find offensive. Unfortunately, material censorship is usually extremely biased. Personally, I find religious content more offensive and / or unacceptable than adult content. But then, I don't censor myself, I just ignore it. However.. all in all, this is distracting from the point that some content is against the terms of service (and also morally/legally unacceptable). This is completely seperate from the "mature content" flagging. If you noticed some child pornography listed, for example, you'd probably like a method of reporting it swiftly and in an efficient manner to the lindens. Tom. From matthew.dowd at hotmail.co.uk Fri May 2 14:44:55 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 14:44:57 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209763840.12336.66.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> Message-ID: > If it gets more than X flags, then it gets> automatically taken down, and it still goes to a human review team. All you need is a co-ordinated group of X+1 people determined to remove say anyone selling sculpties (or a more realistic prejudice), for them to at least temporarily get sites removed. Effectively, such an approach is a "guilty until proven innocent" one. Matthew _________________________________________________________________ Win Indiana Jones prizes with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/9fb0f376/attachment.htm From tom at streamsense.net Fri May 2 14:49:35 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri May 2 14:50:14 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> Message-ID: <481B8C6F.4060209@streamsense.net> Matthew Dowd wrote: > > All you need is a co-ordinated group of X+1 people determined to > remove say anyone selling sculpties (or a more realistic prejudice), > for them to at least temporarily get sites removed. Effectively, such > an approach is a "guilty until proven innocent" one. > > Matthew Indeed, and this is the tactic used to harass many people in second life right now, particuarly with "age verification". Always guilty until proven innocent, so what an excellent tool to knock someone out of second life whom you don't particuarly agree with? Or, in this case, content.. And don't tell me that the lindens review each case, I was banned twice in the space of three weeks due to some unfounded malicious "under age" reports (after I had already verified my age, no less). A flag doesn't need to be repetitive in order to be abusive, and to cause damage. Tom. From kfa at gmx.net Fri May 2 14:53:27 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri May 2 14:53:54 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B89F5.2070509@streamsense.net> References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> <481B89F5.2070509@streamsense.net> Message-ID: <481B8D57.5040707@gmx.net> Thomas Grimshaw wrote: > > However.. all in all, this is distracting from the point that some > content is against the terms of service (and also morally/legally > unacceptable). This is completely seperate from the "mature content" > flagging. If you noticed some child pornography listed, for example, > you'd probably like a method of reporting it swiftly and in an efficient > manner to the lindens. > > Tom. > But we have that for a long time, and I don't see what's amiss with the existing abuse report system. I have filed some myself (mostly griefers) and found it easy to use, and the reaction was swift. If there is some truly illegal content, then we don't need a threshold value composed of N flags or whatever. One report is enough to trigger investigation and action if found necessary. From matthew.dowd at hotmail.co.uk Fri May 2 14:54:07 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 14:54:11 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B89F5.2070509@streamsense.net> References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> <481B89F5.2070509@streamsense.net> Message-ID: > However.. all in all, this is distracting from the point that some > content is against the terms of service (and also morally/legally > unacceptable). This is completely seperate from the "mature content" > flagging. If you noticed some child pornography listed, for example, > you'd probably like a method of reporting it swiftly and in an efficient > manner to the lindens. Unfortunately it isn't quite as black and white. Whilst, clearly child pornography is prohibited content - when LL asked people to be vigilante about child pornography (partly due to the badly chosen phrase of "age play"), many got ARed for being child avatars or being called Lolita etc.. Hence I could quite imagine children clothes stores, and Gothic Lolita stores getting a relative high number of "prohibited" flags even though these are not prohibited (by people misunderstanding rather than necessarily deliberately grieffing). Matthew _________________________________________________________________ Win Indiana Jones prizes with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/9b524f0a/attachment.htm From matthew.dowd at hotmail.co.uk Fri May 2 14:59:09 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 14:59:11 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B8C6F.4060209@streamsense.net> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <481B8C6F.4060209@streamsense.net> Message-ID: > And don't tell me that the lindens review each case, I was > banned twice in the space of three weeks due to some unfounded malicious > "under age" reports (after I had already verified my age, no less). Off topic, but the increasingly common stories of people being banned due to a false underage AR is worrying (despite having age verified or even faxed proof of age to LL previously) - I work in the education sector, and could quite imagine students thinking it a prank to underage AR their tutor! Matthew _________________________________________________________________ Great deals on almost anything at eBay.co.uk. Search, bid, find and win on eBay today! http://clk.atdmt.com/UKM/go/msnnkmgl0010000004ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/a83cf846/attachment.htm From innes at siriusm.com Fri May 2 15:03:28 2008 From: innes at siriusm.com (Innes McLeod) Date: Fri May 2 15:03:32 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! References: <481B50DE.8080500@lindenlab.com> Message-ID: <018201c8aca0$5a660780$6601a8c0@Topaz> I have some reservations about this system. It seems to me that, as has been mentioned, it can be abused to harass. To prevent it's use as harassment, you will have to add load to the database to record where every vote came from. The same will apply to the Showcase nominations. I can foresee hundreds of alts being created just for the sole purpose of voting up a single business. As it stands even with that system, if I see something that I feel is a serious offense I would still send a normal AR, instead of waiting for enough people to notice and hopefully cast their votes for the removal of the offending content. Generally, I only report for very obvious hate speech, or child related sexual material, and in my opinion both of those are to important to just have them sit waiting for enough votes. Something I would rather see would be an expansion of the categories that products or parcels can be listed under. ----- Original Message ----- From: Jeska Dzwigalski To: sldev@lists.secondlife.com Sent: Friday, May 02, 2008 12:35 PM Subject: [sldev] Your Feedback Wanted on Search Flagging ! Hello! You've been asking us to do better with inappropriate content and content classification and we've been listening. In an effort to make our abuse reporting system easier to access and more effective, we are planning to introduce a flagging system for our search results - and we'd love to get your feedback. The new flagging system will help Residents to flag inappropriate postings for rapid removal, while preserving everyone's ability to express themselves freely in world. How it will work a.. First, when you post a classified, group, event or parcel listing, you will have to self-declare if your content is mature or not. b.. Second, every listing will have a "Flag This" link. You can use this to report inappropriate or mis-classified content or nominate great content for the showcase. Flag Categories a.. Mature - the listing is adult only content b.. Prohibited - the listing contains content that is prohibited on SL c.. Spam - irrelevant listings (examples: commercial posts in non-commercial venues, event postings for non-events) d.. Showcase - nominate something for possible inclusion in the Second Life Showcase (http://secondlife.com/showcase) [All listings will still have to follow the Community Standards and Terms of Service.] Types of listings that can be flagged a.. Parcel listings b.. Classifieds c.. Events d.. You will not be able to flag avatar or group profiles What happens when something is flagged a.. Every flag counts as one vote for that flag category. While one (or few) votes does nothing, if a listing receives enough votes in that category, it will be auto-classified as reported. b.. Prohibited and spam content will be taken down immediately when it gets enough votes c.. When content is flagged several times, the content owner will be notified by SL support team and may be penalized according to Community Standards Anything else? a.. Residents will be allowed to flag a particular search listing only once. You cannot change your vote, so flag with care b.. There will be a limit to how many times a day a Resident can flag search listings c.. Anonymous basic residents or residents whose accounts are less than x days old will not be able to flag content d.. Residents will still be able to report abusive content from inworld via the Abuse Reporting system under the Help menu e.. Of course, no system can be perfect, so if you think something was flagged in error, you can always file a support ticket for review Thats it. We hope that this will make content flagging more effective and will help the community better regulate what is appropriate and what is not. Please reply to this email with your thoughts and feedback on this proposed design! Cheers, Jeska, Kalpana and the LL Search Team -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- ------------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev ------------------------------------------------------------------------------ No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 8:02 AM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/617fe00f/attachment-0001.htm From kfa at gmx.net Fri May 2 15:06:08 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri May 2 15:06:35 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B8D57.5040707@gmx.net> References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> <481B89F5.2070509@streamsense.net> <481B8D57.5040707@gmx.net> Message-ID: <481B9050.2010200@gmx.net> Ok I don't want to criticize without following up with a more constructive idea: Instead of a negative rating system, can't we have a positive one? Such a thing once was in place already, with the rating system for avatars. It was scrapped just around the time when I first came, but I met older users who were quite sad about it going away because it had cost them a lot of work to build up their excellent rating. What if we had that for places now, and could give points possibly even for several criteria, like artistic quality, informational or educational value, or whatever? We have too many systems in our life for gathering demerit points and too few for merit points! Felix From robla at lindenlab.com Fri May 2 15:15:46 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri May 2 15:15:48 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481B5720.3030605@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com><481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> Message-ID: <481B9292.4080608@lindenlab.com> Hi all, Let me ask this another way. Is anyone aware of published research or other helpful information in this area that may not have been considered in the original design? Big bonus points if you can actually provide helpful quotes from that research that are relevant to the proposed design. Rob On 5/2/08 11:02 AM, Jeska Dzwigalski wrote: > Heya! > > Repeatedly misusing/abusing the flagging tool (for example to target a > particular Resident) would be considered harassment and handled by the > Governance team per the Community Standards. > > Anyone else have thoughts or questions on the design? > > Cheers, > Jeska > > > Thomas Grimshaw wrote: > >> Zak Escher wrote: >> >>> Will there be any consequences for abusively flagging listings? >>> >> Yes, my question too. >> >> The abuse reporting system has been obscenely misused as a griefing >> tool for a long time, i'd rather not add to this. >> >> Tom >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > From annagulaev at gmail.com Fri May 2 15:27:42 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 15:27:43 2008 Subject: [sldev] [VWR] fmod.dll not found Message-ID: I've built the 1.20 RC5 viewer for Windows and it runs from within visual studio, but it doesn't run by double-clicking its icon. 1) I get "the application has failed to start because fmod.dll was not found". 2) fmod.dll is in the linden/indra/newview directory; the same relative-to-the-executable place it is in version 1.18.4.3 I've been working with for months. 3) The executable I'm trying to run is newview.exe, located in linden/indra/newview/Release Is there something I failed to do to make the executable look for this DLL in the same place the last version looked for it? Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/908cf78f/attachment.htm From carjay at gmx.net Fri May 2 15:45:34 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri May 2 15:45:40 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: References: Message-ID: <481B998E.5090207@gmx.net> Anna Gulaev wrote: > I seem to be missing the library libboost_signals-gcc34-mt > > It is not in the easy linux dependencies, and it is not included in an > install of libboost-dev and libboost-regex-dev. Can someone please > tell me where this is supposed to be, and how it was supposed to have > gotten there? > > Ubuntu 8.04 Not sure why it's not in the libs package but linking against the system provided libbosts should be no problem. You just have to remove the "gcc34" reference in the SConstruct to be able to link against the system libraries. For example: 'boost_signals-gcc34-mt' needs to become 'boost_signals-mt' There are several references in the SConstruct but they all work like this. Regards, Carsten From annagulaev at gmail.com Fri May 2 15:56:59 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 15:57:01 2008 Subject: [sldev] Re: [VWR] fmod.dll not found In-Reply-To: References: Message-ID: On 5/2/08, Anna Gulaev wrote: > > I've built the 1.20 RC5 viewer for Windows and it runs from within visual > studio, but it doesn't run by double-clicking its icon. > > 1) I get "the application has failed to start because fmod.dll was not > found". > 2) fmod.dll is in the linden/indra/newview directory; the same > relative-to-the-executable place it is in version 1.18.4.3 I've been > working with for months. > 3) The executable I'm trying to run is newview.exe, located in > linden/indra/newview/Release I've noted the following similarities and differences in the fmod.dll that this version is using vs the last version. 1) Its checksum is identical; that is, it is binary identical 2) It has today's date, whereas the last version's copy has a 2005 date. So, I copy-n-pasted it through windows rather than cp-ing it through cygwin. Not that I expected that to make a difference given #1. This, and also using the -p option on cp within cygwin, provided a copy with the desired timestamp, and it still didn't work. 3) The attributes properties reported by windows are identical. 4) The permissions flags in a long directory listing, no matter how I make the copy, look like this... -rwx------ wheras the previous version looks like this... -rwx------+ What is the plus-sign on the end? This is the only file in this directory that lacks it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/cee02e52/attachment.htm From annagulaev at gmail.com Fri May 2 16:27:02 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 16:27:03 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <481B998E.5090207@gmx.net> References: <481B998E.5090207@gmx.net> Message-ID: I don't have a boost_signals-mt on my system, either. After installing libboost-dev and libboost-regex-dev, here is a complete list of all files on my system that contain "boost": ./var/lib/dpkg/info/libboost-regex-dev.md5sums ./var/lib/dpkg/info/libboost-regex1.34.1.list ./var/lib/dpkg/info/libboost-regex1.34.1.shlibs ./var/lib/dpkg/info/libboost-regex1.34.1.md5sums ./var/lib/dpkg/info/libboost-regex1.34.1.postinst ./var/lib/dpkg/info/libboost-regex1.34.1.postrm ./var/lib/dpkg/info/libboost-regex-dev.list ./var/lib/dpkg/info/libboost-dev.list ./var/lib/dpkg/info/libboost-dev.md5sums ./var/cache/apt/archives/libboost-dev_1.34.1-4ubuntu3_i386.deb ./var/cache/apt/archives/libboost-regex1.34.1_1.34.1-4ubuntu3_i386.deb ./var/cache/apt/archives/libboost-regex-dev_1.34.1-4ubuntu3_i386.deb ./usr/share/doc/libboost-regex1.34.1 ./usr/share/doc/libboost-regex-dev ./usr/share/doc/libboost-dev ./usr/share/lintian/overrides/libboost-regex1.34.1 ./usr/share/lintian/overrides/libboost-dev ./usr/lib/libboost_regex-gcc41-mt-1_34_1.so.1.34.1 ./usr/lib/libboost_regex-gcc42-mt-1_34_1.so.1.34.1 ./usr/lib/libboost_regex-gcc42-mt-1_34_1.a ./usr/lib/libboost_regex-mt.a ./usr/lib/libboost_regex-gcc42-mt-1_34_1.so ./usr/lib/libboost_regex-gcc42-1_34_1.a ./usr/lib/libboost_regex.so ./usr/lib/libboost_regex-mt.so ./usr/lib/libboost_regex-gcc42-1_34_1.so ./usr/lib/libboost_regex-gcc42-1_34_1.so.1.34.1 ./usr/lib/libboost_regex.a ./usr/lib/libboost_regex-gcc41-1_34_1.so.1.34.1 ./usr/include/c++/3.4/bits/boost_concept_check.h ./usr/include/boost ./usr/src/linux-headers-2.6.24-16/scripts/rt-tester/t5-l4-pi-boost-deboost.tst ./usr/src/linux-headers-2.6.24-16/scripts/rt-tester/t4-l2-pi-deboost.tst ./usr/src/linux-headers-2.6.24-16/scripts/rt-tester/t5-l4-pi-boost-deboost-setsched.tst ~/sl/1.20.rc5/linden/libraries/include/boost ~/sl/1.20.rc5/linden/indra/llcommon/llboost.h On Fri, May 2, 2008 at 6:45 PM, Carsten Juttner wrote: > Anna Gulaev wrote: > > > I seem to be missing the library libboost_signals-gcc34-mt > > > > It is not in the easy linux dependencies, and it is not included in an > > install of libboost-dev and libboost-regex-dev. Can someone please tell me > > where this is supposed to be, and how it was supposed to have gotten there? > > > > Ubuntu 8.04 > > > > Not sure why it's not in the libs package but linking against the system > provided libbosts should be no problem. > > You just have to remove the "gcc34" reference in the SConstruct to be able > to link against the system libraries. > > For example: > 'boost_signals-gcc34-mt' needs to become 'boost_signals-mt' > > There are several references in the SConstruct but they all work like > this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/16499d4a/attachment.htm From carjay at gmx.net Fri May 2 16:41:00 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri May 2 16:41:02 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: References: <481B998E.5090207@gmx.net> Message-ID: <481BA68C.6020203@gmx.net> Anna Gulaev wrote: > I don't have a boost_signals-mt on my system, either. After installing > libboost-dev and libboost-regex-dev, here is a complete list of all > files on my system that contain "boost": I use Kubuntu 7.10 (Gutsy) and here the boost signals library is in a separate package called libboost-signals-dev Guess it's still the same for 8.04 . BTW: thanks for bringing this up, it made me notice that I accidentally linked against the non-mt boost libs (forgot to add the -mt postfix) which didn't give problems so far but who knows... :) Regards, Carsten From annagulaev at gmail.com Fri May 2 16:45:48 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 16:45:51 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <481BA68C.6020203@gmx.net> References: <481B998E.5090207@gmx.net> <481BA68C.6020203@gmx.net> Message-ID: The boost libraries last appeared in a linux release for 1.20 RC2. RC3,4 and 5 are all missing these files. I'll install the boost signals package just as soon as my build reaches its next failure point :-) Thanks, Anna On Fri, May 2, 2008 at 7:41 PM, Carsten Juttner wrote: > Anna Gulaev wrote: > > > I don't have a boost_signals-mt on my system, either. After installing > > libboost-dev and libboost-regex-dev, here is a complete list of all files on > > my system that contain "boost": > > > > I use Kubuntu 7.10 (Gutsy) and here the boost signals library is in a > separate package called libboost-signals-dev > > Guess it's still the same for 8.04 . > > BTW: thanks for bringing this up, it made me notice that I accidentally > linked against the non-mt boost libs (forgot to add the -mt postfix) which > didn't give problems so far but who knows... :) > > > Regards, > Carsten > > _______________________________________________ > 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/20080502/ec9585e2/attachment-0001.htm From jeska at lindenlab.com Fri May 2 17:08:48 2008 From: jeska at lindenlab.com (Jeska Dzwigalski) Date: Fri May 2 17:07:08 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <018201c8aca0$5a660780$6601a8c0@Topaz> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> Message-ID: <481BAD10.5020305@lindenlab.com> Heya, Thanks for all the great thoughts everyone, very helpful! I wanted to clarify that the Search Flagging described is for search listings -- not inworld content, avatar or group profiles, land sales etc. - it is ONLY for parcel listings, classified ads and events listings. Also, for those who are concerned about abuse/griefing, here is some more detail on the proposed design: * If a listing is flagged as "Mature" by x Residents and is not marked Mature, it will be automatically changed to Mature - it will not be removed. Totally agree that more clarity is needed around what is "mature" (and "prohibited") I will take that back to the Governance Team as feedback. * If a listing is flagged as "Prohibited" by x Residents, it will be automatically taken down and reviewed by the Governance team. Prohibited listings might include listings for gambling or child pornography. * Not all accounts are able to flag search listings, anonymous basic Residents or Residents who are under x days old will not be able to participate in search flagging. * Each account which can flag is only able do so once per search listing and there is a limit to the amount of search listings each account can flag per day. * One account flagging a listing will NOT cause it to be automatically removed * Nominate for Showcase is that exactly - a nomination for review by an editorial board for possible inclusion. * Any classified ads that are taken down will be refunded (prorated for time active), with notification Are there any other restrictions to who can flag or when/how/etc anyone can think of to help both prevent overt abuse while still helping stem grievous abuse of search listings (see: current Event Calendar spam as one example)? Cheers, Jeska Innes McLeod wrote: > I have some reservations about this system. It seems to me that, as > has been mentioned, it can be abused to harass. To prevent it's use as > harassment, you will have to add load to the database to record where > every vote came from. The same will apply to the Showcase nominations. > I can foresee hundreds of alts being created just for the sole purpose > of voting up a single business. > > As it stands even with that system, if I see something that I feel is > a serious offense I would still send a normal AR, instead of waiting > for enough people to notice and hopefully cast their votes for the > removal of the offending content. Generally, I only report for very > obvious hate speech, or child related sexual material, and in my > opinion both of those are to important to just have them sit waiting > for enough votes. > > Something I would rather see would be an expansion of the categories > that products or parcels can be listed under. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Sent:* Friday, May 02, 2008 12:35 PM > *Subject:* [sldev] Your Feedback Wanted on Search Flagging ! > > Hello! > > You've been asking us to do better with inappropriate content and > content classification and we've been listening. In an effort to > make our abuse reporting system easier to access and more > effective, we are planning to introduce a flagging system for our > search results - and we'd love to get your feedback. > > The new flagging system will help Residents to flag inappropriate > postings for rapid removal, while preserving everyone's ability to > express themselves freely in world. > > *How it will work* > > * First, when you post a classified, group, event or parcel > listing, you will have to self-declare if your content is > mature or not. > * Second, every listing will have a "Flag This" link. You can > use this to report inappropriate or mis-classified content > or nominate great content for the showcase. > > *Flag Categories* > > * Mature - /the listing is adult only content/ > * Prohibited - /the listing contains content that is > prohibited on SL/ > * Spam - /irrelevant listings (examples: commercial posts in > non-commercial venues, event postings for non-events)/ > * Showcase - /nominate something for possible inclusion in the > Second Life Showcase/ (http://secondlife.com/showcase) > > /[All listings will still have to follow the Community Standards > and Terms of Service > .]/ > > *Types of listings that can be flagged* > > * Parcel listings > * Classifieds > * Events > * You will not be able to flag avatar or group profiles > > *What happens when something is flagged* > > * Every flag counts as one vote for that flag category. While > one (or few) votes does nothing, if a listing receives > enough votes in that category, it will be auto-classified as > reported. > * Prohibited and spam content will be taken down immediately > when it gets enough votes > * When content is flagged several times, the content owner > will be notified by SL support team and may be penalized > according to Community Standards > > > *Anything else?* > > * Residents will be allowed to flag a particular search > listing only once. You cannot change your vote, so flag with > care > * There will be a limit to how many times a day a Resident can > flag search listings > * Anonymous basic residents or residents whose accounts are > less than x days old will not be able to flag content > * Residents will still be able to report abusive content from > inworld via the Abuse Reporting system under the Help menu > * Of course, no system can be perfect, so if you think > something was flagged in error, you can always file a > support ticket for review > > Thats it. We hope that this will make content flagging more > effective and will help the community better regulate what is > appropriate and what is not. > > Please reply to this email with your thoughts and feedback on this > proposed design! > > Cheers, > Jeska, Kalpana and the LL Search Team > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Lab > jeska@lindenlab.com > http://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > > ------------------------------------------------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------------------------------------------------ > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: > 5/2/2008 8:02 AM > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/6cd49263/attachment.htm From kfa at gmx.net Fri May 2 17:08:27 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri May 2 17:08:55 2008 Subject: [sldev] The pig staring at the clockwork... Message-ID: <481BACFB.80609@gmx.net> Sorry but I need to ask a little help. This is probably simple, but I've been pouring over the code for hours and can't find what I'm looking for. Maybe need more sleep ;) I'm working at a teleport history for VWR-1422 and have it pretty much functioning, only adding the parcel name to the entry poses a slight problem. I hooked up a function call in llviewerdisplay.cpp line 364, that's after 'case LLAgent::TELEPORT_ARRIVING' and inside 'if( arrival_fraction > 1.f )'. Calling LLViewerParcelMgr::getInstance()->getAgentParcelName() returns the name of the previous parcel, not the one where I just landed. Guess that's too early and I have to wait for some update message to arrive, but which one? I tried searching for the point when LLViewerParcelMgr::mAgentParcel gets assigned a value, but couldn't find it. I'd appreciate a quick pointer if someone happens to know that part of the source. Thanks, Felix From darien_caldwell at comcast.net Fri May 2 17:26:24 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Fri May 2 17:26:32 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! References: <481B50DE.8080500@lindenlab.com><018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: <007d01c8acb4$525a4ec0$647ba8c0@a644000> Thanks for the clarification. One Important restriction I can think of is to not let someone's alts also flag the same listing. If you are excluding basic accounts, there should be the ability to tell if more than one avatar is owned by the same person. I noticed you said flagging is restricted on an account basis, does that mean per avatar, or per actual Real Life Individual? The distinction is relevant. :) Also, there is a thread I started in the SL forums on this here: http://forums.secondlife.com/showthread.php?t=256710 If you feel brave stop in, it's quite constructive. ----- Original Message ----- From: Jeska Dzwigalski To: sldev@lists.secondlife.com Cc: kalpana@lindenlab.com Sent: Friday, May 02, 2008 5:08 PM Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! Heya, Thanks for all the great thoughts everyone, very helpful! I wanted to clarify that the Search Flagging described is for search listings -- not inworld content, avatar or group profiles, land sales etc. - it is ONLY for parcel listings, classified ads and events listings. Also, for those who are concerned about abuse/griefing, here is some more detail on the proposed design: * If a listing is flagged as "Mature" by x Residents and is not marked Mature, it will be automatically changed to Mature - it will not be removed. Totally agree that more clarity is needed around what is "mature" (and "prohibited") I will take that back to the Governance Team as feedback. * If a listing is flagged as "Prohibited" by x Residents, it will be automatically taken down and reviewed by the Governance team. Prohibited listings might include listings for gambling or child pornography. * Not all accounts are able to flag search listings, anonymous basic Residents or Residents who are under x days old will not be able to participate in search flagging. * Each account which can flag is only able do so once per search listing and there is a limit to the amount of search listings each account can flag per day. * One account flagging a listing will NOT cause it to be automatically removed * Nominate for Showcase is that exactly - a nomination for review by an editorial board for possible inclusion. * Any classified ads that are taken down will be refunded (prorated for time active), with notification Are there any other restrictions to who can flag or when/how/etc anyone can think of to help both prevent overt abuse while still helping stem grievous abuse of search listings (see: current Event Calendar spam as one example)? Cheers, Jeska Innes McLeod wrote: I have some reservations about this system. It seems to me that, as has been mentioned, it can be abused to harass. To prevent it's use as harassment, you will have to add load to the database to record where every vote came from. The same will apply to the Showcase nominations. I can foresee hundreds of alts being created just for the sole purpose of voting up a single business. As it stands even with that system, if I see something that I feel is a serious offense I would still send a normal AR, instead of waiting for enough people to notice and hopefully cast their votes for the removal of the offending content. Generally, I only report for very obvious hate speech, or child related sexual material, and in my opinion both of those are to important to just have them sit waiting for enough votes. Something I would rather see would be an expansion of the categories that products or parcels can be listed under. ----- Original Message ----- From: Jeska Dzwigalski To: sldev@lists.secondlife.com Sent: Friday, May 02, 2008 12:35 PM Subject: [sldev] Your Feedback Wanted on Search Flagging ! Hello! You've been asking us to do better with inappropriate content and content classification and we've been listening. In an effort to make our abuse reporting system easier to access and more effective, we are planning to introduce a flagging system for our search results - and we'd love to get your feedback. The new flagging system will help Residents to flag inappropriate postings for rapid removal, while preserving everyone's ability to express themselves freely in world. How it will work a.. First, when you post a classified, group, event or parcel listing, you will have to self-declare if your content is mature or not. b.. Second, every listing will have a "Flag This" link. You can use this to report inappropriate or mis-classified content or nominate great content for the showcase. Flag Categories a.. Mature - the listing is adult only content b.. Prohibited - the listing contains content that is prohibited on SL c.. Spam - irrelevant listings (examples: commercial posts in non-commercial venues, event postings for non-events) d.. Showcase - nominate something for possible inclusion in the Second Life Showcase (http://secondlife.com/showcase) [All listings will still have to follow the Community Standards and Terms of Service.] Types of listings that can be flagged a.. Parcel listings b.. Classifieds c.. Events d.. You will not be able to flag avatar or group profiles What happens when something is flagged a.. Every flag counts as one vote for that flag category. While one (or few) votes does nothing, if a listing receives enough votes in that category, it will be auto-classified as reported. b.. Prohibited and spam content will be taken down immediately when it gets enough votes c.. When content is flagged several times, the content owner will be notified by SL support team and may be penalized according to Community Standards Anything else? a.. Residents will be allowed to flag a particular search listing only once. You cannot change your vote, so flag with care b.. There will be a limit to how many times a day a Resident can flag search listings c.. Anonymous basic residents or residents whose accounts are less than x days old will not be able to flag content d.. Residents will still be able to report abusive content from inworld via the Abuse Reporting system under the Help menu e.. Of course, no system can be perfect, so if you think something was flagged in error, you can always file a support ticket for review Thats it. We hope that this will make content flagging more effective and will help the community better regulate what is appropriate and what is not. Please reply to this email with your thoughts and feedback on this proposed design! Cheers, Jeska, Kalpana and the LL Search Team -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- -------------------------------------------------------------------------- _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 8:02 AM ---------------------------------------------------------------------------- _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- ------------------------------------------------------------------------------ _______________________________________________ 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/20080502/e87a201e/attachment-0001.htm From poppy at lindenlab.com Fri May 2 17:58:16 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Fri May 2 17:58:00 2008 Subject: [sldev] Linux Voice, 64-bit, 64-bit Voice Message-ID: <481BB8A8.5050102@lindenlab.com> Hello, I just posted instructions for Linux Voice, 64-bit, 64-bit Voice like I've been promising for a while. Ubuntu-centric, so please adjust for Fedora, Suse, Slackware, etc as needed. https://wiki.secondlife.com/wiki/Linux_Viewer#Voice https://wiki.secondlife.com/wiki/Linux_Viewer#64-bit hth, + poppy From gbrandon at gmail.com Fri May 2 17:58:07 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Fri May 2 17:58:13 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481BAD10.5020305@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: I think you've got the wrong idea with the "automatic" part. On Fri, May 2, 2008 at 8:08 PM, Jeska Dzwigalski wrote: > Heya, > > Thanks for all the great thoughts everyone, very helpful! I wanted to > clarify that the Search Flagging described is for search listings -- not > inworld content, avatar or group profiles, land sales etc. - it is ONLY for > parcel listings, classified ads and events listings. Also, for those who are > concerned about abuse/griefing, here is some more detail on the proposed > design: > > * If a listing is flagged as "Mature" by x Residents and is not marked > Mature, it will be automatically changed to Mature - it will not be removed. > Totally agree that more clarity is needed around what is "mature" (and > "prohibited") I will take that back to the Governance Team as feedback. > * If a listing is flagged as "Prohibited" by x Residents, it will be > automatically taken down and reviewed by the Governance team. Prohibited > listings might include listings for gambling or child pornography. > * Not all accounts are able to flag search listings, anonymous basic > Residents or Residents who are under x days old will not be able to > participate in search flagging. > * Each account which can flag is only able do so once per search listing > and there is a limit to the amount of search listings each account can flag > per day. > * One account flagging a listing will NOT cause it to be automatically > removed > * Nominate for Showcase is that exactly - a nomination for review by an > editorial board for possible inclusion. > * Any classified ads that are taken down will be refunded (prorated for > time active), with notification > > Are there any other restrictions to who can flag or when/how/etc anyone > can think of to help both prevent overt abuse while still helping stem > grievous abuse of search listings (see: current Event Calendar spam as one > example)? > > Cheers, > Jeska > > > > > Innes McLeod wrote: > > I have some reservations about this system. It seems to me that, as has > been mentioned, it can be abused to harass. To prevent it's use as > harassment, you will have to add load to the database to record where every > vote came from. The same will apply to the Showcase nominations. I can > foresee hundreds of alts being created just for the sole purpose of voting > up a single business. > > As it stands even with that system, if I see something that I feel is a > serious offense I would still send a normal AR, instead of waiting for > enough people to notice and hopefully cast their votes for the removal of > the offending content. Generally, I only report for very obvious hate > speech, or child related sexual material, and in my opinion both of those > are to important to just have them sit waiting for enough votes. > > Something I would rather see would be an expansion of the categories that > products or parcels can be listed under. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Sent:* Friday, May 02, 2008 12:35 PM > *Subject:* [sldev] Your Feedback Wanted on Search Flagging ! > > Hello! > > You've been asking us to do better with inappropriate content and content > classification and we've been listening. In an effort to make our abuse > reporting system easier to access and more effective, we are planning to > introduce a flagging system for our search results - and we'd love to get > your feedback. > > The new flagging system will help Residents to flag inappropriate postings > for rapid removal, while preserving everyone's ability to express themselves > freely in world. > > *How it will work* > > - First, when you post a classified, group, event or parcel listing, > you will have to self-declare if your content is mature or not. > - Second, every listing will have a "Flag This" link. You can use > this to report inappropriate or mis-classified content or nominate great > content for the showcase. > > *Flag Categories* > > - Mature - *the listing is adult only content* > - Prohibited - *the listing contains content that is prohibited on > SL* > - Spam - *irrelevant listings (examples: commercial posts in > non-commercial venues, event postings for non-events)* > - Showcase - *nominate something for possible inclusion in the > Second Life Showcase* (http://secondlife.com/showcase) > > *[All listings will still have to follow the Community Standardsand Terms > of Service .]* > > *Types of listings that can be flagged* > > - Parcel listings > - Classifieds > - Events > - You will not be able to flag avatar or group profiles > > *What happens when something is flagged* > > - Every flag counts as one vote for that flag category. While one > (or few) votes does nothing, if a listing receives enough votes in that > category, it will be auto-classified as reported. > - Prohibited and spam content will be taken down immediately when it > gets enough votes > - When content is flagged several times, the content owner will be > notified by SL support team and may be penalized according to Community > Standards > > *Anything else?* > > - Residents will be allowed to flag a particular search listing only > once. You cannot change your vote, so flag with care > - There will be a limit to how many times a day a Resident can flag > search listings > - Anonymous basic residents or residents whose accounts are less > than x days old will not be able to flag content > - Residents will still be able to report abusive content from > inworld via the Abuse Reporting system under the Help menu > - Of course, no system can be perfect, so if you think something > was flagged in error, you can always file a support ticket for review > > Thats it. We hope that this will make content flagging more effective and > will help the community better regulate what is appropriate and what is not. > > Please reply to this email with your thoughts and feedback on this > proposed design! > > Cheers, > Jeska, Kalpana and the LL Search Team > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > > ------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------ > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 > 8:02 AM > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > > _______________________________________________ > 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/20080502/36099132/attachment.htm From secret.argent at gmail.com Fri May 2 19:00:36 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri May 2 19:00:04 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B50DE.8080500@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> Message-ID: On 2008-05-02, at 12:35, Jeska Dzwigalski wrote: > You've been asking us to do better with inappropriate content and > content classification and we've been listening. In an effort to > make our abuse reporting system easier to access and more > effective, we are planning to introduce a flagging system for our > search results - and we'd love to get your feedback. My feedback, as a 20 year network administrator who has at times been at the forefront of the anti-spam effort in Usenet and email, is: 1. I have not been asking you to do better with "inappropriate content and content classification", I have been asking that you make it easier to report spam. Spam is a content-free concept: the content of a message is almost irrelevant as to whether it is spam or not. 2. "this is spam" should be the only option. Any other categorization is too open to abuse and is likely to cause you a lot of extra work, as well as cause unrecoverable damages to innocent parties. At least that's what's happened in other environments. From secret.argent at gmail.com Fri May 2 19:03:30 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri May 2 19:02:59 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> Message-ID: On 2008-05-02, at 14:46, Anna Gulaev wrote: > I always thought it'd be a good half-solution to allow builders to > define a volume (a prim) as "indoor space". So, you'd place a few > large prims inside your building to roughly fill the space > (including the interior wall surfaces, but not the exterior), make > them fully transparent, flag them as "interior volume", and any > surface that was fully within one of those volumes would not > receive sun/moon lighting or any local lighting that originated > outside the volume. Only if these prims were guaranteed to never under any circumstances able to be selected unless you have BOTH "show transparent" and "edit mode" on. Trust me, it's swingingely hard to interact with ANYTHING when you're inside a prim. From matthew.dowd at hotmail.co.uk Fri May 2 19:20:04 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 19:20:07 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: References: <481B998E.5090207@gmx.net> <481BA68C.6020203@gmx.net> Message-ID: My recollection from a previous thread was that there were some versioning conflicts with boost on linux, and a recommendation that you install these from source rather than LL distribute them. I don't know the details but suspect that there might be minor differences in the boost binaries for different distros? Matthew Date: Fri, 2 May 2008 19:45:48 -0400From: annagulaev@gmail.comTo: sldev@lists.secondlife.comSubject: Re: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mtThe boost libraries last appeared in a linux release for 1.20 RC2. RC3,4 and 5 are all missing these files.I'll install the boost signals package just as soon as my build reaches its next failure point :-)Thanks,Anna On Fri, May 2, 2008 at 7:41 PM, Carsten Juttner wrote: Anna Gulaev wrote: I don't have a boost_signals-mt on my system, either. After installing libboost-dev and libboost-regex-dev, here is a complete list of all files on my system that contain "boost":I use Kubuntu 7.10 (Gutsy) and here the boost signals library is in a separate package called libboost-signals-devGuess it's still the same for 8.04 .BTW: thanks for bringing this up, it made me notice that I accidentally linked against the non-mt boost libs (forgot to add the -mt postfix) which didn't give problems so far but who knows... :) Regards,Carsten_______________________________________________Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ All new Live Search at Live.com http://clk.atdmt.com/UKM/go/msnnkmgl0010000006ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/676090b1/attachment.htm From matthew.dowd at hotmail.co.uk Fri May 2 19:35:10 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 19:35:13 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: Its the automatic guilty if voted by x residents which is the problem. As noted, even with the various safeguards there is still scope for grieffing. However, it is mistaken votes which concern me. When the child pornography issue flared up, there were quite a few people who though child avatars were banned (and ARed such), and others who reacted to child avatars in mature areas as if they were real children (forgetting that a pixel depiction of a child is not corruptible, and any avatar on the main grid should have an adult controlling it). Likewise with the gambling ban there were even reports of Lindens deleting pay for free devices which weren't banned. Suppose I had a Los Vegas themed sim, but were all the slot machines, roulette wheels etc worked but didn't take or pay out money (i.e. more decorative). I could quite imagine that getting flagged quite often as prohibited. Unfortunately there are probably enough people out there who would incorrectly flag parcels (either deliberately or through an honest or cultural misunderstanding), that if you set x high enough to avoid search entries being incorrectly removed, you've probably also set x too high for correctly flagged parcels to also be removed. Matthew Date: Fri, 2 May 2008 20:58:07 -0400From: gbrandon@gmail.comTo: sldev@lists.secondlife.comSubject: Re: [sldev] Your Feedback Wanted on Search Flagging !I think you've got the wrong idea with the "automatic" part. On Fri, May 2, 2008 at 8:08 PM, Jeska Dzwigalski wrote: Heya, Thanks for all the great thoughts everyone, very helpful! I wanted to clarify that the Search Flagging described is for search listings -- not inworld content, avatar or group profiles, land sales etc. - it is ONLY for parcel listings, classified ads and events listings. Also, for those who are concerned about abuse/griefing, here is some more detail on the proposed design: * If a listing is flagged as "Mature" by x Residents and is not marked Mature, it will be automatically changed to Mature - it will not be removed. Totally agree that more clarity is needed around what is "mature" (and "prohibited") I will take that back to the Governance Team as feedback. * If a listing is flagged as "Prohibited" by x Residents, it will be automatically taken down and reviewed by the Governance team. Prohibited listings might include listings for gambling or child pornography.* Not all accounts are able to flag search listings, anonymous basic Residents or Residents who are under x days old will not be able to participate in search flagging. * Each account which can flag is only able do so once per search listing and there is a limit to the amount of search listings each account can flag per day.* One account flagging a listing will NOT cause it to be automatically removed* Nominate for Showcase is that exactly - a nomination for review by an editorial board for possible inclusion. * Any classified ads that are taken down will be refunded (prorated for time active), with notificationAre there any other restrictions to who can flag or when/how/etc anyone can think of to help both prevent overt abuse while still helping stem grievous abuse of search listings (see: current Event Calendar spam as one example)? Cheers, Jeska Innes McLeod wrote: I have some reservations about this system. It seems to me that, as has been mentioned, it can be abused to harass. To prevent it's use as harassment, you will have to add load to the database to record where every vote came from. The same will apply to the Showcase nominations. I can foresee hundreds of alts being created just for the sole purpose of voting up a single business. As it stands even with that system, if I see something that I feel is a serious offense I would still send a normal AR, instead of waiting for enough people to notice and hopefully cast their votes for the removal of the offending content. Generally, I only report for very obvious hate speech, or child related sexual material, and in my opinion both of those are to important to just have them sit waiting for enough votes. Something I would rather see would be an expansion of the categories that products or parcels can be listed under. ----- Original Message ----- From: Jeska Dzwigalski To: sldev@lists.secondlife.com Sent: Friday, May 02, 2008 12:35 PM Subject: [sldev] Your Feedback Wanted on Search Flagging ! Hello! You've been asking us to do better with inappropriate content and content classification and we've been listening. In an effort to make our abuse reporting system easier to access and more effective, we are planning to introduce a flagging system for our search results - and we'd love to get your feedback. The new flagging system will help Residents to flag inappropriate postings for rapid removal, while preserving everyone's ability to express themselves freely in world.How it will work First, when you post a classified, group, event or parcel listing, you will have to self-declare if your content is mature or not. Second, every listing will have a "Flag This" link. You can use this to report inappropriate or mis-classified content or nominate great content for the showcase. Flag Categories Mature - the listing is adult only content Prohibited - the listing contains content that is prohibited on SL Spam - irrelevant listings (examples: commercial posts in non-commercial venues, event postings for non-events) Showcase - nominate something for possible inclusion in the Second Life Showcase (http://secondlife.com/showcase) [All listings will still have to follow the Community Standards and Terms of Service.] Types of listings that can be flagged Parcel listings Classifieds Events You will not be able to flag avatar or group profiles What happens when something is flagged Every flag counts as one vote for that flag category. While one (or few) votes does nothing, if a listing receives enough votes in that category, it will be auto-classified as reported. Prohibited and spam content will be taken down immediately when it gets enough votes When content is flagged several times, the content owner will be notified by SL support team and may be penalized according to Community Standards Anything else? Residents will be allowed to flag a particular search listing only once. You cannot change your vote, so flag with care There will be a limit to how many times a day a Resident can flag search listings Anonymous basic residents or residents whose accounts are less than x days old will not be able to flag content Residents will still be able to report abusive content from inworld via the Abuse Reporting system under the Help menu Of course, no system can be perfect, so if you think something was flagged in error, you can always file a support ticket for review Thats it. We hope that this will make content flagging more effective and will help the community better regulate what is appropriate and what is not. Please reply to this email with your thoughts and feedback on this proposed design! Cheers, Jeska, Kalpana and the LL Search Team -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- _______________________________________________Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev No virus found in this incoming message.Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 8:02 AM _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- _______________________________________________Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Discover and Win with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/94c0406e/attachment.htm From annagulaev at gmail.com Fri May 2 20:33:51 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 20:33:52 2008 Subject: [sldev] [VWR] Built viewer. Now what? Message-ID: I've built 1.20 RC5 for both linux and windows. I have the same problem with both... How do I run the darn thing? The linux build seems to spit out a do-it-yourself collection of scripts, which if I assemble to resemble the released version with it's double-indirect calling of the executable I could probably get to work. But...why? Is this like an exercise? So, I do the exercise and...fail. Can't find libELFIO. I can, but the damned executable can't. I could now research how the release version finds its dynamic libraries, but instead I throw up my arms, re-build the damned thing as a releasefordownload version, extract the tarball as if I had downloaded it, and have a working version. Heaven help me if I need to debug it. The windows build won't run because it can't find a DLL that's right where it's always been (fmod.dll). How does an application know to look in the directory above for DLLs? The last version could do that and this version can't. Time to look up how the black box that is visual studio handles DLL paths. Another exercise. This time I cheat. I just copy the DLL into the directory with the executable. Only, this doesn't work. The app will now run, but it looks for its app_settings in the wrong place and exits with an error. So I've come to the conclusion that I'm daft. I've had the unreasonable expectation that the result of building a program is a program I can run. Or I've failed to read something I should have. Or I've failed to download somethingerother. Or I built the wrong version. Or...I'm just daft. I've been working with 1.18.4.3 for months. I've been building the release version (not releasefordownload) for...whatever reason. I don't remember. I think it had the right mix of debug info and ease of building. So, that's the version I'm trying to build now. Please. What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/5c74716e/attachment-0001.htm From annagulaev at gmail.com Fri May 2 20:43:45 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 20:43:47 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: References: <481B998E.5090207@gmx.net> <481BA68C.6020203@gmx.net> Message-ID: On 5/2/08, Anna Gulaev wrote: > > The boost libraries last appeared in a linux release for 1.20 RC2. RC3,4 > and 5 are all missing these files. It's also missing ll_icon.png I found ll_icon.BMP in a previous verion and converted using GIMP. It doesn't seem to use the icon, but it needs to be there for the build. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080502/f9218d63/attachment.htm From matthew.dowd at hotmail.co.uk Fri May 2 21:47:10 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri May 2 21:47:13 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481B9292.4080608@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com><481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> Message-ID: Can't give references to research - but I would suggest a different approach: Mature content Google has something called "SafeSearch filtering" which can filter out "explicit sexual content" (http://www.google.com/support/bin/static.py?page=searchguides.html&ctx=preferences&hl=en). Given the new search uses a Google Appliance could a variant of that be employed (when the mature checkbox is unticked)? Spam Work on the landmarks project to allow better social tagging of locations etc. - improve the amount of description you can add to locations/objects etc. so that the real results get ranked better. i.e. increase the relevancy of non-spam rather than tag spam per se. Matthew > Date: Fri, 2 May 2008 15:15:46 -0700> From: robla@lindenlab.com> To: sldev@lists.secondlife.com> Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !)> > Hi all,> > Let me ask this another way. Is anyone aware of published research or > other helpful information in this area that may not have been considered > in the original design? Big bonus points if you can actually provide > helpful quotes from that research that are relevant to the proposed design.> > Rob> > On 5/2/08 11:02 AM, Jeska Dzwigalski wrote:> > Heya!> >> > Repeatedly misusing/abusing the flagging tool (for example to target a> > particular Resident) would be considered harassment and handled by the> > Governance team per the Community Standards.> >> > Anyone else have thoughts or questions on the design?> >> > Cheers,> > Jeska> >> >> > Thomas Grimshaw wrote:> > > >> Zak Escher wrote:> >> > >>> Will there be any consequences for abusively flagging listings?> >>> > >> Yes, my question too.> >>> >> The abuse reporting system has been obscenely misused as a griefing> >> tool for a long time, i'd rather not add to this.> >>> >> Tom> >> _______________________________________________> >> 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 _________________________________________________________________ Discover and Win with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/ab1b5bd8/attachment.htm From GordonWendt at gmail.com Fri May 2 22:03:10 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri May 2 22:03:13 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481B9292.4080608@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> Message-ID: <493033a70805022203y68b91015mb95ad97d2304edda@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What about using a cloud system, let people tag specific locations and switch to tag based searching, of course there would have to be a system to weigh each tag for a specific entry be it parcel, event, etc... I would be against this being used for people tagging which should stay purely alphabetical and tagging for listings that are based on paying for a listing should stay prioritized based on the amount paid (although that's an entirely separate issue altogether). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: http://getfiregpg.org iD8DBQFIG/IdqJF30JM0FpARApaNAJ45yZButmjTE14RpCb9OtAbKyJGdACglqRK q7+f+4ETbpErum62UYDt5hk= =vhgQ -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/f29d2593/attachment.htm From annagulaev at gmail.com Fri May 2 22:08:29 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri May 2 22:08:32 2008 Subject: [sldev] The pig staring at the clockwork... In-Reply-To: <481BACFB.80609@gmx.net> References: <481BACFB.80609@gmx.net> Message-ID: I think you're looking for a parcel properties reply message. Anna On Fri, May 2, 2008 at 8:08 PM, Felix Duesenburg wrote: > I hooked up a function call in llviewerdisplay.cpp line 364, that's > after 'case LLAgent::TELEPORT_ARRIVING' and inside 'if( arrival_fraction > > 1.f )'. Calling LLViewerParcelMgr::getInstance()->getAgentParcelName() > returns the name of the previous parcel, not the one where I just landed. > > Guess that's too early and I have to wait for some update message to > arrive, but which one? I tried searching for the point when > LLViewerParcelMgr::mAgentParcel gets assigned a value, but couldn't find > it. I'd appreciate a quick pointer if someone happens to know that part > of the source. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/93d64bef/attachment.htm From overtake at keynet.com.br Sat May 3 01:16:58 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Sat May 3 01:33:43 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> Message-ID: <007601c8acf8$5491fe60$6e00a8c0@eaurouge> Well said Felix, I agree totally. {}Overtake ----- Original Message ----- From: "Felix Duesenburg" To: "Jeska Dzwigalski" Cc: Sent: Friday, May 02, 2008 6:30 PM Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! > I'm afraid this is like shouting against a tidal wave, and maybe off > topic on a dev list. But since feedback is asked I have to seize the > opportunity and say my opinion anyway. While appreciating LL's efforts > to listen to the user community, it's that community that has me worried > much more in this context. I am truly appalled by this correctness > craze. People seem to be more scared of a breast popping on their screen > than of nuclear bombs or legal systems going haywire. Maybe it has to do > with where one comes from... but whenever I see such a thing being > considered, I get a flashback of the so-called German Democratic > Republic, where half the population made sure that the other half toed > the line. To cut a long rant short, I am against any flagging, rating or > other system that facilitates and encourages public denounciation of > perceived aberrations. The only ones who should get a say in this matter > are the immediate neighbours of a parcel, or those living in the same > region or within visible render distance. Whether it's about the > PG/Mature distinction or any individual local standard, the general > public should not get to enforce a regional rule. But there seem to be > so many people actually wanting this that we are led to believe applying > the rule of democracy is the only right thing to do. Then I'm again > reminded that democracy and liberty are two completely different things > - even "good" democracies have the potential to turn hostile against > minority opinions and forms of expression. If I don't like a place I > have the liberty to go elsewhere, only their neighbours can't so easily, > that's why they alone may object. Generally, the liberty of the creator > weighs higher than the casual visitor's individual taste or decency > threshold. But that seems to be just my lone opinion these days. Can't > anyone see that we're going back to the middle ages when we didn't know > to distinguish moral and criminal code...? > > Felix > > > Jeska Dzwigalski wrote: >> Hello! >> >> You've been asking us to do better with inappropriate content and >> content classification and we've been listening. In an effort to make >> our abuse reporting system easier to access and more effective, we are >> planning to introduce a flagging system for our search results - and >> we'd love to get your feedback. >> >> ... > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kfa at gmx.net Sat May 3 04:13:34 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat May 3 04:14:13 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481BAD10.5020305@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: <481C48DE.3030305@gmx.net> Sorry, I wasn't quite clear in my earlier statement. Although I talked about in-world content, I didn't mean to distinguish between that content and listings or classifieds that refer to it when I opposed the suggested flagging system. Whether for content or listings, I am against facilities that make it too easy to give demerit points, especially when they are coupled with an automated de-listing that forces the accused to intervene to have it undone. But maybe there is one aspect where such a system could be very helpful: To improve relevancy of advertisements/listings to the actual content, and therefore improve the quality of search results. There is quite a rampant abuse of keywords used both in location descriptions and classifieds. Pretty much everything is put in there, whether it has anything to do with what they offer or not, only to boost search ranking. But that's the same problem as on the web and very difficult to tackle by technical means. I usually simply include such facts in my consideration whether to buy anything from that vendor or not. If there was a rating system where users can influence the search ranking based on relevancy, that would be quite an improvement. However, as said before, a negative flagging system is an invitation to abuse by e.g. competitors or anyone with malicious intent. Only a positive flagging system (similar to the in-world vote boxes we already have) would be able to prevent that from happening. To fake a positive ranking you need an army of alts and that could be detected internally. Felix Jeska Dzwigalski wrote: > Heya, > > Thanks for all the great thoughts everyone, very helpful! I wanted to > clarify that the Search Flagging described is for search listings -- not > inworld content, avatar or group profiles, land sales etc. - it is ONLY > for parcel listings, classified ads and events listings. Also, for those > who are concerned about abuse/griefing, here is some more detail on the > proposed design: > > ... From marvin24 at gmx.de Sat May 3 04:29:45 2008 From: marvin24 at gmx.de (Marvin) Date: Sat May 3 04:29:51 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <481B998E.5090207@gmx.net> References: <481B998E.5090207@gmx.net> Message-ID: <200805031329.46271.marvin24@gmx.de> Hi, On Saturday 03 May 2008 00:45:34 Carsten Juttner wrote: > Anna Gulaev wrote: > > I seem to be missing the library libboost_signals-gcc34-mt > > > > It is not in the easy linux dependencies, and it is not included in an > > install of libboost-dev and libboost-regex-dev. Can someone please > > tell me where this is supposed to be, and how it was supposed to have > > gotten there? > > > > Ubuntu 8.04 > > Not sure why it's not in the libs package but linking against the system > provided libbosts should be no problem. > > You just have to remove the "gcc34" reference in the SConstruct to be > able to link against the system libraries. > > For example: > 'boost_signals-gcc34-mt' needs to become 'boost_signals-mt' there is another problem, that multithreaded versions of the libraries are not available everywhere. Is there a problem linking to the non-threaded versions? - Marvin From me at signpostmarv.name Sat May 3 04:34:46 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat May 3 04:34:50 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481BAD10.5020305@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: <481C4DD6.4010106@signpostmarv.name> cF = UNIX_TIMESTAMP(`date_content_flagged`) cP = UNIX_TIMESTAMP(`date_content_posted`) fA = UNIX_TIMESTAMP(`date_flagger_avatar_born`) N = number_of_flaggings T = (cF - cP) / (cF - fA) W = weight_of_flagging = N / T If my math is right, the algebra blurb I've typed out above makes fewer flaggings from older avatars more substantial than flash-mobbing content with freshly created accounts. It also makes older avatars' flaggings carry more weight on older content. Using a weighted scheme (perhaps not using the formula I've described here), would be far more preferable than if (N = x) take action. ~ Marv. Jeska Dzwigalski wrote: > Heya, > > Thanks for all the great thoughts everyone, very helpful! I wanted to > clarify that the Search Flagging described is for search listings -- > not inworld content, avatar or group profiles, land sales etc. - it is > ONLY for parcel listings, classified ads and events listings. Also, > for those who are concerned about abuse/griefing, here is some more > detail on the proposed design: > > * If a listing is flagged as "Mature" by x Residents and is not marked > Mature, it will be automatically changed to Mature - it will not be > removed. Totally agree that more clarity is needed around what is > "mature" (and "prohibited") I will take that back to the Governance > Team as feedback. > * If a listing is flagged as "Prohibited" by x Residents, it will be > automatically taken down and reviewed by the Governance team. > Prohibited listings might include listings for gambling or child > pornography. > * Not all accounts are able to flag search listings, anonymous basic > Residents or Residents who are under x days old will not be able to > participate in search flagging. > * Each account which can flag is only able do so once per search > listing and there is a limit to the amount of search listings each > account can flag per day. > * One account flagging a listing will NOT cause it to be automatically > removed > * Nominate for Showcase is that exactly - a nomination for review by > an editorial board for possible inclusion. > * Any classified ads that are taken down will be refunded (prorated > for time active), with notification > > Are there any other restrictions to who can flag or when/how/etc > anyone can think of to help both prevent overt abuse while still > helping stem grievous abuse of search listings (see: current Event > Calendar spam as one example)? > > Cheers, > Jeska -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/a5872887/smime.bin From carjay at gmx.net Sat May 3 05:04:27 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat May 3 05:04:28 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <200805031329.46271.marvin24@gmx.de> References: <481B998E.5090207@gmx.net> <200805031329.46271.marvin24@gmx.de> Message-ID: <481C54CB.5030307@gmx.net> Marvin wrote: > there is another problem, that multithreaded versions of the libraries are not > available everywhere. Is there a problem linking to the non-threaded > versions? > Thinking about it, the GUI is currently single-threaded most of the time so it probably won't matter but given that somebody at LL thought it might be necessary to link against mt versions I'd rather go with that. But it could just be a case of "better safe than sorry" :) Which distribution does not include mt-versions of boost libraries? Regards, Carsten From carjay at gmx.net Sat May 3 05:12:01 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat May 3 05:12:00 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <481C54CB.5030307@gmx.net> References: <481B998E.5090207@gmx.net> <200805031329.46271.marvin24@gmx.de> <481C54CB.5030307@gmx.net> Message-ID: <481C5691.3090005@gmx.net> Carsten Juttner wrote: > Thinking about it, the GUI is currently single-threaded most of the > time so it probably won't matter but given that somebody at LL thought > it might be necessary to link against mt versions I'd rather go with > that. That should actually read: "the viewer is currently...". AFAIK the GUI parts (including the render pipeline) of the viewer are handled in a single thread all the time. From marvin24 at gmx.de Sat May 3 05:56:30 2008 From: marvin24 at gmx.de (Marvin) Date: Sat May 3 05:56:37 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: <481C54CB.5030307@gmx.net> References: <200805031329.46271.marvin24@gmx.de> <481C54CB.5030307@gmx.net> Message-ID: <200805031456.30985.marvin24@gmx.de> Hello Carsten, On Saturday 03 May 2008 14:04:27 Carsten Juttner wrote: > Marvin wrote: > > there is another problem, that multithreaded versions of the libraries > > are not available everywhere. Is there a problem linking to the > > non-threaded versions? > > Thinking about it, the GUI is currently single-threaded most of the time > so it probably won't matter but given that somebody at LL thought it > might be necessary to link against mt versions I'd rather go with that. > > But it could just be a case of "better safe than sorry" :) > > Which distribution does not include mt-versions of boost libraries? openSuSE < 11 (means all released versions) Fedora < 8 donno about ubuntu/debian and others maybe this has something to do with the boost version, because 1.34 libraries have seperated "-mt" versions. Also, there is a -D_REENTRANT compiler flag set, which probably should be turned off. Will test this out. - Marvin From wuhanzymail at 163.com Sat May 3 07:03:06 2008 From: wuhanzymail at 163.com (wuhanzymail) Date: Sat May 3 07:03:34 2008 Subject: [sldev] cygwin flex lscript_compile workaround In-Reply-To: <4818FF66.9040505@lindenlab.com> References: <4818FF66.9040505@lindenlab.com> Message-ID: <24758368.287211209823386992.JavaMail.coremail@bj163app112.163.com> How to apply below patch to indra.l? Just copy and paste these code to the end of indra.l? I tried but failed. I have no experience about it, so could anyone kind to give more detail instructions? Thank you so much! Best Regards, Ying ?2008-05-01?Steve ??? I'm not sure whether this has already been addressed here, but we discovered a problem with the latest version of Cygwin flex and lscript_compile and I thought I would share the workaround. We've committed the workaround to our release-candidate branche so it should be in an upcoming source drop as well. 1. Add "YY_NO_UNISTD_H" to the list of Preprocessor Definitions in the lscript_compile project file. 2. Apply the following patch it indra.l: Index: indra.l =================================================================== --- indra.l (revision 86342) +++ indra.l (revision 86343) @@ -12,6 +12,7 @@ #include "linden_common.h" // Deal with the fact that lex/yacc generates unreachable code #ifdef LL_WINDOWS +#pragma warning (disable : 4018) // warning C4018: signed/unsigned mismatch #pragma warning (disable : 4702) // warning C4702: unreachable code #endif // LL_WINDOWS #include "llmath.h" @@ -44,7 +45,10 @@ #define YYLMAX 16384 #define YY_NEVER_INTERACTIVE 1 /* stops flex from calling isatty() */ - +#ifdef LL_WINDOWS +#define isatty(x) 0 /* hack for bug in cygwin flex 2.5.35 */ +#endif + #ifdef ECHO #undef ECHO #endif _______________________________________________ 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/20080503/2ec120ea/attachment.htm From matthew.dowd at hotmail.co.uk Sat May 3 08:43:27 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat May 3 08:43:29 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481BAD10.5020305@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> Message-ID: > * If a listing is flagged as "Prohibited" by x Residents, it will be automatically taken > down and reviewed by the Governance team. Prohibited listings might > include listings for gambling or child pornography. What happens if a listing reviewed by the Governance team and reinstated, goes on to get another x votes? A good example might be a free to play casino (i.e. you play the games for fun rather than money) - this *isn't* prohibited by the gambling ban. However, I suspect a significant proportion of residents would think that any casino is banned (after all even some of the Lindens tasked with deleting gambling devices failed to realise that distinction and removed some free to play games - much to the annoyance of residents). As such I could see such a listing quite frequently attracting x votes, being automatically taken down, being reviewed by the governance team, being reinstated, and a few days later attracting another x votes etc. This may also apply to search listings for other activities where there is some ambiguity as to whether it is prohibited or not, or where there is a sizeable group who would *like* to see that activity banned (even though it is legal, permissible, and the community as a whole has no problem with it). Matthew _________________________________________________________________ Win Indiana Jones prizes with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/3175ff6c/attachment.htm From carjay at gmx.net Sat May 3 09:37:03 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat May 3 09:37:02 2008 Subject: [sldev] cygwin flex lscript_compile workaround In-Reply-To: <24758368.287211209823386992.JavaMail.coremail@bj163app112.163.com> References: <4818FF66.9040505@lindenlab.com> <24758368.287211209823386992.JavaMail.coremail@bj163app112.163.com> Message-ID: <481C94AF.20006@gmx.net> wuhanzymail wrote: > How to apply below patch to indra.l? Just copy and paste these code to > the end of indra.l? I tried but failed. > I have no experience about it, so could anyone kind to give more > detail instructions? Thank you so much! It's what "svn diff" outputs. You can use "patch" to apply it to the sourcecode under Linux but there are similar tools for Windows, too. Take a look at http://en.wikipedia.org/wiki/Diff and http://en.wikipedia.org/wiki/Patch_%28Unix%29 for more info. BTW, the change has made it into the current 1.20RC sources in svn, so you might as well use: http://svn.secondlife.com/svn/linden/branches/Branch_1-20-Viewer/indra/lscript/lscript_compile/indra.l Regards, Carsten From wuhanzymail at 163.com Sat May 3 10:09:11 2008 From: wuhanzymail at 163.com (wuhanzymail) Date: Sat May 3 10:09:29 2008 Subject: [sldev] cygwin flex lscript_compile workaround In-Reply-To: <481C94AF.20006@gmx.net> References: <481C94AF.20006@gmx.net> <4818FF66.9040505@lindenlab.com> <24758368.287211209823386992.JavaMail.coremail@bj163app112.163.com> Message-ID: <12246398.326111209834551698.JavaMail.coremail@bj163app112.163.com> Boroondas and Carsten, thanks for your help. Now I made the patch successfully. Best Regards, Ying ?2008-05-04?"Carsten Juttner" ??? wuhanzymail wrote: > How to apply below patch to indra.l? Just copy and paste these code to > the end of indra.l? I tried but failed. > I have no experience about it, so could anyone kind to give more > detail instructions? Thank you so much! It's what "svn diff" outputs. You can use "patch" to apply it to the sourcecode under Linux but there are similar tools for Windows, too. Take a look at http://en.wikipedia.org/wiki/Diff and http://en.wikipedia.org/wiki/Patch_%28Unix%29 for more info. BTW, the change has made it into the current 1.20RC sources in svn, so you might as well use: http://svn.secondlife.com/svn/linden/branches/Branch_1-20-Viewer/indra/lscript/lscript_compile/indra.l Regards, Carsten _______________________________________________ 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/20080504/acf3da64/attachment.htm From seg at haxxed.com Sat May 3 12:38:17 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat May 3 12:38:21 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> Message-ID: <1209843497.12336.73.camel@localhost> On Fri, 2008-05-02 at 21:44 +0000, Matthew Dowd wrote: > > If it gets more than X flags, then it gets > > automatically taken down, and it still goes to a human review team. > > All you need is a co-ordinated group of X+1 people determined to > remove say anyone selling sculpties (or a more realistic prejudice), > for them to at least temporarily get sites removed. Effectively, such > an approach is a "guilty until proven innocent" one. Yes, that's exactly what I'm considering. Which is why I'm proposing a quick-reacting review team that will detect such abuse, put the listing back up, whitelist it against further abuse, and punish the abusers. Such as removing their tagging privileges for N months. If you have a better idea, feel free to propose it. "x sucks" is not productive. "x sucks, how about y instead?" is productive. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e3f1e99a/attachment.pgp From secret.argent at gmail.com Sat May 3 13:10:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat May 3 13:10:23 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209843497.12336.73.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> Message-ID: <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> On 2008-05-03, at 14:38, Callum Lerwick wrote: > If you have a better idea, feel free to propose it. "x sucks" is not > productive. "x sucks, how about y instead?" is productive. Well, I proposed my alternative. But what the hell, how about another? * Nothing is banned automatically. * Flagged posts are handled in order of some function based on how old they are and how many flags there are and what type there are. For example, spam flags get an exponential function of the number of flags, say 0.1 * 2^N. * If something is obviously being flagged falsely, the IP address of the all flaggers are put on a silent blacklist for one day, and all flags from these address are silently voided. * The length of the blacklist is increased each time it's invoked. From matthew.dowd at hotmail.co.uk Sat May 3 13:48:52 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat May 3 13:48:56 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209843497.12336.73.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> Message-ID: > If you have a better idea, feel free to propose it. "x sucks" is not> productive. "x sucks, how about y instead?" is productive. I did a few posts back but to expand a little: i) use Google SafeFilter for filtering out mature content in addition to the mature tag ii) work on various projects such as the landmark project to improve relevancy ranking (perhaps consider social tagging) thus pushing spam down in rank iii) use the existing AR process for prohibited listings (consider adding an AR button to search results) iv) adding a button for recommending content to the showcase (perhaps only allow one recommendation per day, restrict to PIOF accounts and/or add some token L$ fee to cut down abuse). Matthew _________________________________________________________________ Be a Hero and Win with Iron Man http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/bea7c394/attachment.htm From matthew.dowd at hotmail.co.uk Sat May 3 13:52:58 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat May 3 13:53:00 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209843497.12336.73.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> Message-ID: > punish the abusers. Such as removing their tagging privileges for N months. This needs to be done with care - a false report may be a genuine mistake - believing the gambling ban applies to free to pay casinos which don't give prizes, thinking the "no age play" blogs outlaw child avatars etc. Overall, the amount of manual work to deal with the system proposed doesn't sound much less (and possibly more) than the amount to deal with a traditional AR - hence my suggest to stick with the current AR process! Matthew _________________________________________________________________ Discover and Win with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e9657bff/attachment.htm From seg at haxxed.com Sat May 3 16:13:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat May 3 16:13:35 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> Message-ID: <1209856410.12336.84.camel@localhost> On Sat, 2008-05-03 at 20:52 +0000, Matthew Dowd wrote: > > punish the abusers. Such as removing their tagging privileges for N > months. > > This needs to be done with care - a false report may be a genuine > mistake - believing the gambling ban applies to free to pay casinos > which don't give prizes, thinking the "no age play" blogs outlaw child > avatars etc. Yes, which is why I'm insisting the decision be made by a human being, with a user's past behavior taken in to account. A written warning can be made first, with a three strikes and you're out policy, whatever. I was being deliberately vague about the details of punishment because it is orthogonal to my proposed workflow. > Overall, the amount of manual work to deal with the system proposed > doesn't sound much less (and possibly more) than the amount to deal > with a traditional AR - hence my suggest to stick with the current AR > process! My main point is once a listing is reviewed and a decision of its legitimacy is made, that decision stands. No more flaggings/ARs are allowed, preventing an endless fight over a single listing. And the idea is that the review team is well familiar enough with the minute detail of what is against the rules and what isn't, that these decisions can be made quickly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5d274bba/attachment.pgp From seg at haxxed.com Sat May 3 16:21:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat May 3 16:21:09 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> Message-ID: <1209856862.12336.92.camel@localhost> On Sat, 2008-05-03 at 20:48 +0000, Matthew Dowd wrote: > i) use Google SafeFilter for filtering out mature content in addition > to the mature tag Any automated system, even Google's, can and will be gamed by determined human beings. Requiring humans to be in the loop to counter such behavior *anyway*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5b752692/attachment.pgp From seg at haxxed.com Sat May 3 16:49:16 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat May 3 16:49:21 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> Message-ID: <1209858556.12336.112.camel@localhost> On Sat, 2008-05-03 at 15:10 -0500, Argent Stonecutter wrote: > Well, I proposed my alternative. But what the hell, how about another? > > * Nothing is banned automatically. Well fine, if everyone is so determined that any automatic takedown is evil, then N = infinity. I don't particularly care. My proposed workflow still stands. > * Flagged posts are handled in order of some function based on how > old they are and how many flags there are and what type there are. > For example, spam flags get an exponential function of the number of > flags, say 0.1 * 2^N. Or you could just sort based on number of flaggings. Why does it need to be so complex? An item should never be on the review queue for more than T amount of time anyway, making the sort order a mostly inconsequential detail and we are splitting hairs at this point. > * If something is obviously being flagged falsely, the IP address of > the all flaggers are put on a silent blacklist for one day, and all > flags from these address are silently voided. > * The length of the blacklist is increased each time it's invoked. These don't contradict anything I've said. The details of punishment are orthogonal to the workflow, it is to me a well covered and thus un-interesting problem space. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/417c5e3f/attachment.pgp From secret.argent at gmail.com Sat May 3 17:06:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat May 3 17:06:17 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209858556.12336.112.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> <1209858556.12336.112.camel@localhost> Message-ID: On 2008-05-03, at 18:49, Callum Lerwick wrote: >> * Flagged posts are handled in order of some function based on how >> old they are and how many flags there are and what type there are. >> For example, spam flags get an exponential function of the number of >> flags, say 0.1 * 2^N. > > Or you could just sort based on number of flaggings. I'm assuming limited resources at Linden Labs, so I'm not assuming that they will EVER get to all flaggings. That is, this is triage. The function used would be Linden Labs' business, and tuned to fit the workload. > Why does it need to be so complex? It doesn't need to be any more complex than Linden Labs chooses to make it, but it's quite likely that it will be simpler to use a more complex function... for example, if it's easy to report spam then there's some small number below which you should completely ignore spam reports, because spam is a function of volume. >> * If something is obviously being flagged falsely, the IP address of >> the all flaggers are put on a silent blacklist for one day, and all >> flags from these address are silently voided. >> * The length of the blacklist is increased each time it's invoked. > > These don't contradict anything I've said. The details of > punishment are > orthogonal to the workflow, it is to me a well covered and thus > un-interesting problem space. This is not "punishment", because it's silent, there's no feedback to the person that their flagging has been ignored. This is part of the triage, eliminating known sources of bad information allowing them to more easily locate items that are likely to need response. From ravenglassrentals at yahoo.com Sat May 3 19:52:55 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Sat May 3 19:52:59 2008 Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 In-Reply-To: <20080504000619.D5D8441B21F@stupor.lindenlab.com> Message-ID: <22344.53368.qm@web55609.mail.re4.yahoo.com> Re: "Which is why I'm proposing a quick-reacting review team that will detect such abuse, put the listing back up, whitelist it against further abuse, and punish the abusers. Such as removing their tagging privileges for N months." No. I'm absolutely dead set against any kind of moving of the awful forums culture inworld. No policing of inworld content by other residents. We cannot have a system where one set of residents are pitted against another, policing their content. Absolutely unacceptable. The existing abuse report system should be used for content of concern, and Lindens should improve or staff up this system if policing of inworld continent becomes their priority. Don't use residents for this function. Prokofy Neva sldev-request@lists.secondlife.com wrote: Send SLDev mailing list submissions to sldev@lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request@lists.secondlife.com You can reach the person managing the list at sldev-owner@lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 2. Re: Your Feedback Wanted on Search Flagging ! (Argent Stonecutter) 3. RE: Your Feedback Wanted on Search Flagging ! (Matthew Dowd) 4. RE: Your Feedback Wanted on Search Flagging ! (Matthew Dowd) 5. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 6. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 7. Re: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 8. Re: Your Feedback Wanted on Search Flagging ! (Argent Stonecutter) ---------------------------------------------------------------------- Message: 1 Date: Sat, 03 May 2008 14:38:17 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209843497.12336.73.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Fri, 2008-05-02 at 21:44 +0000, Matthew Dowd wrote: > > If it gets more than X flags, then it gets > > automatically taken down, and it still goes to a human review team. > > All you need is a co-ordinated group of X+1 people determined to > remove say anyone selling sculpties (or a more realistic prejudice), > for them to at least temporarily get sites removed. Effectively, such > an approach is a "guilty until proven innocent" one. Yes, that's exactly what I'm considering. Which is why I'm proposing a quick-reacting review team that will detect such abuse, put the listing back up, whitelist it against further abuse, and punish the abusers. Such as removing their tagging privileges for N months. If you have a better idea, feel free to propose it. "x sucks" is not productive. "x sucks, how about y instead?" is productive. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e3f1e99a/attachment-0001.pgp ------------------------------ Message: 2 Date: Sat, 3 May 2008 15:10:55 -0500 From: Argent Stonecutter Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: SL-Dev Mailing List Message-ID: <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-05-03, at 14:38, Callum Lerwick wrote: > If you have a better idea, feel free to propose it. "x sucks" is not > productive. "x sucks, how about y instead?" is productive. Well, I proposed my alternative. But what the hell, how about another? * Nothing is banned automatically. * Flagged posts are handled in order of some function based on how old they are and how many flags there are and what type there are. For example, spam flags get an exponential function of the number of flags, say 0.1 * 2^N. * If something is obviously being flagged falsely, the IP address of the all flaggers are put on a silent blacklist for one day, and all flags from these address are silently voided. * The length of the blacklist is increased each time it's invoked. ------------------------------ Message: 3 Date: Sat, 3 May 2008 20:48:52 +0000 From: Matthew Dowd Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: Callum Lerwick , Message-ID: Content-Type: text/plain; charset="iso-8859-1" > If you have a better idea, feel free to propose it. "x sucks" is not> productive. "x sucks, how about y instead?" is productive. I did a few posts back but to expand a little: i) use Google SafeFilter for filtering out mature content in addition to the mature tag ii) work on various projects such as the landmark project to improve relevancy ranking (perhaps consider social tagging) thus pushing spam down in rank iii) use the existing AR process for prohibited listings (consider adding an AR button to search results) iv) adding a button for recommending content to the showcase (perhaps only allow one recommendation per day, restrict to PIOF accounts and/or add some token L$ fee to cut down abuse). Matthew _________________________________________________________________ Be a Hero and Win with Iron Man http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/bea7c394/attachment-0001.htm ------------------------------ Message: 4 Date: Sat, 3 May 2008 20:52:58 +0000 From: Matthew Dowd Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: Callum Lerwick , Message-ID: Content-Type: text/plain; charset="iso-8859-1" > punish the abusers. Such as removing their tagging privileges for N months. This needs to be done with care - a false report may be a genuine mistake - believing the gambling ban applies to free to pay casinos which don't give prizes, thinking the "no age play" blogs outlaw child avatars etc. Overall, the amount of manual work to deal with the system proposed doesn't sound much less (and possibly more) than the amount to deal with a traditional AR - hence my suggest to stick with the current AR process! Matthew _________________________________________________________________ Discover and Win with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e9657bff/attachment-0001.htm ------------------------------ Message: 5 Date: Sat, 03 May 2008 18:13:29 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209856410.12336.84.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 20:52 +0000, Matthew Dowd wrote: > > punish the abusers. Such as removing their tagging privileges for N > months. > > This needs to be done with care - a false report may be a genuine > mistake - believing the gambling ban applies to free to pay casinos > which don't give prizes, thinking the "no age play" blogs outlaw child > avatars etc. Yes, which is why I'm insisting the decision be made by a human being, with a user's past behavior taken in to account. A written warning can be made first, with a three strikes and you're out policy, whatever. I was being deliberately vague about the details of punishment because it is orthogonal to my proposed workflow. > Overall, the amount of manual work to deal with the system proposed > doesn't sound much less (and possibly more) than the amount to deal > with a traditional AR - hence my suggest to stick with the current AR > process! My main point is once a listing is reviewed and a decision of its legitimacy is made, that decision stands. No more flaggings/ARs are allowed, preventing an endless fight over a single listing. And the idea is that the review team is well familiar enough with the minute detail of what is against the rules and what isn't, that these decisions can be made quickly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5d274bba/attachment-0001.pgp ------------------------------ Message: 6 Date: Sat, 03 May 2008 18:21:02 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209856862.12336.92.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 20:48 +0000, Matthew Dowd wrote: > i) use Google SafeFilter for filtering out mature content in addition > to the mature tag Any automated system, even Google's, can and will be gamed by determined human beings. Requiring humans to be in the loop to counter such behavior *anyway*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5b752692/attachment-0001.pgp ------------------------------ Message: 7 Date: Sat, 03 May 2008 18:49:16 -0500 From: Callum Lerwick Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209858556.12336.112.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 15:10 -0500, Argent Stonecutter wrote: > Well, I proposed my alternative. But what the hell, how about another? > > * Nothing is banned automatically. Well fine, if everyone is so determined that any automatic takedown is evil, then N = infinity. I don't particularly care. My proposed workflow still stands. > * Flagged posts are handled in order of some function based on how > old they are and how many flags there are and what type there are. > For example, spam flags get an exponential function of the number of > flags, say 0.1 * 2^N. Or you could just sort based on number of flaggings. Why does it need to be so complex? An item should never be on the review queue for more than T amount of time anyway, making the sort order a mostly inconsequential detail and we are splitting hairs at this point. > * If something is obviously being flagged falsely, the IP address of > the all flaggers are put on a silent blacklist for one day, and all > flags from these address are silently voided. > * The length of the blacklist is increased each time it's invoked. These don't contradict anything I've said. The details of punishment are orthogonal to the workflow, it is to me a well covered and thus un-interesting problem space. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/417c5e3f/attachment-0001.pgp ------------------------------ Message: 8 Date: Sat, 3 May 2008 19:06:46 -0500 From: Argent Stonecutter Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: SL-Dev Mailing List Message-ID: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-05-03, at 18:49, Callum Lerwick wrote: >> * Flagged posts are handled in order of some function based on how >> old they are and how many flags there are and what type there are. >> For example, spam flags get an exponential function of the number of >> flags, say 0.1 * 2^N. > > Or you could just sort based on number of flaggings. I'm assuming limited resources at Linden Labs, so I'm not assuming that they will EVER get to all flaggings. That is, this is triage. The function used would be Linden Labs' business, and tuned to fit the workload. > Why does it need to be so complex? It doesn't need to be any more complex than Linden Labs chooses to make it, but it's quite likely that it will be simpler to use a more complex function... for example, if it's easy to report spam then there's some small number below which you should completely ignore spam reports, because spam is a function of volume. >> * If something is obviously being flagged falsely, the IP address of >> the all flaggers are put on a silent blacklist for one day, and all >> flags from these address are silently voided. >> * The length of the blacklist is increased each time it's invoked. > > These don't contradict anything I've said. The details of > punishment are > orthogonal to the workflow, it is to me a well covered and thus > un-interesting problem space. This is not "punishment", because it's silent, there's no feedback to the person that their flagging has been ignored. This is part of the triage, eliminating known sources of bad information allowing them to more easily locate items that are likely to need response. ------------------------------ _______________________________________________ SLDev mailing list SLDev@lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 17, Issue 13 ************************************* --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/318d951d/attachment-0001.htm From secret.argent at gmail.com Sat May 3 20:15:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat May 3 20:15:09 2008 Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 In-Reply-To: <22344.53368.qm@web55609.mail.re4.yahoo.com> References: <22344.53368.qm@web55609.mail.re4.yahoo.com> Message-ID: 110% in agreement with Prokofy here. This shouldn't be more than a tool to guide actual humans at LL, and even then I still don't think it'd be actually useful except for detecting spam. From warkirby3333 at hotmail.co.uk Sat May 3 20:25:18 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Sat May 3 20:25:20 2008 Subject: [sldev] RE: SLDev Digest, Vol 17, Issue 3 In-Reply-To: <20080502190042.98E4F113A19@stupor.lindenlab.com> References: <20080502190042.98E4F113A19@stupor.lindenlab.com> Message-ID: > * Prohibited and spam content will be taken down immediately when it > gets enough votes > * When content is flagged several times, the content owner will be > notified by SL support team and may be penalized according to > Community Standards No. This cannot work. Prohibited and spam content should come under LINDEN REVIEW, by a REAL LIVE PERSON when it recieves enough votes. Automatically deleting anything will lead to this tool being used as a weapon. Use the system only to flag and draw attention to suspect listings. Have decisions made by real people. _________________________________________________________________ Win Indiana Jones prizes with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000002ukm/direct/01/ From kamilion at gmail.com Sat May 3 20:50:24 2008 From: kamilion at gmail.com (Kamilion) Date: Sat May 3 20:50:27 2008 Subject: [sldev] Font Corruption in 1.20RC5, Need download links for previous linux builds. Message-ID: So I was following my normal update routine, download the latest RC, extract it, delete the previous RC's folder, and fire it up. Only, now in RC5, my fonts are totally hosed and the client is near completely unusable on my laptop. It was working great in previous RCs, which had fixed most of the issues I had experienced on this laptop. Found someone else had already posted this in JIRA: http://jira.secondlife.com/browse/VWR-6984 And here's my screenshot, attached to that issue: http://jira.secondlife.com/secure/attachment/16547/Screenshot.png Could someone kindly give me the download links to the official Linux 1.20RC builds for RC2, RC3, and RC4? I'll try to track down where in the chain this went sour. My hardware: Stock Fujitsu Lifebook S2020, with ATI Radeon IGP 320M / Radeon Mobility U1, Athlon XP-M 2100+ (1.66Ghz), 512MB of memory. Thanks! -- Kamilion "Never feel stupid for asking questions, feel stupid for ignoring answers." From seg at haxxed.com Sat May 3 21:51:17 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat May 3 21:51:24 2008 Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 In-Reply-To: <22344.53368.qm@web55609.mail.re4.yahoo.com> References: <22344.53368.qm@web55609.mail.re4.yahoo.com> Message-ID: <1209876678.12336.123.camel@localhost> On Sat, 2008-05-03 at 19:52 -0700, Random Unsung wrote: > Re: "Which is why I'm proposing a quick-reacting review team that will > detect such abuse, put the listing back up, whitelist it against > further abuse, and punish the abusers. Such as removing their tagging > privileges for N months." > No policing of inworld content by other residents. We cannot have a > system where one set of residents are pitted against another, policing > their content. Absolutely unacceptable. Read. Comprehend. Post. Also, trim your posts. I thought I was pretty explicit that the review team is to be Linden trusted and sanctioned, and likely even employed. Not a bunch of random residents. The bunch of random residents are the ones doing the initial flagging, the review team is what keeps them in check by making the actual decisions. But I suppose everyone rambling on about their imagined fears without actually reading the thread is par for the course. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/098a9d1b/attachment.pgp From secret.argent at gmail.com Sat May 3 22:01:05 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat May 3 22:00:34 2008 Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 In-Reply-To: <1209876678.12336.123.camel@localhost> References: <22344.53368.qm@web55609.mail.re4.yahoo.com> <1209876678.12336.123.camel@localhost> Message-ID: <26EEFB8C-11F5-4CBB-B034-AB968B25A589@gmail.com> On 2008-05-03, at 23:51, Callum Lerwick wrote: > I thought I was pretty explicit that the review team is to be Linden > trusted and sanctioned, and likely even employed. I don't think you were explicit enough about that, because it wasn't clear to me either. And it certainly wasn't anywhere in Jeska's initial comments. From whitequill.bj at gmail.com Sat May 3 22:41:40 2008 From: whitequill.bj at gmail.com (Bj Raz) Date: Sat May 3 22:41:43 2008 Subject: Fwd: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> <007d01c8acb4$525a4ec0$647ba8c0@a644000> Message-ID: ---------- Forwarded message ---------- From: Bj Raz Date: Sun, May 4, 2008 at 1:40 AM Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: Darien Caldwell I can see where Darien Caldwell is coming from about RL vs avatars. If one person owns 5 SL accounts and thus decides to abuse the system thus, you can get bad data because the person is spamming on not one account (cause you can't) but because they logged onto all five of there accounts and with all of the five different User names, voted something up or down, if griefing is done by telling others to logon to each of there accounts, then you could be getting VERY bad data because the greifers are all logging on to each of there 5 accounts and telling there friends (who are griefers) to do the same, thus manipulating the system. This is a class RED scenario, how do you see preventing this? On Fri, May 2, 2008 at 8:26 PM, Darien Caldwell wrote: > Thanks for the clarification. One Important restriction I can think of is > to not let someone's alts also flag the same listing. If you are excluding > basic accounts, there should be the ability to tell if more than one avatar > is owned by the same person. I noticed you said flagging is restricted on > an account basis, does that mean per avatar, or per actual Real Life > Individual? The distinction is relevant. :) > > Also, there is a thread I started in the SL forums on this here: > http://forums.secondlife.com/showthread.php?t=256710 If you feel brave > stop in, it's quite constructive. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Cc:* kalpana@lindenlab.com > *Sent:* Friday, May 02, 2008 5:08 PM > *Subject:* Re: [sldev] Your Feedback Wanted on Search Flagging ! > > Heya, > > Thanks for all the great thoughts everyone, very helpful! I wanted to > clarify that the Search Flagging described is for search listings -- not > inworld content, avatar or group profiles, land sales etc. - it is ONLY for > parcel listings, classified ads and events listings. Also, for those who are > concerned about abuse/griefing, here is some more detail on the proposed > design: > > * If a listing is flagged as "Mature" by x Residents and is not marked > Mature, it will be automatically changed to Mature - it will not be removed. > Totally agree that more clarity is needed around what is "mature" (and > "prohibited") I will take that back to the Governance Team as feedback. > * If a listing is flagged as "Prohibited" by x Residents, it will be > automatically taken down and reviewed by the Governance team. Prohibited > listings might include listings for gambling or child pornography. > * Not all accounts are able to flag search listings, anonymous basic > Residents or Residents who are under x days old will not be able to > participate in search flagging. > * Each account which can flag is only able do so once per search listing > and there is a limit to the amount of search listings each account can flag > per day. > * One account flagging a listing will NOT cause it to be automatically > removed > * Nominate for Showcase is that exactly - a nomination for review by an > editorial board for possible inclusion. > * Any classified ads that are taken down will be refunded (prorated for > time active), with notification > > Are there any other restrictions to who can flag or when/how/etc anyone > can think of to help both prevent overt abuse while still helping stem > grievous abuse of search listings (see: current Event Calendar spam as one > example)? > > Cheers, > Jeska > > > > Innes McLeod wrote: > > I have some reservations about this system. It seems to me that, as has > been mentioned, it can be abused to harass. To prevent it's use as > harassment, you will have to add load to the database to record where every > vote came from. The same will apply to the Showcase nominations. I can > foresee hundreds of alts being created just for the sole purpose of voting > up a single business. > > As it stands even with that system, if I see something that I feel is a > serious offense I would still send a normal AR, instead of waiting for > enough people to notice and hopefully cast their votes for the removal of > the offending content. Generally, I only report for very obvious hate > speech, or child related sexual material, and in my opinion both of those > are to important to just have them sit waiting for enough votes. > > Something I would rather see would be an expansion of the categories that > products or parcels can be listed under. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Sent:* Friday, May 02, 2008 12:35 PM > *Subject:* [sldev] Your Feedback Wanted on Search Flagging ! > > Hello! > > You've been asking us to do better with inappropriate content and content > classification and we've been listening. In an effort to make our abuse > reporting system easier to access and more effective, we are planning to > introduce a flagging system for our search results - and we'd love to get > your feedback. > > The new flagging system will help Residents to flag inappropriate postings > for rapid removal, while preserving everyone's ability to express themselves > freely in world. > > *How it will work* > > - First, when you post a classified, group, event or parcel listing, > you will have to self-declare if your content is mature or not. > - Second, every listing will have a "Flag This" link. You can use > this to report inappropriate or mis-classified content or nominate great > content for the showcase. > > *Flag Categories* > > - Mature - *the listing is adult only content* > - Prohibited - *the listing contains content that is prohibited on > SL* > - Spam - *irrelevant listings (examples: commercial posts in > non-commercial venues, event postings for non-events)* > - Showcase - *nominate something for possible inclusion in the > Second Life Showcase* (http://secondlife.com/showcase) > > *[All listings will still have to follow the Community Standardsand Terms > of Service .]* > > *Types of listings that can be flagged* > > - Parcel listings > - Classifieds > - Events > - You will not be able to flag avatar or group profiles > > *What happens when something is flagged* > > - Every flag counts as one vote for that flag category. While one > (or few) votes does nothing, if a listing receives enough votes in that > category, it will be auto-classified as reported. > - Prohibited and spam content will be taken down immediately when it > gets enough votes > - When content is flagged several times, the content owner will be > notified by SL support team and may be penalized according to Community > Standards > > *Anything else?* > > - Residents will be allowed to flag a particular search listing only > once. You cannot change your vote, so flag with care > - There will be a limit to how many times a day a Resident can flag > search listings > - Anonymous basic residents or residents whose accounts are less > than x days old will not be able to flag content > - Residents will still be able to report abusive content from > inworld via the Abuse Reporting system under the Help menu > - Of course, no system can be perfect, so if you think something was > flagged in error, you can always file a support ticket for review > > Thats it. We hope that this will make content flagging more effective and > will help the community better regulate what is appropriate and what is not. > > Please reply to this email with your thoughts and feedback on this > proposed design! > > Cheers, > Jeska, Kalpana and the LL Search Team > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > > ------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------ > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 > 8:02 AM > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > ------------------------------ > > _______________________________________________ > 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/20080504/c2cc9366/attachment-0001.htm From whitequill.bj at gmail.com Sat May 3 22:46:04 2008 From: whitequill.bj at gmail.com (Bj Raz) Date: Sat May 3 22:46:07 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <007d01c8acb4$525a4ec0$647ba8c0@a644000> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> <007d01c8acb4$525a4ec0$647ba8c0@a644000> Message-ID: I can see where Darien Caldwell is coming from about RL vs avatars. If one person owns 5 SL accounts and thus decides to abuse the system thus, you can get bad data because the person is spamming on not one account (cause you can't) but because they logged onto all five of there accounts and with all of the five different User names, voted something up or down, if griefing is done by telling others to logon to each of there accounts, then you could be getting VERY bad data because the greifers are all logging on to each of there 5 accounts and telling there friends (who are griefers) to do the same, thus manipulating the system. This is a class RED scenario, how do you see preventing this? On Fri, May 2, 2008 at 8:26 PM, Darien Caldwell wrote: > Thanks for the clarification. One Important restriction I can think of is > to not let someone's alts also flag the same listing. If you are excluding > basic accounts, there should be the ability to tell if more than one avatar > is owned by the same person. I noticed you said flagging is restricted on > an account basis, does that mean per avatar, or per actual Real Life > Individual? The distinction is relevant. :) > > Also, there is a thread I started in the SL forums on this here: > http://forums.secondlife.com/showthread.php?t=256710 If you feel brave > stop in, it's quite constructive. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Cc:* kalpana@lindenlab.com > *Sent:* Friday, May 02, 2008 5:08 PM > *Subject:* Re: [sldev] Your Feedback Wanted on Search Flagging ! > > Heya, > > Thanks for all the great thoughts everyone, very helpful! I wanted to > clarify that the Search Flagging described is for search listings -- not > inworld content, avatar or group profiles, land sales etc. - it is ONLY for > parcel listings, classified ads and events listings. Also, for those who are > concerned about abuse/griefing, here is some more detail on the proposed > design: > > * If a listing is flagged as "Mature" by x Residents and is not marked > Mature, it will be automatically changed to Mature - it will not be removed. > Totally agree that more clarity is needed around what is "mature" (and > "prohibited") I will take that back to the Governance Team as feedback. > * If a listing is flagged as "Prohibited" by x Residents, it will be > automatically taken down and reviewed by the Governance team. Prohibited > listings might include listings for gambling or child pornography. > * Not all accounts are able to flag search listings, anonymous basic > Residents or Residents who are under x days old will not be able to > participate in search flagging. > * Each account which can flag is only able do so once per search listing > and there is a limit to the amount of search listings each account can flag > per day. > * One account flagging a listing will NOT cause it to be automatically > removed > * Nominate for Showcase is that exactly - a nomination for review by an > editorial board for possible inclusion. > * Any classified ads that are taken down will be refunded (prorated for > time active), with notification > > Are there any other restrictions to who can flag or when/how/etc anyone > can think of to help both prevent overt abuse while still helping stem > grievous abuse of search listings (see: current Event Calendar spam as one > example)? > > Cheers, > Jeska > > > > Innes McLeod wrote: > > I have some reservations about this system. It seems to me that, as has > been mentioned, it can be abused to harass. To prevent it's use as > harassment, you will have to add load to the database to record where every > vote came from. The same will apply to the Showcase nominations. I can > foresee hundreds of alts being created just for the sole purpose of voting > up a single business. > > As it stands even with that system, if I see something that I feel is a > serious offense I would still send a normal AR, instead of waiting for > enough people to notice and hopefully cast their votes for the removal of > the offending content. Generally, I only report for very obvious hate > speech, or child related sexual material, and in my opinion both of those > are to important to just have them sit waiting for enough votes. > > Something I would rather see would be an expansion of the categories that > products or parcels can be listed under. > > ----- Original Message ----- > *From:* Jeska Dzwigalski > *To:* sldev@lists.secondlife.com > *Sent:* Friday, May 02, 2008 12:35 PM > *Subject:* [sldev] Your Feedback Wanted on Search Flagging ! > > Hello! > > You've been asking us to do better with inappropriate content and content > classification and we've been listening. In an effort to make our abuse > reporting system easier to access and more effective, we are planning to > introduce a flagging system for our search results - and we'd love to get > your feedback. > > The new flagging system will help Residents to flag inappropriate postings > for rapid removal, while preserving everyone's ability to express themselves > freely in world. > > *How it will work* > > - First, when you post a classified, group, event or parcel listing, > you will have to self-declare if your content is mature or not. > - Second, every listing will have a "Flag This" link. You can use > this to report inappropriate or mis-classified content or nominate great > content for the showcase. > > *Flag Categories* > > - Mature - *the listing is adult only content* > - Prohibited - *the listing contains content that is prohibited on > SL* > - Spam - *irrelevant listings (examples: commercial posts in > non-commercial venues, event postings for non-events)* > - Showcase - *nominate something for possible inclusion in the > Second Life Showcase* (http://secondlife.com/showcase) > > *[All listings will still have to follow the Community Standardsand Terms > of Service .]* > > *Types of listings that can be flagged* > > - Parcel listings > - Classifieds > - Events > - You will not be able to flag avatar or group profiles > > *What happens when something is flagged* > > - Every flag counts as one vote for that flag category. While one > (or few) votes does nothing, if a listing receives enough votes in that > category, it will be auto-classified as reported. > - Prohibited and spam content will be taken down immediately when it > gets enough votes > - When content is flagged several times, the content owner will be > notified by SL support team and may be penalized according to Community > Standards > > *Anything else?* > > - Residents will be allowed to flag a particular search listing only > once. You cannot change your vote, so flag with care > - There will be a limit to how many times a day a Resident can flag > search listings > - Anonymous basic residents or residents whose accounts are less > than x days old will not be able to flag content > - Residents will still be able to report abusive content from > inworld via the Abuse Reporting system under the Help menu > - Of course, no system can be perfect, so if you think something was > flagged in error, you can always file a support ticket for review > > Thats it. We hope that this will make content flagging more effective and > will help the community better regulate what is appropriate and what is not. > > Please reply to this email with your thoughts and feedback on this > proposed design! > > Cheers, > Jeska, Kalpana and the LL Search Team > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > > ------------------------------ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > ------------------------------ > No virus found in this incoming message. > Checked by AVG. > Version: 7.5.524 / Virus Database: 269.23.7/1411 - Release Date: 5/2/2008 > 8:02 AM > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription:https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- > ------------------------ > Jeska Dzwigalski > Community and Product Development, Linden Labjeska@lindenlab.comhttp://www.secondlife.com > Visit my Office in Second Life: http://tinyurl.com/nmhsa > ------------------------- > > > ------------------------------ > > _______________________________________________ > 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/20080504/4289299d/attachment.htm From overtake at keynet.com.br Sat May 3 22:38:59 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Sat May 3 22:50:19 2008 Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 References: <22344.53368.qm@web55609.mail.re4.yahoo.com> Message-ID: <004f01c8adaa$9ea3f550$6e00a8c0@eaurouge> Agreed Prokofy I lived under a dictatorship from my infancy until I was 25 and they had a number of censors that where "normal" people invited to do the work. Apparently it could look like a do-good job, to hold things like ultra violence and hard sex to came to children, giving rates, but they had also the power to ban totally anything they thought deserved it. That led to some crazy things like Playboy having a rule where only one nipple could show on photos... censors being virtually co-authors of songs because they changed so much the original lyrics... Not to mention the new class of people with a lot of power created with this. No, the best is to have freedom, people can choose to not see what they don?t like. And parents should take care of their sons, not expect the rest of the planet to do the work for them. Lindens should do any kind of work in this direction (since they have a "company" view of SL) so residents stay being all same level people. {}Overtake ----- Original Message ----- From: Random Unsung To: sldev@lists.secondlife.com Sent: Saturday, May 03, 2008 11:52 PM Subject: [sldev] Re: SLDev Digest, Vol 17, Issue 13 Re: "Which is why I'm proposing a quick-reacting review team that will detect such abuse, put the listing back up, whitelist it against further abuse, and punish the abusers. Such as removing their tagging privileges for N months." No. I'm absolutely dead set against any kind of moving of the awful forums culture inworld. No policing of inworld content by other residents. We cannot have a system where one set of residents are pitted against another, policing their content. Absolutely unacceptable. The existing abuse report system should be used for content of concern, and Lindens should improve or staff up this system if policing of inworld continent becomes their priority. Don't use residents for this function. Prokofy Neva sldev-request@lists.secondlife.com wrote: Send SLDev mailing list submissions to sldev@lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request@lists.secondlife.com You can reach the person managing the list at sldev-owner@lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 2. Re: Your Feedback Wanted on Search Flagging ! (Argent Stonecutter) 3. RE: Your Feedback Wanted on Search Flagging ! (Matthew Dowd) 4. RE: Your Feedback Wanted on Search Flagging ! (Matthew Dowd) 5. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 6. RE: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 7. Re: Your Feedback Wanted on Search Flagging ! (Callum Lerwick) 8. Re: Your Feedback Wanted on Search Flagging ! (Argent Stonecutter) ---------------------------------------------------------------------- Message: 1 Date: Sat, 03 May 2008 14:38:17 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209843497.12336.73.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Fri, 2008-05-02 at 21:44 +0000, Matthew Dowd wrote: > > If it gets more than X flags, then it gets > > automatically taken down, and it still goes to a human review team. > > All you need is a co-ordinated group of X+1 people determined to > remove say anyone selling sculpties (or a more realistic prejudice), > for them to at least temporarily get sites removed. Effectively, such > an approach is a "guilty until proven innocent" one. Yes, that's exactly what I'm considering. Which is why I'm proposing a quick-reacting review team that will detect such abuse, put the listing back up, whitelist it against further abuse, and punish the abusers. Such as removing their tagging privileges for N months. If you have a better idea, feel free to propose it. "x sucks" is not productive. "x sucks, how about y instead?" is productive. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e3f1e99a/attachment-0001.pgp ------------------------------ Message: 2 Date: Sat, 3 May 2008 15:10:55 -0500 From: Argent Stonecutter Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: SL-Dev Mailing List Message-ID: <303D8338-5ADE-4290-9AE2-E8C19828A445@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-05-03, at 14:38, Callum Lerwick wrote: > If you have a better idea, feel free to propose it. "x sucks" is not > productive. "x sucks, how about y instead?" is productive. Well, I proposed my alternative. But what the hell, how about another? * Nothing is banned automatically. * Flagged posts are handled in order of some function based on how old they are and how many flags there are and what type there are. For example, spam flags get an exponential function of the number of flags, say 0.1 * 2^N. * If something is obviously being flagged falsely, the IP address of the all flaggers are put on a silent blacklist for one day, and all flags from these address are silently voided. * The length of the blacklist is increased each time it's invoked. ------------------------------ Message: 3 Date: Sat, 3 May 2008 20:48:52 +0000 From: Matthew Dowd Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: Callum Lerwick , Message-ID: Content-Type: text/plain; charset="iso-8859-1" > If you have a better idea, feel free to propose it. "x sucks" is not> productive. "x sucks, how about y instead?" is productive. I did a few posts back but to expand a little: i) use Google SafeFilter for filtering out mature content in addition to the mature tag ii) work on various projects such as the landmark project to improve relevancy ranking (perhaps consider social tagging) thus pushing spam down in rank iii) use the existing AR process for prohibited listings (consider adding an AR button to search results) iv) adding a button for recommending content to the showcase (perhaps only allow one recommendation per day, restrict to PIOF accounts and/or add some token L$ fee to cut down abuse). Matthew _________________________________________________________________ Be a Hero and Win with Iron Man http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/bea7c394/attachment-0001.htm ------------------------------ Message: 4 Date: Sat, 3 May 2008 20:52:58 +0000 From: Matthew Dowd Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: Callum Lerwick , Message-ID: Content-Type: text/plain; charset="iso-8859-1" > punish the abusers. Such as removing their tagging privileges for N months. This needs to be done with care - a false report may be a genuine mistake - believing the gambling ban applies to free to pay casinos which don't give prizes, thinking the "no age play" blogs outlaw child avatars etc. Overall, the amount of manual work to deal with the system proposed doesn't sound much less (and possibly more) than the amount to deal with a traditional AR - hence my suggest to stick with the current AR process! Matthew _________________________________________________________________ Discover and Win with Live Search http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080503/e9657bff/attachment-0001.htm ------------------------------ Message: 5 Date: Sat, 03 May 2008 18:13:29 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209856410.12336.84.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 20:52 +0000, Matthew Dowd wrote: > > punish the abusers. Such as removing their tagging privileges for N > months. > > This needs to be done with care - a false report may be a genuine > mistake - believing the gambling ban applies to free to pay casinos > which don't give prizes, thinking the "no age play" blogs outlaw child > avatars etc. Yes, which is why I'm insisting the decision be made by a human being, with a user's past behavior taken in to account. A written warning can be made first, with a three strikes and you're out policy, whatever. I was being deliberately vague about the details of punishment because it is orthogonal to my proposed workflow. > Overall, the amount of manual work to deal with the system proposed > doesn't sound much less (and possibly more) than the amount to deal > with a traditional AR - hence my suggest to stick with the current AR > process! My main point is once a listing is reviewed and a decision of its legitimacy is made, that decision stands. No more flaggings/ARs are allowed, preventing an endless fight over a single listing. And the idea is that the review team is well familiar enough with the minute detail of what is against the rules and what isn't, that these decisions can be made quickly. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5d274bba/attachment-0001.pgp ------------------------------ Message: 6 Date: Sat, 03 May 2008 18:21:02 -0500 From: Callum Lerwick Subject: RE: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209856862.12336.92.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 20:48 +0000, Matthew Dowd wrote: > i) use Google SafeFilter for filtering out mature content in addition > to the mature tag Any automated system, even Google's, can and will be gamed by determined human beings. Requiring humans to be in the loop to counter such behavior *anyway*. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/5b752692/attachment-0001.pgp ------------------------------ Message: 7 Date: Sat, 03 May 2008 18:49:16 -0500 From: Callum Lerwick Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: sldev@lists.secondlife.com Message-ID: <1209858556.12336.112.camel@localhost> Content-Type: text/plain; charset="us-ascii" On Sat, 2008-05-03 at 15:10 -0500, Argent Stonecutter wrote: > Well, I proposed my alternative. But what the hell, how about another? > > * Nothing is banned automatically. Well fine, if everyone is so determined that any automatic takedown is evil, then N = infinity. I don't particularly care. My proposed workflow still stands. > * Flagged posts are handled in order of some function based on how > old they are and how many flags there are and what type there are. > For example, spam flags get an exponential function of the number of > flags, say 0.1 * 2^N. Or you could just sort based on number of flaggings. Why does it need to be so complex? An item should never be on the review queue for more than T amount of time anyway, making the sort order a mostly inconsequential detail and we are splitting hairs at this point. > * If something is obviously being flagged falsely, the IP address of > the all flaggers are put on a silent blacklist for one day, and all > flags from these address are silently voided. > * The length of the blacklist is increased each time it's invoked. These don't contradict anything I've said. The details of punishment are orthogonal to the workflow, it is to me a well covered and thus un-interesting problem space. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080503/417c5e3f/attachment-0001.pgp ------------------------------ Message: 8 Date: Sat, 3 May 2008 19:06:46 -0500 From: Argent Stonecutter Subject: Re: [sldev] Your Feedback Wanted on Search Flagging ! To: SL-Dev Mailing List Message-ID: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2008-05-03, at 18:49, Callum Lerwick wrote: >> * Flagged posts are handled in order of some function based on how >> old they are and how many flags there are and what type there are. >> For example, spam flags get an exponential function of the number of >> flags, say 0.1 * 2^N. > > Or you could just sort based on number of flaggings. I'm assuming limited resources at Linden Labs, so I'm not assuming that they will EVER get to all flaggings. That is, this is triage. The function used would be Linden Labs' business, and tuned to fit the workload. > Why does it need to be so complex? It doesn't need to be any more complex than Linden Labs chooses to make it, but it's quite likely that it will be simpler to use a more complex function... for example, if it's easy to report spam then there's some small number below which you should completely ignore spam reports, because spam is a function of volume. >> * If something is obviously being flagged falsely, the IP address of >> the all flaggers are put on a silent blacklist for one day, and all >> flags from these address are silently voided. >> * The length of the blacklist is increased each time it's invoked. > > These don't contradict anything I've said. The details of > punishment are > orthogonal to the workflow, it is to me a well covered and thus > un-interesting problem space. This is not "punishment", because it's silent, there's no feedback to the person that their flagging has been ignored. This is part of the triage, eliminating known sources of bad information allowing them to more easily locate items that are likely to need response. ------------------------------ _______________________________________________ SLDev mailing list SLDev@lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 17, Issue 13 ************************************* ------------------------------------------------------------------------------ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ------------------------------------------------------------------------------ _______________________________________________ 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/20080504/7fcba890/attachment-0001.htm From Celierra at gmail.com Sat May 3 22:53:48 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sat May 3 22:53:51 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481B9292.4080608@lindenlab.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> Message-ID: On Fri, May 2, 2008 at 6:15 PM, Rob Lanphier wrote: > Hi all, > > Let me ask this another way. Is anyone aware of published research or > other helpful information in this area that may not have been considered in > the original design? Big bonus points if you can actually provide helpful > quotes from that research that are relevant to the proposed design. > > Rob > Hmm... I think a version of the Weighted Majority Algorithm applies here (see http://www.cs.cornell.edu/courses/cs482/2008sp/handouts/prediction.pdf , section 2 and figure 1), but it'll need a few modifications. If you'll forgive me for running away with this (I need practice for my algorithms final anyway), I'd suggest: - Each normal resident is an "expert" in the terminology the algorithm. Their credibilities ("weights") start at 1. - A resident flags (predicts 1) if they saw the content for at least y seconds, and did set a flag - A resident sets an anti-flag (predicts 0) if they seem to "approve" of the search result, which can be defined as -- saw the content for at least x seconds, but didn't set a flag, and/or -- teleported to the location, and/or stayed there for a while, and/or... -- something else - Add a "null" prediction, i.e. neither a 0 nor 1. Null votes contribute to neither the weight of 0s nor the weight of 1s. Weights are neither increased nor decreased for null predictions. - The "correct answers" are derived from actions by employees or trusted volunteers The original algorithm only decreases weights for every wrong answer: when a "wrong" prediction is made, the algorithm says to knock down the weight by the constant factor r = (1-epsilon). This would constantly decrease the weights of the most active residents (due to human error and attrition). So, add a concept of forgiveness and an ability to gain credibility through correct flaggings: - When a correct prediction is made, increase the resident's weight to max(n*old_weight, maximum_weight) where 1 < n < 1/r. (Let forgiveness cost f be the number of correct flaggings necessary in order to recover from the loss of credibility due to one wrong flagging, which I think is -log base r of n.) Then: Consider all 0 and 1 votes over the past however-long period. Suspiciousness metric: sum of weights of residents predicting 1 - sum of weights of residents predicting 0 List results based on their suspiciousness metric Lindens/volunteers look at the most suspicious entries, and act on those (note that the algorithm needs "correct answers", so preferably everything should be human-checked) This has some nice properties: - Suppose that the weight of 0 votes stays relatively constant over time. x residents repeatedly flagging the same entries together can abusively/mistakenly flag at most O(log x) times in a row before their weight becomes so low that they cannot overcome the weight of 0 votes. In the worst case, the x accounts perfectly split up their votes in order to get O(x) abuses, but that requires a lot of luck (see below). - Beyond that point, those x residents would need to help the system f times (f is the forgiveness cost from before) for every time they abuse it / make a mistake. - No action needs to be taken on abusers, since their weights will silently and rapidly fall towards zero, and the abuser will just wonder why the system is not listening to their flags anymore (as long as they're ignorant of this algorithm). - Since nobody ever looks at the non-suspicious results, you can't build up forgiveness by anti-flagging "easy" results - you have to make decisions on the difficult cases. Three not-so-good properties: - If someone with perfect knowledge and x alts is trying to abuse the algorithm, that person could theoretically be able to get O(x) abuses, by doing the following: -- Group the alts into teams so that their weights sum to something just large enough to put the targets into the top-n suspiciousness list. Call this weight c. -- Flag the targets, and wait until the flagging is rejected -- Repeat step 1 with new weights (this results in 1-epsilon times fewer groupings) -- Flag the targets again -- Repeat This requires a lot of knowledge - in particular, I don't think anyone will be able to see how many flags they need to put in to get something into the suspiciousness metric. Epsilon is also pretty hard to get knowledge of. Might want to check the math on the O(x) bound... It comes from: Let r = (1-epsilon). The number of abuses is something like: x/c + (x/c)r + (x/c)r^2 + ... + (x/c)r^(-log_r (x/c)) = (x/c)*(1-r*r^log_r(c/x))/(1-r), using the formula for geometric series = (x/c)*(1-rc/x)/(1-r) = (x/c - r)/(1-r) = (1/c)(1/epsilon)x - (1-epsilon)/epsilon, substituted for r = O(x) That's a pretty small constant factor in front of the x, though. :) - If a large army of new alts flags lots of entries at once, all the metrics will be calculated with the old weights = 1, and they could pollute the entire top-n suspiciousness list. When the next few 'correct answers' come in, you'd want to knock down all the alts' weights and recalculate the applicable metrics so that the garbage entries slide off the list. I imagine that this would be quite costly. Actually getting to the point of exploiting this is *probably* too difficult, but I'm not certain... - Most flaggings (preferably all of them) need to be human-checked for the algorithm to work... There are a lot of details and pieces that can be changed while keeping most of the good stuff, so hope that helps? :) -- ~Alex and Cel From matthew.dowd at hotmail.co.uk Sun May 4 00:42:52 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun May 4 00:42:55 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209856862.12336.92.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <1209763840.12336.66.camel@localhost> <1209843497.12336.73.camel@localhost> <1209856862.12336.92.camel@localhost> Message-ID: > On Sat, 2008-05-03 at 20:48 +0000, Matthew Dowd wrote:> > i) use Google SafeFilter for filtering out mature content in addition> > to the mature tag> > Any automated system, even Google's, can and will be gamed by determined> human beings. Requiring humans to be in the loop to counter such> behavior *anyway*. Well, I assume that you don't expect people to game their results to get caught by the SafeFilter (since this would be an exercise in futitlity as to be filtered from the PG results all you need is to click the mature box!) ;-) As regards gaming the system so that mature results still appear in a PG search. What I'm not sure of is how many of the mature listings appearing are deliberate or just oversights. This would certainly catch all the oversights, and a reaosnable number of the deliberates. The genuinely determined ones which game the system and avoid the filter would still be AR-able, and hopefully using the SafeFilter (which Google will be constantly refining) will cut down the number to a manageable level. Matthew _________________________________________________________________ Be a Hero and Win with Iron Man http://clk.atdmt.com/UKM/go/msnnkmgl0010000009ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080504/4c07f0ac/attachment.htm From secret.argent at gmail.com Sun May 4 05:12:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun May 4 05:12:24 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> Message-ID: On 2008-05-04, at 00:53, Celierra Darling wrote: > - A resident sets an anti-flag (predicts 0) if they seem to "approve" > of the search result, which can be defined as > -- saw the content for at least x seconds, but didn't set a flag, > and/or > -- teleported to the location, and/or stayed there for a while, and/ > or... > -- something else Something else: acceptance or mere inaction should not imply approval. * A resident may disapprove of the whole system, or only use it to flag spam. * A resident may merely be reluctant to use the system. * A reluctant user's flag would seem to be more important. From open at autistici.org Sun May 4 06:08:57 2008 From: open at autistici.org (Opensource Obscure) Date: Sun May 4 06:09:10 2008 Subject: [sldev] slviewer, gcc-4.3 and scons =?UTF-8?Q?=3E=3D=20=30=2E=39=38?= In-Reply-To: <200805011734.21956.marvin24@gmx.de> References: <200804301642.09130.marvin24@gmx.de> <481888FB.9080804@lindenlab.com> <200805011734.21956.marvin24@gmx.de> Message-ID: <4393bd15774752b00988bd7bad1f0ef9@localhost> On Thu, 1 May 2008 17:34:21 +0200, Marvin wrote: > As this only affects people, who want to build slviewer by themself, this > may not be a big problem anyway. Should we add a note to the wiki then? The note should explain that if you want to build the viewer yourself, you also will have to solve this issue on your own. This may be easy for most developers that rebuild the viewer, but it may not be trivial for everybody; example - I am not a developer and I am not very skilled about handling sources, libraries, patches, compilator versions and such. However, sometimes I build the SL viewer on my own, and I usually succeed in that. I can do that because of the wiki page instructions. I do this mainly for two reasons: 1. as http://wiki.secondlife.com/wiki/Get_source_and_compile states, ''Even if you don't plan to develop, just the act of downloading and compiling can uncover problems'' 2. little trivial patches and workarounds - example: http://jira.secondlife.com/browse/VWR-2085 (still unassigned) -> since months, on Linux you can't hide the UI if you don't modify a line in llviewermenu.cpp and then recompile from sources I agree with you that both these reasons are 'not a big problem' when compared to other viewer issues. However I'd be glad if you/someone could resume the 'slviewer, gcc-4.3 and scons >= 0.98' issue to a phrase/paragraph, so that I can add it to the wiki page. At least, lame people like me will be warned of this issue before we try building the viewer. I would write the note myself but I actually can't provide a precise answer in correct technical english terms. Opensource Obscure From marvin24 at gmx.de Sun May 4 09:25:29 2008 From: marvin24 at gmx.de (Marvin) Date: Sun May 4 09:29:15 2008 Subject: [sldev] slviewer, gcc-4.3 and scons >= 0.98 In-Reply-To: <54e66b8159de210a710dc8fbd7c8411a@localhost> References: <200804301642.09130.marvin24@gmx.de> <481888FB.9080804@lindenlab.com> <200805011734.21956.marvin24@gmx.de> <54e66b8159de210a710dc8fbd7c8411a@localhost> Message-ID: <1209918333.8436.6.camel@localhost.localdomain> Hi, I succeeded in building with gcc-4.3 and scons 0.98. Turns out, that scons didn't like TMP_BUILD_DIR to be set to "/" - mmh. There was another missing include later, so I attach two patches, which make 1.20.5 compile (and run) for me. Maybe these can be applied to the branch (I don't like jira). Greetings Marvin On Sun, 2008-05-04 at 13:04 +0000, Opensource Obscure wrote: > On Thu, 1 May 2008 17:34:21 +0200, Marvin wrote: > > > As this only affects people, who want to build slviewer by themself, this > > > may not be a big problem anyway. > > > > Should we add a note to the wiki then? > > The note should explain that if you want to build the viewer yourself, > > you also will have to solve this issue on your own. > > > > This may be easy for most developers that rebuild the viewer, > > but it may not be trivial for everybody; example - I am not a > > developer and I am not very skilled about handling sources, > > libraries, patches, compilator versions and such. However, sometimes > > I build the SL viewer on my own, and I usually succeed in that. > > I can do that because of the wiki page instructions. > > > > I do this mainly for two reasons: > > > > 1. as http://wiki.secondlife.com/wiki/Get_source_and_compile states, > > ''Even if you don't plan to develop, just the act of downloading > > and compiling can uncover problems'' > > > > 2. little trivial patches and workarounds - example: > > http://jira.secondlife.com/browse/VWR-2085 (still unassigned) > > -> since months, on Linux you can't hide the UI if you don't modify a > > line in llviewermenu.cpp and then recompile from sources > > > > I agree that both these reasons are 'not a big problem' when compared > > to other viewer issues. > > > > However I'd be glad if you/someone could resume the 'slviewer, > > gcc-4.3 and scons >= 0.98' issue to a phrase/paragraph, so that > > I can add it to the wiki page. At least, lame people like me > > will be warned of this issue before we try building the viewer. > > > > > > Opensource Obscure > > -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-1.20.5-fix_boost_in_SConstruct.patch Type: application/x-shellscript Size: 1824 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080504/d926f6cc/slviewer-1.20.5-fix_boost_in_SConstruct.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-1.20.5-fixes_for_gcc43.patch Type: application/x-shellscript Size: 2306 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080504/d926f6cc/slviewer-1.20.5-fixes_for_gcc43.bin From annagulaev at gmail.com Sun May 4 11:37:07 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun May 4 11:37:11 2008 Subject: [sldev] Re: [VWR] fmod.dll not found In-Reply-To: References: Message-ID: How does a windows program built with visual studio know where to look for DLLs? Every suggestion I can find says to put the path in the PATH environment variable. Clearly, this is not how the SL viewer knows to find fmod.dll in the newview directory, because I don't have newview in my path, and version 1.18.4.3 worked fine. 1.20.rc5 does not find it. 1.18.4.3 does. the fmod DLL is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview the executable is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview/Release How is the SL viewer finding (or not!) the fmod DLL? Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080504/aa597203/attachment-0001.htm From soft at lindenlab.com Sun May 4 11:44:57 2008 From: soft at lindenlab.com (Soft) Date: Sun May 4 11:45:00 2008 Subject: [sldev] Re: [VWR] fmod.dll not found In-Reply-To: References: Message-ID: On Sun, May 4, 2008 at 1:37 PM, Anna Gulaev wrote: > How does a windows program built with visual studio know where to look for > DLLs? > > Every suggestion I can find says to put the path in the PATH environment > variable. Clearly, this is not how the SL viewer knows to find fmod.dll in > the newview directory, because I don't have newview in my path, and version > 1.18.4.3 worked fine. 1.20.rc5 does not find it. 1.18.4.3 does. > > the fmod DLL is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview > the executable is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview/Release > > How is the SL viewer finding (or not!) the fmod DLL? Hello, Anna. I believe that Windows treats the current directory as though it were part of the path. So what you probably want to do if you wish to run the viewer in this fashion is to make a shortcut or a batch file that sets the newview directory as the current directory, and then run the release executable without actually switching to that directory. From annagulaev at gmail.com Sun May 4 11:55:24 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun May 4 11:55:26 2008 Subject: [sldev] Re: [VWR] fmod.dll not found In-Reply-To: References: Message-ID: Thanks, Soft. That's what I did. I made a shortcut with the newview directory as the start directory. Works dandily :) Anna On Sun, May 4, 2008 at 2:44 PM, Soft wrote: > On Sun, May 4, 2008 at 1:37 PM, Anna Gulaev wrote: > > How does a windows program built with visual studio know where to look > for > > DLLs? > > > > Every suggestion I can find says to put the path in the PATH environment > > variable. Clearly, this is not how the SL viewer knows to find fmod.dll > in > > the newview directory, because I don't have newview in my path, and > version > > 1.18.4.3 worked fine. 1.20.rc5 does not find it. 1.18.4.3 does. > > > > the fmod DLL is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview > > the executable is here: > /cygdrive/c/sl/1.20.rc5/linden/indra/newview/Release > > > > How is the SL viewer finding (or not!) the fmod DLL? > > Hello, Anna. I believe that Windows treats the current directory as > though it were part of the path. So what you probably want to do if > you wish to run the viewer in this fashion is to make a shortcut or a > batch file that sets the newview directory as the current directory, > and then run the release executable without actually switching to that > directory. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080504/b11c4a26/attachment.htm From rms at gnu.org Sun May 4 13:08:39 2008 From: rms at gnu.org (Richard M Stallman) Date: Sun May 4 13:09:12 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <480E8C28.3080508@lindenlab.com> (poppy@lindenlab.com) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> Message-ID: Please forgive the delay in my response. I have been very overloaded. Allowing the contributor of a change to use his own code however he wishes, even after he has contributed it to the original program, is the right thing to do. But I think it is not enough to deal with this issue. The possibility I would like to avoid is that the developer might include my code in a non-free version while not including it in his comparable free version. If he did that, then my contribution would primarily aid non-free software. Even though I would be allowed to add it myself to a free fork -- supposing there is one -- that would not be enough to change the situation. So I think that we should call on such developers to make a promise such as, "If we include your code in a non-free version, we will include your code with equal functionality and technical advantahes in a free version, and that free version will have all the features and capabilities that are common to that non-free version and the free version you improved." With that promise, you will know that your code will contribute to a free version that isn't just demoware. From gigstaggart at gmail.com Sun May 4 14:46:14 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun May 4 14:46:19 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> Message-ID: <481E2EA6.2030107@gmail.com> Argent Stonecutter wrote: > Something else: acceptance or mere inaction should not imply approval. > * A resident may disapprove of the whole system, or only use it to > flag spam. > * A resident may merely be reluctant to use the system. > * A reluctant user's flag would seem to be more important. I'm not sure that's a bad thing. If you hate the system so much that you never use it, yet you still find an entry objectionable enough to flag, that entry must be pretty bad. Really I'd be more worried about there being no server-side way to determine this implicit approval. Also it wouldn't be too hard for someone to implicitly approve a few thousand messages with a bot, since most of them won't be incorrect (most entries are legit), and boost a bad weight that way. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080504/03cd2442/smime.bin From gigstaggart at gmail.com Sun May 4 14:50:04 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun May 4 14:50:07 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481B9050.2010200@gmx.net> References: <481B50DE.8080500@lindenlab.com> <481B87DB.6070001@gmx.net> <481B89F5.2070509@streamsense.net> <481B8D57.5040707@gmx.net> <481B9050.2010200@gmx.net> Message-ID: <481E2F8C.5080202@gmail.com> Felix Duesenburg wrote: > Such a thing once was in place already, with the rating system for > avatars. It was scrapped just around the time when I first came, but I > met older users who were quite sad about it going away because it had > cost them a lot of work to build up their excellent rating. Well yeah. That was the problem. People worked on boosting their rating instead of actually contributing the things the rating was supposed to rate. An open ended positive feedback system just leads to feedback whoring. c.f. eBay and Slashdot back when Slashdot displayed a numerical karma score on your profile. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080504/1b04f593/smime.bin From secret.argent at gmail.com Sun May 4 15:16:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun May 4 15:15:52 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481E2EA6.2030107@gmail.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> <481E2EA6.2030107@gmail.com> Message-ID: <37F33680-107D-42E7-A077-7C5DB076185E@gmail.com> On 2008-05-04, at 16:46, Jason Giglio wrote: > Argent Stonecutter wrote: >> Something else: acceptance or mere inaction should not imply >> approval. >> * A resident may disapprove of the whole system, or only use it to >> flag spam. >> * A resident may merely be reluctant to use the system. >> * A reluctant user's flag would seem to be more important. > > I'm not sure that's a bad thing. If you hate the system so much that > you never use it, yet you still find an entry objectionable enough to > flag, that entry must be pretty bad. I think you're agreeing with what I intended to convey. :) From Celierra at gmail.com Sun May 4 16:27:03 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sun May 4 16:27:05 2008 Subject: [sldev] Research on flagging/rating systems? (Re: Your Feedback Wanted on Search Flagging !) In-Reply-To: <481E2EA6.2030107@gmail.com> References: <481B50DE.8080500@lindenlab.com> <481B5227.4060703@gmail.com> <481B5249.3080700@streamsense.net> <481B5720.3030605@lindenlab.com> <481B9292.4080608@lindenlab.com> <481E2EA6.2030107@gmail.com> Message-ID: On Sun, May 4, 2008 at 5:46 PM, Jason Giglio wrote: > ... Also it wouldn't be too hard for > someone to implicitly approve a few thousand messages with a bot, since > most of them won't be incorrect (most entries are legit), and boost a > bad weight that way. > If you bot-approve a few thousand messages and none of them are controversial, then you don't get any extra weight because the Lindens/volunteers will never get around to those. Alternatively, you can also explicitly forgive more/less based upon how controvercial the case was, with a max gain of 1/r down to a factor of only 1 for no-controversy cases. On Sun, May 4, 2008 at 5:46 PM, Jason Giglio wrote: > Argent Stonecutter wrote: > > Something else: acceptance or mere inaction should not imply approval. > > * A resident may disapprove of the whole system, or only use it to > > flag spam. > > * A resident may merely be reluctant to use the system. > > * A reluctant user's flag would seem to be more important. > > I'm not sure that's a bad thing. If you hate the system so much that > you never use it, yet you still find an entry objectionable enough to > flag, that entry must be pretty bad. > > Really I'd be more worried about there being no server-side way to > determine this implicit approval. I think this is generally a problem about how to define an approval vote... My first instinct was to just define it such that the most utilized entries are harder to flag, but yes, then an implicit anti-flag shouldn't have a major penalty for those not very willing to participate in the system.... But whatever definition is eventually used, there needs to be *some* penalty for incorrect approval votes, because otherwise bots would be able to continually approve of bad things to keep things them away from the top-n list. That reminds me, I forgot something... as I had defined things, occasionally one would need to check a list that's something like the top-n by min(weight of 0s, weight of 1s), to watch for abuses of bots trying to keep something out of suspicion (by flooding with approvals). -- ~Alex and Cel From seg at haxxed.com Sun May 4 19:13:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun May 4 19:13:38 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> <007d01c8acb4$525a4ec0$647ba8c0@a644000> Message-ID: <1209953609.12336.140.camel@localhost> On Sun, 2008-05-04 at 01:46 -0400, Bj Raz wrote: > I can see where Darien Caldwell is coming from about RL vs avatars. > If one person owns 5 SL accounts and thus decides to abuse the system > thus, you can get bad data because the person is spamming on not one > account (cause you can't) but because they logged onto all five of > there accounts and with all of the five different User names, voted > something up or down, if griefing is done by telling others to logon > to each of there accounts, then you could be getting VERY bad data > because the greifers are all logging on to each of there 5 accounts > and telling there friends (who are griefers) to do the same, thus > manipulating the system. > > This is a class RED scenario, how do you see preventing this? Sigh, once again, my proposal handles this just fine. It doesn't matter if its one person or a group of people trying to game the system, if they concentrate on a single listing, all it will accomplish is to push that listing higher in the review queue, meaning the review team will get to it sooner, who will then whitelist the listing as being legitimate, thus protecting that listing from all further abuse. Flooding a legitimate listing with illegitimate flaggings will only result in making the abuse attempt all the more obvious, and thus the more likely, and quickly, the review team's banhammer will come down on the abusers. Seriously, I'm a connoisseur of interweb drama. I've seen it all. Go ahead, try and stump me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080504/547d5dc5/attachment-0001.pgp From jessesa at gmail.com Sun May 4 19:40:16 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Sun May 4 19:40:19 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <1209953609.12336.140.camel@localhost> References: <481B50DE.8080500@lindenlab.com> <018201c8aca0$5a660780$6601a8c0@Topaz> <481BAD10.5020305@lindenlab.com> <007d01c8acb4$525a4ec0$647ba8c0@a644000> <1209953609.12336.140.camel@localhost> Message-ID: > On 5/4/08, Callum Lerwick wrote: > Flooding a legitimate listing with illegitimate flaggings will only > result in making the abuse attempt all the more obvious, and thus the > more likely, and quickly, the review team's banhammer will come down on > the abusers. I would imagine an unusual pattern of flaggings would also raise a bit of curiosity. It wouldn't take too much intelligience for someone to notice a bunch of different accounts all flagging from the same ip address. It is one thing if we were talking about strictly a machine algorithm for someone to game but when the final review is ultimately in human hands, it becomes considerably more difficult. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080504/32365cab/attachment.htm From lenglish5 at cox.net Sun May 4 19:49:23 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun May 4 19:49:25 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> Message-ID: <481E75B3.1080907@cox.net> Richard M Stallman wrote: > Please forgive the delay in my response. I have been very overloaded. > > Allowing the contributor of a change to use his own code > however he wishes, even after he has contributed it to > the original program, is the right thing to do. But I think > it is not enough to deal with this issue. > > The possibility I would like to avoid is that the developer might > include my code in a non-free version while not including it in his > comparable free version. If he did that, then my contribution would > primarily aid non-free software. Even though I would be allowed to > add it myself to a free fork -- supposing there is one -- that would > not be enough to change the situation. > > So I think that we should call on such developers to make a promise > such as, "If we include your code in a non-free version, we will > include your code with equal functionality and technical advantahes in > a free version, and that free version will have all the features and > capabilities that are common to that non-free version and the free > version you improved." > > With that promise, you will know that your code will contribute to a > free version that isn't just demoware. > I can see what you're saying, but consider the possibility that the commercial license, done by a third party, forks well away from the current free version. The example I have in mind is the Second Life OnRez viewer, which is the only commercial version of the Second Life viewer I'm aware of. Many people prefer the interface of the OnRez viewer (which is also a free download used for the SL CSI:NY TV tie-in) but some features found in the latest open source viewer aren't found in the OnRez version and visa versa. It seems to me that your clause about equal functionality and so on might not apply in this case for various legitimate (non-deceptive) reasons. Lawson From robin.cornelius at gmail.com Mon May 5 02:19:08 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon May 5 02:19:19 2008 Subject: [sldev] Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: References: Message-ID: <481ED10C.5000609@gmail.com> Kamilion wrote: > So I was following my normal update routine, download the latest RC, > extract it, delete the previous RC's folder, and fire it up. > Only, now in RC5, my fonts are totally hosed and the client is near > completely unusable on my laptop. > It was working great in previous RCs, which had fixed most of the > issues I had experienced on this laptop. > > Found someone else had already posted this in JIRA: > http://jira.secondlife.com/browse/VWR-6984 I'm glad its not a me only bug again. Thats quite interesting that you say this has got worse from early 1.20.X RCs to now. I certainly saw this in RC4, i didn't test before RC4 on the effected hardware. I did have other corruption in earlier versions but something has changed to make this severe corruption in the RC. What i may do is check out specific revisions from SVN on the 1.20 branch and try to isolate a revision where it went wrong but as the revisions tend to me bulk synchronises from internal SVN it still leaves quite a wide code base even if i find a specific revision. If you do find anything please ping me directly as well as VWR-6984 Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080505/e42461b2/signature.pgp From Anders at Arnholm.se Mon May 5 05:53:52 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Mon May 5 05:59:19 2008 Subject: [sldev] 1.20rc5 linux: missing boost_signals-gcc34-mt In-Reply-To: References: <481B998E.5090207@gmx.net> <481BA68C.6020203@gmx.net> Message-ID: <481F0360.50705@Arnholm.se> Anna Gulaev skrev: > On 5/2/08, *Anna Gulaev* wrote: > > The boost libraries last appeared in a linux release for 1.20 RC2. > RC3,4 and 5 are all missing these files. > > > It's also missing ll_icon.png > I found ll_icon.BMP in a previous verion and converted using GIMP. It > doesn't seem to use the icon, but it needs to be there for the build. Took the file out of the viewer_maifest.py file om my side, and filed a jira about it. http://jira.secondlife.com/browse/VWR-6749 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From alissa_sabre at yahoo.co.jp Mon May 5 07:26:18 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon May 5 07:26:25 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: <481BAD10.5020305@lindenlab.com> References: <481BAD10.5020305@lindenlab.com> Message-ID: <77ds4eL4eb4s25e2Yds4f.alissa_sabre@yahoo.co.jp> Several questions and comments that I beielve are not discussed yet on this list: > * First, when you post a classified, group, event or parcel > listing, you will have to self-declare if your content is > mature or not. > * If a listing is flagged as "Mature" by x Residents and is not marked > Mature, it will be automatically changed to Mature - it will not be > removed. Totally agree that more clarity is needed around what is I believe entries that are already self-declared as Mature are not flagged for Mature, because it is OK to list, e.g., mature events as long as it is marked as Mature. Am I correct? Assuming I am, my question is: is it enforced by the system? (E.g., the "Mature" radio button is greyed out for a Mature Event listing.) Another questin is: what is the LL policy on the contrary, i.e., is it allowed to self-declare no Mature things as Mature? How we can flag it, if it isn't? > > *Flag Categories* > > > > * Mature - /the listing is adult only content/ > > * Prohibited - /the listing contains content that is > > prohibited on SL/ > > * Spam - /irrelevant listings (examples: commercial posts in > > non-commercial venues, event postings for non-events)/ > > * Showcase - /nominate something for possible inclusion in the > > Second Life Showcase/ (http://secondlife.com/showcase) The first three categories (mature, prohibited, and spam) are negative flagging. The last one, showcase, is positive. I think it is a bad practice to put things of opposite purpose into a single "flagging" user interface. It will confuse residents, and the objective of the new flagging system unclear. Even if the underlying mechanism to handle is same for all four categories, there should be clear distinction; e.g., a link labeled "Flag this" for the first three categories, and another link labeled "Recommend this" for the Showcase category. > > * When content is flagged several times, the content owner > > will be notified by SL support team and may be penalized > > according to Community Standards > > Well, I don't think you intended to do this for a resident whose contents are frequently flagged as "Showcase"... I think you confused yourself by putting negative and positive things into a single "flagging". > > * Spam - /irrelevant listings (examples: commercial posts in > > non-commercial venues, event postings for non-events)/ As far as I understand, a usual understanding of the word SPAM is to show something, usually an advertisement, that is not wanted by the receipients a lot of times to a lot of people. I don't think your examples fall into my understanding of the word SPAM. If my understanding of the word SPAM is wrong (it is very likely because I'm not an English speaker), that's fine. However, I understand the word correctly, I recommend to change the name for the category that is suitable for the cases that you want to catch. > * If a listing is flagged as "Prohibited" by x Residents, it will be > automatically taken down and reviewed by the Governance team. "automatically taken down and reviewed"? Why this is not "reviewed and taken down if it is recognized as prohibited"? You Linden Governers will review it very soon, anyway, then why do you take it down before review? This may depends on how large the "x" is; if x is 10,000, taking down before review may be OK. But if it is 10 or 20, I don't think it is adequate. > * Not all accounts are able to flag search listings, anonymous basic > Residents or Residents who are under x days old will not be able to > participate in search flagging. What is "anonymous basic resident"? Is it residents with "payment info not on file"? If it is it, I believe LL is doing an inappropriate thing here. I understand that LL considered the difference between "payment info not on file" and "payment info used" has no meaning, and that is the reason LL introduced separate age verification system... > > * Of course, no system can be perfect, so if you think > > something was flagged in error, you can always file a > > support ticket for review Does this mean residents with basic accounts are unable to oppose to false flagging? Alissa Sabre -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From kittenlulu at gmail.com Mon May 5 09:17:22 2008 From: kittenlulu at gmail.com (Kitten Lulu) Date: Mon May 5 09:17:28 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device Message-ID: Hello, Thanks to Apple, I can now write apps for iPhone and iPod Touch devices. They have accelerometers, an app can read the orientation in 3D space of the device. I got an idea for an app that I'd love to develop. Imagine a modified/future Second Life client that (in addition to the usual on-screen rendering) streams a first-person 3D view to the iPhone/iPodTouch. Imagine being able to tilt and move the device to look around, use multi-touch fingers to zoom-in and out, use taps to move around. (*) Imagine being able to do all that without requiring custom hardware or headtracking. Imagine distributing it for free thru Apple's iTunes and AppStore to all iPhone and iPod Touch users worldwide. Anyone wants to help? I can do the iPhone/iPod touch part, but I don't know where to start with the Second Life client parts. -- Kitten Lulu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080505/36316337/attachment.htm From carjay at gmx.net Mon May 5 09:58:25 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon May 5 09:58:33 2008 Subject: [sldev] Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: <481ED10C.5000609@gmail.com> References: <481ED10C.5000609@gmail.com> Message-ID: <481F3CB1.6070409@gmx.net> Robin Cornelius wrote: > I'm glad its not a me only bug again. Thats quite interesting that you > say this has got worse from early 1.20.X RCs to now. I certainly saw > this in RC4, i didn't test before RC4 on the effected hardware. > Interesting effect, I also have never seen this on my AMD64 hardware. The effect reminds me of what you get when the GL texture unit is not correctly set up (blending is not enabled or set up wrong) so you do not see the glyphs but rather their surrounding "bounding boxes". Since it only affects a certain subset of fonts it seems to rely on a specific precondition. Maybe you could narrow it down by comparing between the working and nonworking states? Regards, Carsten From sakkaku at gmail.com Mon May 5 10:04:02 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon May 5 10:04:06 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: References: Message-ID: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> > Hello, > > Thanks to Apple, I can now write apps for iPhone and iPod Touch devices. > They have accelerometers, an app can read the orientation in 3D space of the > device. > > I got an idea for an app that I'd love to develop. > > Imagine a modified/future Second Life client that (in addition to the usual > on-screen rendering) streams a first-person 3D view to the iPhone/iPodTouch. > > Imagine being able to tilt and move the device to look around, use > multi-touch fingers to zoom-in and out, use taps to move around. (*) > > Imagine being able to do all that without requiring custom hardware or > headtracking. > > Imagine distributing it for free thru Apple's iTunes and AppStore to all > iPhone and iPod Touch users worldwide. > > Anyone wants to help? > > I can do the iPhone/iPod touch part, but I don't know where to start with > the Second Life client parts. > > -- > Kitten Lulu The main problem will be the iPhones rather limited ram (128MB supposedly), the "official" graphical client consumes 400+MB most of the time on my system. It may be possible to use libsl to make a client, supposedly there is an ObjC# compiler out for the iPhone, but you likely wont be able to have any graphics. While it is a wonderful idea I think it isn't really practical due to the hardware limitations of the iPhone itself. From carjay at gmx.net Mon May 5 10:04:35 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon May 5 10:04:39 2008 Subject: [sldev] Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: <481F3CB1.6070409@gmx.net> References: <481ED10C.5000609@gmail.com> <481F3CB1.6070409@gmx.net> Message-ID: <481F3E23.7010202@gmx.net> Carsten Juttner wrote: > The effect reminds me of what you get when the GL texture unit is not > correctly set up (blending is not enabled or set up wrong) so you do > not see the glyphs but rather their surrounding "bounding boxes". Argh, should check before I post :) That should have read "when the GL *state* is not correctly set up". Regards, Carsten From cjbreisch at yahoo.com Mon May 5 11:40:09 2008 From: cjbreisch at yahoo.com (Chris J. Breisch) Date: Mon May 5 11:40:22 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> References: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> Message-ID: <000301c8aedf$744aac50$5ce004f0$@com> And the slow network would bother me. Do you really want an EDGE device for SL? I'd be more tempted to do something on EV-DO with Windows Mobile. However, on a similar note, is there any progress on the SL thin client? I remember reading in January that LL was expecting there to be a public beta available in February. I'm looking at my calendar and it appears to be May, with no thin client alpha or beta in sight. Chris J. Breisch -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Matthew Underwood Sent: Monday, May 05, 2008 1:04 PM To: Kitten Lulu Cc: sldev@lists.secondlife.com Subject: Re: [sldev] iPhone/iPod Touch as a Second Life I/O device The main problem will be the iPhones rather limited ram (128MB supposedly), the "official" graphical client consumes 400+MB most of the time on my system. It may be possible to use libsl to make a client, supposedly there is an ObjC# compiler out for the iPhone, but you likely wont be able to have any graphics. While it is a wonderful idea I think it isn't really practical due to the hardware limitations of the iPhone itself. _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sakkaku at gmail.com Mon May 5 11:47:34 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Mon May 5 11:47:36 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <000301c8aedf$744aac50$5ce004f0$@com> References: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> <000301c8aedf$744aac50$5ce004f0$@com> Message-ID: <79e704e0805051147h407be769m99f0e86b051b4afb@mail.gmail.com> > And the slow network would bother me. Do you really want an EDGE device for SL? I'd be more tempted to do something on EV-DO with Windows Mobile. > > However, on a similar note, is there any progress on the SL thin client? I remember reading in January that LL was expecting there to be a public beta available in February. I'm looking at my calendar and it appears to be May, with no thin client alpha or beta in sight. > > Chris J. Breisch >From what they replied with it appears they want to develop an interface to interact with SL. To capture the OpenGL output and stream it to the device then use the motion/touch to interact with the client. So then you could assume that you would be over an 802.11b or g network. I would love a thin client, most people would probably migrate over in a few moments of hearing about it if it was even halfway more stable then the official one now. From kwerks.sl at gmail.com Mon May 5 11:49:50 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Mon May 5 11:49:52 2008 Subject: [sldev] 1.20.5 os/x build Message-ID: <7b61e3970805051149k275c0ce2m7d7df08c9307d496@mail.gmail.com> I searched the list but couldn't find reference to this issue and it seems like it does not a warrant a JIRA so I thought I would post here in case it didn't get picked up elsewhere. I had to comment out the following line to get the viewer to run, it built ok. Generally not good to comment out an assertion unless of course the assertion is incorrect. Apologies for not having time to track down the cause in a more meaningful way. llrender/llimagegl.cpp Line 631: //llassert(prev_mip_size == bytes); MacBook Pro 10.5.2, ATI regards JB -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080505/dadcc794/attachment.htm From monkowsk at watson.ibm.com Mon May 5 13:47:53 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon May 5 14:55:20 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: References: Message-ID: <481F7279.809@watson.ibm.com> You mean something like http://www.youtube.com/watch?v=bJF3LBREabk or http://www.youtube.com/watch?v=XwRnjbkljnc Mike Kitten Lulu wrote: > Hello, > > Thanks to Apple, I can now write apps for iPhone and iPod Touch devices. > They have accelerometers, an app can read the orientation in 3D space of > the device. > > I got an idea for an app that I'd love to develop. > > Imagine a modified/future Second Life client that (in addition to the > usual on-screen rendering) streams a first-person 3D view to the > iPhone/iPodTouch. > > Imagine being able to tilt and move the device to look around, use > multi-touch fingers to zoom-in and out, use taps to move around. (*) > > Imagine being able to do all that without requiring custom hardware or > headtracking. > > Imagine distributing it for free thru Apple's iTunes and AppStore to all > iPhone and iPod Touch users worldwide. > > Anyone wants to help? > > I can do the iPhone/iPod touch part, but I don't know where to start > with the Second Life client parts. > > -- > Kitten Lulu From rms at gnu.org Mon May 5 15:06:53 2008 From: rms at gnu.org (Richard M Stallman) Date: Mon May 5 15:07:30 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <481E75B3.1080907@cox.net> (message from Lawson English on Sun, 04 May 2008 19:49:23 -0700) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <481E75B3.1080907@cox.net> Message-ID: I can see what you're saying, but consider the possibility that the commercial license, done by a third party, forks well away from the current free version. The example I have in mind is the Second Life OnRez viewer, which is the only commercial version of the Second Life viewer I'm aware of. Since these are non-free programs, they are, of course, unethical. But the problem we're trying to avoid here is more specific than that. I think that if the original developer agrees to the condition I proposed then no abuse of our code could occur. The reason is that if the source made available by the original developer for third-party non-free software contains our code, this condition will require that the free version also contain our code. Once that is the case, the third-party non-free program cannot contain any of our code which is not in the free version. Many people prefer the interface of the OnRez viewer (which is also a free download Do you mean "gratis download"? I presume this is not free software. used for the SL CSI:NY TV tie-in) but some features found in the latest open source viewer Since I disagree with the basic ideas of "open source", I have to point out that the issue I am concerned about is whether the program is free (libre) software -- not whether it is open source. The two criteria are not the same, and the two philosophies are based on very different values. See http://www.gnu.org/philosophy/open-source-misses-the-point.html for more explanation of the difference between free software and open source. From lenglish5 at cox.net Mon May 5 16:17:05 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon May 5 16:17:06 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <79e704e0805051147h407be769m99f0e86b051b4afb@mail.gmail.com> References: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> <000301c8aedf$744aac50$5ce004f0$@com> <79e704e0805051147h407be769m99f0e86b051b4afb@mail.gmail.com> Message-ID: <481F9571.30107@cox.net> Matthew Underwood wrote: >> And the slow network would bother me. Do you really want an EDGE device for SL? I'd be more tempted to do something on EV-DO with Windows Mobile. >> >> However, on a similar note, is there any progress on the SL thin client? I remember reading in January that LL was expecting there to be a public beta available in February. I'm looking at my calendar and it appears to be May, with no thin client alpha or beta in sight. >> >> Chris J. Breisch >> > > >From what they replied with it appears they want to develop an > interface to interact with SL. To capture the OpenGL output and > stream it to the device then use the motion/touch to interact with the > client. So then you could assume that you would be over an 802.11b or > g network. > > I would love a thin client, most people would probably migrate over in > a few moments of hearing about it if it was even halfway more stable > then the official one now. > How thin is "thin?" Logging onto SL and keeping Ruth there indefinitely takes less than 350 lines of Python. http://wiki.secondlife.com/wiki/Presence_Code_Python. Group IM won't take that much more, assuming I ever figure out the details (my Python group-IM-bot has about 700 lines total, but is not quite working). If you're not interested in 3D display and don't care about being Ruth, implementing most features in SL would be relatively thin. libsl's biggest bloat is an optimization to create about 100K lines of inline C# code to handle packet processing for all packets as fast as possible. Once the new login procedure using Agent Domains is implemented, even Ruth goes away since you will be able to handle group IM and inventory management without having a presence in a simulator and you'll need to implement packet-handling only for those specific packets associated with IM and Inventory. If you want lightweight clients that can navigate in-world, you'll still need to worry about Ruthiness (baking textures) and handling 3D info, unless you can convince LL to provide a separate CAP to the mini-map info. I made a humorous remark about a 2D side-scroller SL at the OpenSource office hours a while back, but for smart phones, being able to at least see your avatar on the mini-map in relation to other avatars may be all that you need for at least SOME level of social interaction. Lawson From jeska at lindenlab.com Mon May 5 16:22:34 2008 From: jeska at lindenlab.com (Jeska Dzwigalski) Date: Mon May 5 16:25:14 2008 Subject: [sldev] Your Feedback Wanted on Search Flagging ! In-Reply-To: References: <481B50DE.8080500@lindenlab.com> Message-ID: <481F96BA.4000902@lindenlab.com> Heya, Thank you all for your feedback on the proposed design for Search Flagging (including Argent's succinct feedback below) - I will be taking it back to the Search Team for their review and hopefully have some more information for you soon. Cheers, - Jeska Argent Stonecutter wrote: > On 2008-05-02, at 12:35, Jeska Dzwigalski wrote: >> You've been asking us to do better with inappropriate content and >> content classification and we've been listening. In an effort to make >> our abuse reporting system easier to access and more effective, we >> are planning to introduce a flagging system for our search results - >> and we'd love to get your feedback. > > > My feedback, as a 20 year network administrator who has at times been > at the forefront of the anti-spam effort in Usenet and email, is: > > 1. I have not been asking you to do better with "inappropriate content > and content classification", I have been asking that you make it > easier to report spam. Spam is a content-free concept: the content of > a message is almost irrelevant as to whether it is spam or not. > > 2. "this is spam" should be the only option. Any other categorization > is too open to abuse and is likely to cause you a lot of extra work, > as well as cause unrecoverable damages to innocent parties. At least > that's what's happened in other environments. > -- ------------------------ Jeska Dzwigalski Community and Product Development, Linden Lab jeska@lindenlab.com http://www.secondlife.com Visit my Office in Second Life: http://tinyurl.com/nmhsa ------------------------- From bos at lindenlab.com Mon May 5 16:35:33 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon May 5 16:35:35 2008 Subject: [sldev] CMake update Message-ID: <481F99C5.7000803@lindenlab.com> We're on the verge of merging the cmake work into our release (trunk) branch. This will probably happen at the end of this week, or maybe the beginning of next. During the final stages of development, we added build support for Visual Studio 2008. As far as I know, it should work on both XP and Vista. I also fixed and closed out all of the reported JIRA bugs against the cmake branch. The one thing we haven't had cycles for is testing release candidates of CMake 2.6.0. If some kind soul wants to give it a whirl, please let us know how it goes. I don't expect there to be any significant changes in the coming week. References: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> <000301c8aedf$744aac50$5ce004f0$@com> <79e704e0805051147h407be769m99f0e86b051b4afb@mail.gmail.com> <481F9571.30107@cox.net> Message-ID: <79e704e0805051700l40a8fe7k155aaa5994f735c1@mail.gmail.com> > > > And the slow network would bother me. Do you really want an EDGE device > for SL? I'd be more tempted to do something on EV-DO with Windows Mobile. > > > > > > However, on a similar note, is there any progress on the SL thin client? > I remember reading in January that LL was expecting there to be a public > beta available in February. I'm looking at my calendar and it appears to be > May, with no thin client alpha or beta in sight. > > > > > > Chris J. Breisch > > > > > > > > > > >From what they replied with it appears they want to develop an > > interface to interact with SL. To capture the OpenGL output and > > stream it to the device then use the motion/touch to interact with the > > client. So then you could assume that you would be over an 802.11b or > > g network. > > > > I would love a thin client, most people would probably migrate over in > > a few moments of hearing about it if it was even halfway more stable > > then the official one now. > > > > > > > How thin is "thin?" Logging onto SL and keeping Ruth there indefinitely > takes less than 350 lines of Python. > http://wiki.secondlife.com/wiki/Presence_Code_Python. Group IM won't take > that much more, assuming I ever figure out the details (my Python > group-IM-bot has about 700 lines total, but is not quite working). > > If you're not interested in 3D display and don't care about being Ruth, > implementing most features in SL would be relatively thin. libsl's biggest > bloat is an optimization to create about 100K lines of inline C# code to > handle packet processing for all packets as fast as possible. > > > Once the new login procedure using Agent Domains is implemented, even Ruth > goes away since you will be able to handle group IM and inventory management > without having a presence in a simulator and you'll need to implement > packet-handling only for those specific packets associated with IM and > Inventory. If you want lightweight clients that can navigate in-world, > you'll still need to worry about Ruthiness (baking textures) and handling 3D > info, unless you can convince LL to provide a separate CAP to the mini-map > info. I made a humorous remark about a 2D side-scroller SL at the > OpenSource office hours a while back, but for smart phones, being able to at > least see your avatar on the mini-map in relation to other avatars may be > all that you need for at least SOME level of social interaction. > > > Lawson So basically you could do some scripting or building without actually needing to be "there" with agent domains? If you are really lazy you can grab the simulator textures via SLURL.com by calculating the URL based on the global position of the region corner. From josh at lindenlab.com Mon May 5 17:32:00 2008 From: josh at lindenlab.com (Joshua Bell) Date: Mon May 5 17:30:02 2008 Subject: [sldev] Re: [VWR] fmod.dll not found In-Reply-To: References: Message-ID: <481FA700.7080000@lindenlab.com> FYI: http://msdn.microsoft.com/en-us/library/7d83bc18(VS.80).aspx (1) Same dir as executable, (2) current dir, (3) Windows system dir, (4) Windows dir, (5) PATH When we package a viewer, the EXE and DLLs end up in the same dir, so (1) applies. When you build a viewer, the executable ends up a few directories down so you need to make sure that (2) applies - which is what the steps below take care of. Anna Gulaev wrote: > Thanks, Soft. That's what I did. I made a shortcut with the newview > directory as the start directory. Works dandily :) > > Anna > > On Sun, May 4, 2008 at 2:44 PM, Soft > wrote: > > On Sun, May 4, 2008 at 1:37 PM, Anna Gulaev > wrote: > > How does a windows program built with visual studio know where > to look for > > DLLs? > > > > Every suggestion I can find says to put the path in the PATH > environment > > variable. Clearly, this is not how the SL viewer knows to find > fmod.dll in > > the newview directory, because I don't have newview in my path, > and version > > 1.18.4.3 worked fine. 1.20.rc5 does not find > it. 1.18.4.3 does. > > > > the fmod DLL is here: /cygdrive/c/sl/1.20.rc5/linden/indra/newview > > the executable is here: > /cygdrive/c/sl/1.20.rc5/linden/indra/newview/Release > > > > How is the SL viewer finding (or not!) the fmod DLL? > > Hello, Anna. I believe that Windows treats the current directory as > though it were part of the path. So what you probably want to do if > you wish to run the viewer in this fashion is to make a shortcut or a > batch file that sets the newview directory as the current directory, > and then run the release executable without actually switching to that > directory. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From alissa_sabre at yahoo.co.jp Mon May 5 17:43:43 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon May 5 17:43:48 2008 Subject: [sldev] 1.20.5 os/x build In-Reply-To: <7b61e3970805051149k275c0ce2m7d7df08c9307d496@mail.gmail.com> References: <7b61e3970805051149k275c0ce2m7d7df08c9307d496@mail.gmail.com> Message-ID: <83n1Ls9rds9ea5er4s9Leu4Y.alissa_sabre@yahoo.co.jp> > I searched the list but couldn't find reference to this issue and it seems > like it does not a warrant a JIRA > llrender/llimagegl.cpp Line 631: //llassert(prev_mip_size == bytes); VWR-7044 -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From dmahalko at gmail.com Mon May 5 17:51:14 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon May 5 17:51:17 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <481F7279.809@watson.ibm.com> References: <481F7279.809@watson.ibm.com> Message-ID: An interesting approach, doing all rendering on a remote server and just streaming 2D video to the client. Alas it requires logging in via proxy, and the remote server must be trusted with knowing your login and password, doing actions for you via the phone interface. - Scalar Tardis / Dale Mahalko On Mon, May 5, 2008 at 3:47 PM, Mike Monkowski wrote: > You mean something like > http://www.youtube.com/watch?v=bJF3LBREabk > or > http://www.youtube.com/watch?v=XwRnjbkljnc > > Mike > > > > > Kitten Lulu wrote: > > Hello, > > > > Thanks to Apple, I can now write apps for iPhone and iPod Touch devices. > They have accelerometers, an app can read the orientation in 3D space of the > device. > > > > I got an idea for an app that I'd love to develop. > > > > Imagine a modified/future Second Life client that (in addition to the > usual on-screen rendering) streams a first-person 3D view to the > iPhone/iPodTouch. > > > > Imagine being able to tilt and move the device to look around, use > multi-touch fingers to zoom-in and out, use taps to move around. (*) > > > > Imagine being able to do all that without requiring custom hardware or > headtracking. > > > > Imagine distributing it for free thru Apple's iTunes and AppStore to all > iPhone and iPod Touch users worldwide. > > > > Anyone wants to help? > > > > I can do the iPhone/iPod touch part, but I don't know where to start with > the Second Life client parts. > > > > -- > > Kitten Lulu > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kamilion at gmail.com Mon May 5 17:58:14 2008 From: kamilion at gmail.com (Kamilion) Date: Mon May 5 17:58:18 2008 Subject: [sldev] Re: Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: References: Message-ID: On Sat, May 3, 2008 at 8:50 PM, Kamilion wrote: > Could someone kindly give me the download links to the official Linux > 1.20RC builds for RC2, RC3, and RC4? > I'll try to track down where in the chain this went sour. Okay, so I figured out how to do this myself. Grabbed the revision numbers from the wiki, and what do you know? http://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.20.4 The download links still seem to work... http://release-candidate-secondlife-com.s3.amazonaws.com/SecondLife_i686_1_20_4_85828_RELEASECANDIDATE.tar.bz2 http://release-candidate-secondlife-com.s3.amazonaws.com/SecondLife_i686_1_20_3_85643_RELEASECANDIDATE.tar.bz2 http://release-candidate-secondlife-com.s3.amazonaws.com/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE.tar.bz2 >From my testing, it appears RC2 was the last version that didn't have this issue. RC3, RC4, and RC5 all have this display issue. I don't have a build environment set up on this laptop, so it's hard for me to track it down any further than this. I'll try to set one up when I can. If anyone has a good link for me to get a dev environment on hardy, I'd like to follow it. Good luck to the rest of you. -- Kamilion "Never feel stupid for asking questions, feel stupid for ignoring answers." From alissa_sabre at yahoo.co.jp Mon May 5 19:26:45 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon May 5 19:26:51 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" Message-ID: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp> Hi, all, I read the following Linden blog entry: Working on the Right Things (Considering OS X "Panther" Support) http://blog.secondlife.com/2008/05/05/working-on-the-right-things-considering-os-x-panther-support/ Then two thoughts came in my mind. First one is on the Windows 2000 support. Isn't it possible to stop supporting pre-SP4 Windows 2000? As some comments to the blog entry wrote, Windows 2000 is older than MacOS X Panther. I don't know how many residents log in with Windows 2000, but I guess the number is not very large. Moreover, I believe most of the existing Windows 2000 users have updated their OS to SP4 already. Some of you may know that I'm working primarily on internationalization and related area. Windows 2000, especially its US version, is terribly bad on internationalization and it always has been a headache for internationalization programmers. Windows 2000 itself provides a fair set of internationalization features, but most of the internationalization components are designed as *optional* parts. And in US version of the first release of Windows 2000, most of the internatinalization components are not installed as default, and worse, some components are not included in Windows 2000 install CD at all... One example is IMM32.DLL, that provides interaction with input methods. It is included in all language versions of Windows 2000 but not installed as default in US version. So, under a typical install of US users' Windows 2000, this DLL is missing from hard disks. That is the reason, when I wrote patch for VWR-250, I had to write unnecessarily complicated dynamic loading of functions in IMM32, making the resulting code harder to read. (You can see essentially the same code in linden/indra/llwindow/llwindowwin32.cpp of the recent viewer source.) THis is the background why I'm asking to stop supporting pre-SP4 Windows 2000. As far as I know, Windows 2000 SP4 has no _problems_ regarding internationalization support. For example, IMM32.DLL discussed above is always installed on all language versions in SP4. (I guess it was SP2 when the situation changed, but I'm not sure.) Limitting support for Windows 2000 to SP4 only makes internationalization programmers' life easier. # I myself don't object if Lindens decide to stop supporting *ALL* Windows 2000, but that's not what I'm asking here. Another one is on the relationship between Lindens' support policy and the source code itself, or open source community's policy. Will we accept changes that facilitates MacOS X 10.3.9 only, after the support for this version is discontinued? My opinion is, we should do so, as long as the change doesn't harm supported platforms. "Support" is a sort of a commitment, especially for a commercial company like LL. Also, open source developers well know that LL is always short-handed on development... They can't integrate a trivial one-line patch submitted on JIRA in timely manner... So, I understand and support the concern expressed in the blog entry. However, open source developers' activity is a different issue. As long as someone in the community finds a value to work on, I believe we have no reason to stop him/her. It is like adding Solaris specific changes into the source tree. LL dosn't officially support Solaris port, but the source changes needed for Solaris are included in the repository. That's fine as long as it doesn't harm supported platform. I think the same policy applies on MacOS 10.3.9. SL viewer may or may not run on MacOS 10.3.9. LL doesn't provide any support for 10.3.9 users. Period. This will be the LL's official statement, even if the community keeps maintaining 10.3.9 compatibility behind the scenes. Of course, this discussion assumes someone in the sldev will work on MacOS 10.3.9... If nobody in the community have enthusiasm on it, termination by LL means a true end of life on the version. Are there anybody who takes care of 10.3.9? -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From alissa_sabre at yahoo.co.jp Mon May 5 19:42:02 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon May 5 19:42:07 2008 Subject: [sldev] CMake update In-Reply-To: <481F99C5.7000803@lindenlab.com> References: <481F99C5.7000803@lindenlab.com> Message-ID: BoS, > We're on the verge of merging the cmake work into our release (trunk) > branch. This will probably happen at the end of this week, or maybe the > beginning of next. Great! Thank you for the effort. One more thank you for telling it before it actually happens. > During the final stages of development, we added build support for > Visual Studio 2008. Hmm... This may be another issue, but does the _completion_ of cmake project affect LL's plan on the choice of Visual Studio versions that LL uses for LL's own binary releases? -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From secret.argent at gmail.com Mon May 5 20:04:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon May 5 20:04:16 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp> References: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp> Message-ID: <2B198A1D-BD6C-405A-8C76-F60602FAE35A@gmail.com> On 2008-05-05, at 21:26, Alissa Sabre wrote: > Isn't it possible to stop supporting pre-SP4 Windows 2000? Microsoft is making it increasingly difficult to download updates for Windows 2000, including SP4. > As some comments to the blog entry wrote, Windows 2000 is older than > MacOS X Panther. I don't know how many residents log in with Windows > 2000, but I guess the number is not very large. You might be surprised. I use Windows 2000. I will continue to use Windows 2000 until Microsoft removes the suicide pill from later versions of Windows. There are very few core differences between 2000 and XP. XP was basically a cosmetic change accompanied by extra bundled software. > Will we accept changes that facilitates MacOS X 10.3.9 only, after > the support for this version is discontinued? I don't see why not, if they are portable and don't cause problems for later versions. > Of course, this discussion assumes someone in the sldev will work on > MacOS 10.3.9... If nobody in the community have enthusiasm on it, > termination by LL means a true end of life on the version. Are there > anybody who takes care of 10.3.9? Well, I still run SL on my Mac mini, now and then, and that's still running Panther. From gwardell at gwsystemsdns.net Mon May 5 21:26:08 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Mon May 5 21:26:15 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp> Message-ID: <001a01c8af31$4f62c330$a400000a@gwsystems2.com> > Isn't it possible to stop supporting pre-SP4 Windows 2000? I use Win2K, it's very solid and a smaller footprint that later Windows. Also I object to the activation requirement/limitations of later windows. Yes, it's SP4, I've seen many software packages that require SP4 so I don't think that's an unreasonable requirement. Gary From tom at streamsense.net Tue May 6 03:18:22 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue May 6 03:18:50 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <2B198A1D-BD6C-405A-8C76-F60602FAE35A@gmail.com> References: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp> <2B198A1D-BD6C-405A-8C76-F60602FAE35A@gmail.com> Message-ID: <4820306E.70800@streamsense.net> Argent Stonecutter wrote: > On 2008-05-05, at 21:26, Alissa Sabre wrote: >> Isn't it possible to stop supporting pre-SP4 Windows 2000? > > Microsoft is making it increasingly difficult to download updates for > Windows 2000, including SP4. That's more a case of Microsoft dropping support for w2k which of course we can do nothing about, however I can't find anything which suggests it's not easy to download SP4. http://www.microsoft.com/downloads/details.aspx?familyid=1001AAF1-749F-49F4-8010-297BD6CA33A0&displaylang=en It doesn't even try to check if you have a genuine copy of windows, which most microsoft downloads do. But, in any case, even if they do remove the download.. http://www.google.co.uk/search?hl=en&q=%22Index+of%22+%09W2KSP4_EN.EXE&btnG=Google+Search&meta= Can we get some demographics from LL outlining a) the number of w2k users, and b) the number of w2k SP4 users? Also, SP4 had some major security fixes, anybody who is not using SP4 on an internet-connected machine is a little insane.. Cheers Tom From gwardell at gwsystemsdns.net Tue May 6 10:22:01 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Tue May 6 10:22:08 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <4820306E.70800@streamsense.net> Message-ID: <002701c8af9d$b2d970a0$a400000a@gwsystems2.com> > > > Argent Stonecutter wrote: > > On 2008-05-05, at 21:26, Alissa Sabre wrote: > >> Isn't it possible to stop supporting pre-SP4 Windows 2000? > > > > Microsoft is making it increasingly difficult to download > updates for > > Windows 2000, including SP4. > That's more a case of Microsoft dropping support for w2k > which of course > we can do nothing about, however I can't find anything which suggests > it's not easy to download SP4. > > http://www.microsoft.com/downloads/details.aspx?familyid=1001A > AF1-749F-49F4-8010-297BD6CA33A0&displaylang=en > > It doesn't even try to check if you have a genuine copy of windows, > which most microsoft downloads do. But, in any case, even if they do > remove the download.. > > http://www.google.co.uk/search?hl=en&q=%22Index+of%22+%09W2KSP > 4_EN.EXE&btnG=Google+Search&meta= > > Can we get some demographics from LL outlining a) the number of w2k > users, and b) the number of w2k SP4 users? > > Also, SP4 had some major security fixes, anybody who is not > using SP4 on > an internet-connected machine is a little insane.. > > Cheers > > Tom > _______________________________________________ Hi, Yes, I don't buy that either. You can still find downloads for NT 4.0 SP 6.0a and that is log past end of life. http://www.microsoft.com/downloads/details.aspx?FamilyID=e396d059-e402-46ef-b095-a74399e25737&DisplayLang=en I could be wrong but I think Win2K is still under some limited support and critical hot fixes. Gary From lenglish5 at cox.net Tue May 6 11:15:50 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue May 6 11:15:53 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <79e704e0805051700l40a8fe7k155aaa5994f735c1@mail.gmail.com> References: <79e704e0805051004i2d537acn3b04269549fb1fb9@mail.gmail.com> <000301c8aedf$744aac50$5ce004f0$@com> <79e704e0805051147h407be769m99f0e86b051b4afb@mail.gmail.com> <481F9571.30107@cox.net> <79e704e0805051700l40a8fe7k155aaa5994f735c1@mail.gmail.com> Message-ID: <4820A056.1060901@cox.net> Matthew Underwood wrote: > > So basically you could do some scripting or building without actually > needing to be "there" with agent domains? > > If you are really lazy you can grab the simulator textures via > SLURL.com by calculating the URL based on the global position of the > region corner. > > I don't know about building. Scripting MIGHT be an option, but there would have to be some way for the viewer and Agent Domain to to talk to an asset server about compiling/manipulating the script from inventory. If LL ever allows non-inventory items to be stored clientside and referenced in viewer windows, you could do whatever you wanted and defer building/scripting until you finished rez-avatar, but you could do that now anyway with an external app or with a suitable edition to the current viewer if you wanted to get REALLY fance with low-level GUI programming. Lawson From kfa at gmx.net Tue May 6 11:17:26 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue May 6 11:17:58 2008 Subject: [sldev] Patch format question Message-ID: <4820A0B6.60405@gmx.net> Hi @ (esp. Linden Devs), This may be a very little thing but I'm wondering if it would cause any trouble to loosen up the guidelines for the format of submitted patches. Not sure how many others use a similar setup to work with. I keep a local svn repository where I check in a newly downloaded source version, then I just fix the project files and commit them. For me it would be so much more convenient if I could just use my TortoiseSVN to create patches from there instead of having to do a command line diff. To make a diff patch, I have to export first and then still watch what goes into it and what not and this is error-prone late at night, or early before the second cup of coffee ;). If instead of this: diff -ruN -x .svn -x '*.vcproj' -x '*.sln' linden-orig/indra/newview/app_settings/settings.xml linden/indra/newview/app_settings/settings.xml --- linden-orig/indra/newview/app_settings/settings.xml 2008-04-27 07:05:17.687500000 -0400 +++ linden/indra/newview/app_settings/settings.xml 2008-04-27 07:09:50.156250000 -0400 ... you get this: Index: indra/newview/app_settings/settings.xml =================================================================== --- indra/newview/app_settings/settings.xml (revision 4) +++ indra/newview/app_settings/settings.xml (working copy) ... would it really disrupt anyone's patterns? I believe you'd have to do some search-and-replace anyway most of the time before a patch can be applied. In the former case the directories may not match, in the latter the revision numbers. Cheers, Felix From soft at lindenlab.com Tue May 6 12:27:32 2008 From: soft at lindenlab.com (Soft) Date: Tue May 6 12:27:37 2008 Subject: [sldev] Patch format question In-Reply-To: <4820A0B6.60405@gmx.net> References: <4820A0B6.60405@gmx.net> Message-ID: On Tue, May 6, 2008 at 1:17 PM, Felix Duesenburg wrote: > Hi @ (esp. Linden Devs), > > This may be a very little thing but I'm wondering if it would cause any trouble to loosen up the guidelines for the format of submitted patches. > > Not sure how many others use a similar setup to work with. I keep a local svn repository where I check in a newly downloaded source version, then I just fix the project files and commit them. For me it would be so much more convenient if I could just use my TortoiseSVN to create patches from there instead of having to do a command line diff. To make a diff patch, I have to export first and then still watch what goes into it and what not and this is error-prone late at night, or early before the second cup of coffee ;). > > If instead of this: > > diff -ruN -x .svn -x '*.vcproj' -x '*.sln' linden-orig/indra/newview/app_settings/settings.xml linden/indra/newview/app_settings/settings.xml > --- linden-orig/indra/newview/app_settings/settings.xml 2008-04-27 07:05:17.687500000 -0400 > +++ linden/indra/newview/app_settings/settings.xml 2008-04-27 07:09:50.156250000 -0400 > > ... you get this: > > Index: indra/newview/app_settings/settings.xml > =================================================================== > --- indra/newview/app_settings/settings.xml (revision 4) > +++ indra/newview/app_settings/settings.xml (working copy) > > ... would it really disrupt anyone's patterns? I believe you'd have to do some search-and-replace anyway most of the time before a patch can be applied. In the former case the directories may not match, in the latter the revision numbers. A svn diff is fine. patch accepts that as input without any problems. ToirtoiseSVN's diff output is fine as well. It needs a little cleanup because it mixes line ending styles between the header and the body, but that's trivial for the importer to fix. From kamilion at gmail.com Tue May 6 13:50:28 2008 From: kamilion at gmail.com (Kamilion) Date: Tue May 6 13:50:33 2008 Subject: [sldev] Re: Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: References: Message-ID: Okay, this is really getting annoying. I'm trying to log in with RC2, but no matter what I do, I keep getting the Download/Quit msgbox. I've tried: ./secondlife --channel rc5isbroken ./secondlife --channel "rc5isbroken" ./secondlife --channel=rc5isbroken ./secondlife --channel="rc5isbroken" What am I missing here? Does --channel simply not work on linux? RC2's easily been the most stable version so far on this box, and due to the font corruption issue, RC3, RC4, and RC5 are unusable, as it's corrupting the heck out of the script window as well as just about everything else. My hardware: Stock Fujitsu Lifebook S2020, with ATI Radeon IGP 320M / Radeon Mobility U1, Athlon XP-M 2200+ (1.66Ghz), 512MB of memory. MesaGL Second Life 1.20.2 (85278) Apr 18 2008 15:48:33 (Second Life Release Candidate) CPU: AMD Athlon(tm) XP-M (LV) 2200+ Memory: 439 MB OS Version: Linux 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 Graphics Card Vendor: Tungsten Graphics, Inc. Graphics Card: Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL OpenGL Version: 1.3 Mesa 7.0.3-rc2 LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.14950 (Mozilla GRE version 1.8.1.13_0000000000) I've included as many log files as I can think of. -- Kamilion "Never feel stupid for asking questions, feel stupid for ignoring answers." -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.conf Type: application/octet-stream Size: 1476 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080506/d5990bb9/xorg-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: Xorg.0.log Type: application/octet-stream Size: 44555 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080506/d5990bb9/Xorg.0-0001.obj -------------- next part -------------- name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL OpenGL version string: 1.3 Mesa 7.0.3-rc2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_OES_read_format, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x27 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x29 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x2c 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x2d 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x2e 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x2f 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x30 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x31 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 Slow 0x32 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x55 32 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 Ncon -------------- next part -------------- kamilion@lifebook:~/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE$ ./secondlife --channel "comeonworkdangyou" Running from /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE ./secondlife: line 69: ./register_secondlifeprotocol.sh: Permission denied 2008-05-06T20:46:23Z INFO: initConfiguration: Loading settings file list/home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/settings_files.xml 2008-05-06T20:46:23Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/settings_crash_behavior.xml 2008-05-06T20:46:23Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/settings.xml 2008-05-06T20:46:23Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/settings_per_account.xml 2008-05-06T20:46:23Z WARNING: parseAndStoreResults: Caught Error:Non composing value with multiple occurences. 2008-05-06T20:46:23Z INFO: initConfiguration: Using command line specified settings filename: /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named CrashSubmitBehavior already exists. 2008-05-06T20:46:23Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/.secondlife/user_settings/settings_crash_behavior.xml 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named AlertedUnsupportedHardware already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named AudioStreamingMusic already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named AudioStreamingVideo already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named CacheValidateCounter already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named CameraPosOnLogout already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ChatterboxRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ContactsTornOff already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named DebugPermissions already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named EnableVoiceChat already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FirstLoginThisInstall already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FirstName already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FirstRunThisInstall already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterAboutRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterBuildOptionsRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterCameraRect3 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterChatRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterContactsRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterCustomizeAppearanceRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterFindRect2 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterGestureRect2 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterHUDRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterInventoryRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterLagMeter already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterLandRect5 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterMediaRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterMiniMapRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterMoveRect2 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterMuteRect3 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterOpenObjectRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterViewBottom already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FloaterWorldMapRect2 already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FocusPosOnLogout already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named FontSansSerifFallback already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named GridChoice already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named InventorySortOrder already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LastFeatureVersion already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LastFindPanel already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LastName already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LastPrefTab already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LastRunVersion already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named LocalCacheVersion already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named MapScale already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named NotecardEditorRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named NumSessions already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named PreviewScriptRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ProbeHardwareOnStartup already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarCloth already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarLODFactor already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarVP already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderCustomSettings already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderFarClip already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderFlexTimeFactor already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderFogRatio already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderGlowResolutionPow already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderLightingDetail already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderMaxPartCount already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderObjectBump already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderQualityPerformance already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderReflectionDetail already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderTerrainDetail already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderVBOEnable already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named RenderVolumeLODFactor already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ServerChoice already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named TextureMemory already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ThrottleBandwidthKBPS already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named ToolboxRect already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named UseDebugMenus already exists. 2008-05-06T20:46:23Z WARNING: LLControlGroup::declareControl: Control named VFSOldSize already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named VFSSalt already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named VectorizePerfTest already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named VectorizeSkin already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WLSkyDetail already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstBuild already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstDebugMenus already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstInventory already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstLeftClickNoHit already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstMap already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstMedia already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstOverrideKeys already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstStreamingMusic already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstStreamingVideo already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstTeleport already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WarnFirstVoice already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindLightUseAtmosShaders already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindowHeight already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindowMaximized already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindowWidth already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindowX already exists. 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named WindowY already exists. 2008-05-06T20:46:24Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:46:24Z WARNING: loadFromFile: Cannot find file /home/kamilion/.secondlife/user_settings/settings_per_account.xml to load. 2008-05-06T20:46:24Z WARNING: loadSettingsFromDirectory: Cannot load /home/kamilion/.secondlife/user_settings/settings_per_account.xml - No settings found. 2008-05-06T20:46:24Z INFO: anotherInstanceRunning: Checking marker file for lock... 2008-05-06T20:46:24Z INFO: anotherInstanceRunning: Marker file isn't locked. 2008-05-06T20:46:24Z INFO: initMarkerFile: Checking marker file for lock... 2008-05-06T20:46:24Z WARNING: ll_apr_warn_status: APR: No such file or directory 2008-05-06T20:46:24Z WARNING: ll_apr_warn_status: APR: No such file or directory 2008-05-06T20:46:24Z WARNING: ll_apr_warn_status: APR: No such file or directory 2008-05-06T20:46:24Z INFO: anotherInstanceRunning: Checking marker file for lock... 2008-05-06T20:46:24Z INFO: anotherInstanceRunning: Marker file isn't locked. 2008-05-06T20:46:24Z INFO: initMarkerFile: Marker file created. 2008-05-06T20:46:24Z INFO: initMarkerFile: Marker file locked. 2008-05-06T20:46:24Z INFO: Exiting initMarkerFile(). 2008-05-06T20:46:24Z INFO: writeSystemInfo: Second Life version 1.20.2 2008-05-06T20:46:24Z INFO: writeSystemInfo: Local time: 2008-05-06T13:46:24 PDT 2008-05-06T20:46:24Z INFO: writeSystemInfo: CPU info: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) XP-M (LV) 2200+ stepping : 0 cpu MHz : 1661.362 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up ts fid vid bogomips : 3324.85 clflush size : 32 ->mHasSSE: 1 ->mHasSSE2: 0 ->mHasAltivec: 0 ->mCPUMhz: 1661 ->mCPUString: AMD Athlon(tm) XP-M (LV) 2200+ 2008-05-06T20:46:24Z INFO: writeSystemInfo: Memory info: MemTotal: 450548 kB MemFree: 82844 kB Buffers: 3424 kB Cached: 147124 kB SwapCached: 22244 kB Active: 285308 kB Inactive: 52804 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 450548 kB LowFree: 82844 kB SwapTotal: 803240 kB SwapFree: 651772 kB Dirty: 96 kB Writeback: 0 kB AnonPages: 182736 kB Mapped: 73052 kB Slab: 10432 kB SReclaimable: 3760 kB SUnreclaim: 6672 kB PageTables: 2092 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 1028512 kB Committed_AS: 717572 kB VmallocTotal: 573432 kB VmallocUsed: 8140 kB VmallocChunk: 564212 kB 2008-05-06T20:46:24Z INFO: writeSystemInfo: OS: Linux 2.6 2008-05-06T20:46:24Z INFO: writeSystemInfo: OS info: Linux 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 2008-05-06T20:46:24Z INFO: init: J2C Engine is: KDU 2008-05-06T20:46:24Z WARNING: LLControlGroup::declareControl: Control named CrashSubmitBehavior already exists. 2008-05-06T20:46:24Z INFO: init: Loading base colors from /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/colors_base.xml 2008-05-06T20:46:24Z INFO: init: Loading user colors from /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/colors.xml 2008-05-06T20:46:24Z INFO: init: Cannot load user colors from /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/colors.xml 2008-05-06T20:46:24Z INFO: updateVectorize: Vectorization : DISABLED 2008-05-06T20:46:24Z INFO: updateVectorize: Vector Processor : COMPILER DEFAULT 2008-05-06T20:46:24Z INFO: updateVectorize: Vectorized Skinning : DISABLED 2008-05-06T20:46:24Z INFO: initCache: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB 2008-05-06T20:46:24Z INFO: purgeTextures: TEXTURE CACHE: Reading Entries... 2008-05-06T20:46:24Z INFO: purgeTextures: TEXTURE CACHE: Validating: 15 2008-05-06T20:46:24Z INFO: purgeTextures: TEXTURE CACHE: Writing Entries: 1135 2008-05-06T20:46:24Z INFO: purgeTextures: TEXTURE CACHE: PURGED: 0 ENTRIES: 1135 CACHE SIZE: 36045824 MB 2008-05-06T20:46:24Z INFO: initCache: VFS CACHE SIZE: 100 MB 2008-05-06T20:46:24Z INFO: initCache: Renaming /home/kamilion/.secondlife/cache/data.db2.x.1739376443 to /home/kamilion/.secondlife/cache/data.db2.x.411146653 2008-05-06T20:46:24Z INFO: initCache: Renaming /home/kamilion/.secondlife/cache/index.db2.x.1739376443 to /home/kamilion/.secondlife/cache/index.db2.x.411146653 2008-05-06T20:46:24Z INFO: LLVFS: VFS: Using index file /home/kamilion/.secondlife/cache/index.db2.x.411146653 and data file /home/kamilion/.secondlife/cache/data.db2.x.411146653 2008-05-06T20:46:24Z INFO: LLVFS: VFS: Using index file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/static_index.db2 and data file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/static_data.db2 2008-05-06T20:46:24Z INFO: initWindow: Initializing window... 2008-05-06T20:46:24Z INFO: ll_try_gtk_init: Starting GTK Initialization. 2008-05-06T20:46:24Z INFO: ll_try_gtk_init: GTK Initialized. 2008-05-06T20:46:24Z INFO: ll_try_gtk_init: - Compiled against GTK version 2.4.14 2008-05-06T20:46:24Z INFO: ll_try_gtk_init: - Running against GTK version 2.12.9 2008-05-06T20:46:24Z INFO: createContext, fullscreen=0 size=1024x710 2008-05-06T20:46:24Z INFO: createContext: Compiled against SDL 1.2.5 2008-05-06T20:46:24Z INFO: createContext: Running against SDL 1.2.12 2008-05-06T20:46:24Z INFO: createContext: creating window 1024x710x32 2008-05-06T20:46:24Z INFO: x11_detect_VRAM_kb: Looking in /var/log/Xorg.0.log for VRAM info... 2008-05-06T20:46:24Z INFO: createContext: GL buffer: 2008-05-06T20:46:24Z INFO: createContext: Red Bits 8 2008-05-06T20:46:24Z INFO: createContext: Green Bits 8 2008-05-06T20:46:24Z INFO: createContext: Blue Bits 8 2008-05-06T20:46:24Z INFO: createContext: Alpha Bits 8 2008-05-06T20:46:24Z INFO: createContext: Depth Bits 24 2008-05-06T20:46:24Z INFO: createContext: Stencil Bits 8 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_EXT_paletted_texture 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_ARB_occlusion_query 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_ARB_point_parameters 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_ARB_shader_objects 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_ARB_vertex_shader 2008-05-06T20:46:24Z INFO: initExtensions: Couldn't initialize GL_ARB_fragment_shader 2008-05-06T20:46:24Z INFO: initExtensions: GL Probe: Getting symbols 2008-05-06T20:46:24Z INFO: initExtensions: GL Probe: Got symbols 2008-05-06T20:46:24Z INFO: LLViewerWindow: Loading feature tables. 2008-05-06T20:46:24Z INFO: loadGPUClass: GPU is Mesa 2008-05-06T20:46:24Z INFO: applyBaseMasks: Setting GPU Class to Class0 2008-05-06T20:46:24Z INFO: maskFeatures: Applying Feature Mask: Class0 2008-05-06T20:46:24Z INFO: maskFeatures: Applying Feature Mask: NoPixelShaders 2008-05-06T20:46:24Z INFO: maskFeatures: Applying Feature Mask: NoVertexShaders 2008-05-06T20:46:24Z INFO: maskFeatures: Applying Feature Mask: OpenGLPre15 2008-05-06T20:46:24Z WARNING: LLViewerImageList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 128 MB 2008-05-06T20:46:24Z WARNING: LLViewerImageList::getMaxVideoRamSetting: VRAM amount not detected, defaulting to 512 MB 2008-05-06T20:46:24Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 32 MB 2008-05-06T20:46:24Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 20 MB 2008-05-06T20:46:24Z INFO: LLViewerImageList::doPreloadImages: Preloading images... 2008-05-06T20:46:24Z INFO: decodeAllImages() took 0.299167 seconds. fetch_pending 0 create_time 0.026043 2008-05-06T20:46:25Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:46:25Z INFO: setShaders: ~~~~~~~~~~~~~~~~~~ Loading Shaders: ~~~~~~~~~~~~~~~~~~ 2008-05-06T20:46:25Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:46:25Z INFO: init: GL_VENDOR Tungsten Graphics, Inc. GL_RENDERER Mesa DRI Radeon 20061018 AGP 4x x86/MMX+/3DNow!+/SSE NO-TCL GL_VERSION 1.3 Mesa 7.0.3-rc2 GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_convolution GL_EXT_copy_texture GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_histogram GL_EXT_packed_pixels GL_EXT_polygon_offset GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_subtexture GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_rectangle GL_EXT_vertex_array GL_APPLE_packed_pixels GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_MESA_ycbcr_texture GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texture_rectangle GL_NV_texgen_reflection GL_OES_read_format GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod 2008-05-06T20:46:25Z INFO: LLVoiceClient::setState: entering state stateDisabled 2008-05-06T20:46:25Z INFO: LLVoiceClient::switchChannel: called in state stateDisabled with uri "" 2008-05-06T20:46:25Z INFO: dump: Resend: 150 2008-05-06T20:46:25Z INFO: dump: Land: 130 2008-05-06T20:46:25Z INFO: dump: Wind: 26 2008-05-06T20:46:25Z INFO: dump: Cloud: 26 2008-05-06T20:46:25Z INFO: dump: Task: 484 2008-05-06T20:46:25Z INFO: dump: Texture: 484 2008-05-06T20:46:25Z INFO: dump: Asset: 200 2008-05-06T20:46:25Z INFO: dump: Total: 1500 2008-05-06T20:46:25Z INFO: idle_startup: Initializing messaging system... 2008-05-06T20:46:25Z INFO: LLTemplateParser: ### Message template version 2 ### 2008-05-06T20:46:25Z INFO: start_net: startNet - receive buffer size : 221184 2008-05-06T20:46:25Z INFO: start_net: startNet - send buffer size : 221184 2008-05-06T20:46:25Z INFO: start_messaging_system: Message template version matches prehash version number 2008-05-06T20:46:25Z INFO: loadFile: Loading message.xml file at /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/message.xml 2008-05-06T20:46:25Z INFO: LLMessageConfigFile::loadCapBans: 27 ban tests 2008-05-06T20:46:25Z INFO: LLMessageSystem::setMessageBans: 2008-05-06T20:46:25Z INFO: setMessageBans: no messages banned 2008-05-06T20:46:25Z INFO: LLMessageConfig::initClass config file /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/message.xml 2008-05-06T20:46:25Z INFO: setAckThrottleBPS: LLXferManager ack throttle min rate: 2.66667e+06 2008-05-06T20:46:25Z INFO: setAckThrottleBPS: LLXferManager ack throttle actual rate: 2.93333e+06 2008-05-06T20:46:25Z INFO: setAckThrottleBPS: LLXferManager ack throttle min rate: 8000 2008-05-06T20:46:25Z INFO: setAckThrottleBPS: LLXferManager ack throttle actual rate: 150000 2008-05-06T20:46:25Z INFO: setUpstream: AssetStorage: Setting upstream provider to 0.0.0.0:0 2008-05-06T20:46:25Z INFO: LLAudioEngine_FMOD::init() initializing FMOD 2008-05-06T20:46:25Z INFO: init: Trying ESD audio output... 2008-05-06T20:46:25Z INFO: ESD audio output initialized OKAY 2008-05-06T20:46:25Z INFO: init: Audio output: ESD 2008-05-06T20:46:25Z INFO: LLAudioEngine_FMOD::init() FMOD initialized correctly 2008-05-06T20:46:25Z INFO: setStartupState: Startup state changing from 0 to 1 2008-05-06T20:46:25Z INFO: idle_startup: Initializing Multimedia.... grab_gst_syms:81: Found DSO: libgstreamer-0.10.so.0 grab_gst_syms:94: Found DSO: libgstaudio-0.10.so.0 grab_gst_syms:108: Found DSO: libgstvideo-0.10.so.0 2008-05-06T20:46:25Z INFO: setStartupState: Startup state changing from 1 to 2 2008-05-06T20:46:25Z INFO: idle_startup: Initializing Window 2008-05-06T20:46:25Z WARNING: Attempted getFields with no login view shown 2008-05-06T20:46:25Z INFO: login_show: Initializing Login Screen 2008-05-06T20:46:26Z INFO: login_show: Setting Servers 2008-05-06T20:46:26Z INFO: setStartupState: Startup state changing from 2 to 3 2008-05-06T20:46:26Z WARNING: getChild: Found child named Say but of wrong type 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named Say in chat_bar 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named end_call_btn in voice_remote 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy text named channel_label in voice_remote 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named voice_channel_bg in voice_remote 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named appearance_btn in toolbar 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named clothing_btn in toolbar 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named sit_btn in toolbar 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named History in chat_panel 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy combo_box named Gesture in chat_panel 2008-05-06T20:46:26Z WARNING: getChild: Found child named Say but of wrong type 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named Say in chat_panel 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy button named Chat in chat floater 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:26Z INFO: startNextTransfer: Getting asset data for: c80260ba-41fd-8a46-768a-6bf236360e3a 2008-05-06T20:46:26Z WARNING: _queueDataRequest: Attempt to move asset data request upstream w/o valid upstream provider 2008-05-06T20:46:26Z INFO: assetCallback: Boom, error in audio file transfer: Circuit gone (-23017) 2008-05-06T20:46:26Z WARNING: createDummyWidget: Making dummy view named Menu Object Take in Menu Holder 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:29Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:30Z WARNING: LLLocale: Failed to set locale en_US.utf8 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy view named bandwidth_tooltip in status 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy view named packet_loss_tooltip in status 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy view named friend_name_label in friends 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy view named friend_rights in friends 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy text named process_rights_label in friends 2008-05-06T20:46:31Z WARNING: createDummyWidget: Making dummy view named floater_my_friends in floater_chatterbox 2008-05-06T20:46:32Z WARNING: createDummyWidget: Making dummy view named Shout in chat_bar 2008-05-06T20:46:32Z INFO: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:HTTP/1.0 200 OK 2008-05-06T20:46:40Z INFO: startNextTransfer: Getting asset data for: 4c8c3c77-de8d-bde2-b9b8-32635e0fd4a6 2008-05-06T20:46:40Z WARNING: _queueDataRequest: Attempt to move asset data request upstream w/o valid upstream provider 2008-05-06T20:46:40Z INFO: assetCallback: Boom, error in audio file transfer: Circuit gone (-23017) 2008-05-06T20:46:46Z INFO: X11: ISO 8859-1 copyTextToClipboard 2008-05-06T20:46:46Z INFO: put_x11clipboard: X11: Populating cutbuffer. 2008-05-06T20:46:46Z INFO: clipboard_filter_callback: Clipboard: An app asked us what selections format we offer. 2008-05-06T20:46:46Z INFO: clipboard_filter_callback: Clipboard: An app asked us what selections format we offer. 2008-05-06T20:46:46Z INFO: clipboard_filter_callback: Clipboard: An app asked us what selections format we offer. 2008-05-06T20:46:52Z INFO: clipboard_filter_callback: Clipboard: An app requested an unsupported selection format 288, we have 31 2008-05-06T20:46:52Z INFO: clipboard_filter_callback: Clipboard: An app requested an unsupported selection format 467, we have 31 2008-05-06T20:46:56Z WARNING: LLViewerImage::setIsMissingAsset: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/skins/textures/icn_lable_music.tga 4e38ce82-5a47-1132-31eb-058b462d8a2e: Marking image as missing 2008-05-06T20:47:02Z INFO: setStartupState: Startup state changing from 3 to 4 2008-05-06T20:47:02Z INFO: idle_startup: Attempting login as: Kamilion Schnook 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: Current Directories: 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: CurPath: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: AppName: SecondLife 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: ExecutableFilename: do-not-directly-run-secondlife-bin 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: ExecutableDir: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/bin 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: ExecutablePathAndName: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/bin/do-not-directly-run-secondlife-bin 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: WorkingDir: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/bin 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: AppRODataDir: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: OSUserDir: /home/kamilion 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: OSUserAppDir: /home/kamilion/.secondlife 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: LindenUserDir: /home/kamilion/.secondlife/kamilion_schnook 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: TempDir: /tmp 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: CAFile: /home/kamilion/Desktop/SecondLife_i686_1_20_2_85278_RELEASECANDIDATE/app_settings/CA.pem 2008-05-06T20:47:02Z INFO: dumpCurrentDirectories: SkinDir: 2008-05-06T20:47:02Z WARNING: loadFromFile: Cannot find file /home/kamilion/.secondlife/kamilion_schnook/settings_crash_behavior.xml to load. 2008-05-06T20:47:02Z WARNING: loadSettingsFromDirectory: Cannot load /home/kamilion/.secondlife/kamilion_schnook/settings_crash_behavior.xml - No settings found. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named AlertedUnsupportedHardware already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named AudioStreamingMusic already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named AudioStreamingVideo already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named CacheValidateCounter already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named CameraPosOnLogout already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ChatterboxRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ContactsTornOff already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named DebugPermissions already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named EnableVoiceChat already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FirstLoginThisInstall already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FirstName already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FirstRunThisInstall already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterAboutRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterBuildOptionsRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterCameraRect3 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterChatRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterContactsRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterCustomizeAppearanceRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterFindRect2 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterGestureRect2 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterHUDRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterInventoryRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterLagMeter already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterLandRect5 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterMediaRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterMiniMapRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterMoveRect2 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterMuteRect3 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterOpenObjectRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterViewBottom already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FloaterWorldMapRect2 already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FocusPosOnLogout already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named FontSansSerifFallback already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named GridChoice already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named InventorySortOrder already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastFeatureVersion already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastFindPanel already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastName already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastPrefTab already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastRunVersion already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LocalCacheVersion already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named MapScale already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named NotecardEditorRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named NumSessions already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named PreviewScriptRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ProbeHardwareOnStartup already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarCloth already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarLODFactor already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderAvatarVP already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderCustomSettings already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderFarClip already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderFlexTimeFactor already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderFogRatio already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderGlowResolutionPow already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderLightingDetail already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderMaxPartCount already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderObjectBump already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderQualityPerformance already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderReflectionDetail already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderTerrainDetail already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderVBOEnable already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named RenderVolumeLODFactor already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ServerChoice already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named TextureMemory already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ThrottleBandwidthKBPS already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named ToolboxRect already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named UseDebugMenus already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named VFSOldSize already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named VFSSalt already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named VectorizePerfTest already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named VectorizeSkin already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WLSkyDetail already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstBuild already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstDebugMenus already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstInventory already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstLeftClickNoHit already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstMap already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstMedia already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstOverrideKeys already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstStreamingMusic already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstStreamingVideo already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstTeleport already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WarnFirstVoice already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindLightUseAtmosShaders already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindowHeight already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindowMaximized already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindowWidth already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindowX already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named WindowY already exists. 2008-05-06T20:47:02Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named InstantMessageLogPath already exists. 2008-05-06T20:47:02Z WARNING: LLControlGroup::declareControl: Control named LastLogoff already exists. 2008-05-06T20:47:02Z INFO: loadSettingsFromDirectory: Loaded settings file /home/kamilion/.secondlife/kamilion_schnook/settings_per_account.xml 2008-05-06T20:47:02Z INFO: loadFile: Loading history.xml file at url_history.xml 2008-05-06T20:47:02Z INFO: init_start_screen: Loading startup bitmap... 2008-05-06T20:47:04Z INFO: setStartupState: Startup state changing from 4 to 6 2008-05-06T20:47:04Z INFO: rewriteURI: Rewriting https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-05-06T20:47:04Z INFO: rewriteResult: [0] https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-05-06T20:47:04Z INFO: setStartupState: Startup state changing from 6 to 7 2008-05-06T20:47:04Z INFO: authenticate: Authenticating: Kamilion Schnook, 2008-05-06T20:47:04Z INFO: authenticate: Options: inventory-root, inventory-skeleton, inventory-lib-root, inventory-lib-owner, inventory-skel-lib, initial-outfit, gestures, event_categories, event_notifications, classified_categories, buddy-list, ui-config, tutorial_setting, login-flags, global-textures, END 2008-05-06T20:47:04Z INFO: LLUserAuth::authenticate: uri=https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-05-06T20:47:04Z INFO: setStartupState: Startup state changing from 7 to 8 2008-05-06T20:47:06Z INFO: transferRate: Buffer size: 376 B 2008-05-06T20:47:06Z INFO: transferRate: Transfer size: 185 B 2008-05-06T20:47:06Z INFO: transferRate: Transfer time: 1.90649 s 2008-05-06T20:47:06Z INFO: transferRate: Transfer rate: 0.776 Kb/s 2008-05-06T20:47:06Z INFO: authResponse: Processed response: 0 2008-05-06T20:47:06Z INFO: setStartupState: Startup state changing from 8 to 9 2008-05-06T20:47:06Z INFO: setStartupState: Startup state changing from 9 to 10 2008-05-06T20:47:06Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:47:06Z WARNING: createXml: Alert: [DownloadMacMandatory] 2008-05-06T20:47:06Z WARNING: createDialog: Alert: A new version of Second Life is available. (Required version: 1.20.5.86279.) You must download this update to use Second Life. Download to your Applications folder? 2008-05-06T20:47:06Z INFO: setStartupState: Startup state changing from 10 to 5 2008-05-06T20:47:09Z INFO: setQuitting: Setting app state to QUITTING 2008-05-06T20:47:09Z INFO: mainLoop: Exiting main_loop 2008-05-06T20:47:09Z INFO: LLVoiceClient::sessionTerminateSendMessage: leaving session: 2008-05-06T20:47:09Z WARNING: LLVoiceClient::sessionTerminateSendMessage: called from unknown state 2008-05-06T20:47:09Z INFO: LLVoiceClient::setState: entering state stateLoggingOut 2008-05-06T20:47:09Z INFO: LLVoiceClient::setState: entering state stateConnectorStopping 2008-05-06T20:47:09Z INFO: disconnectViewer: Disconnecting viewer! 2008-05-06T20:47:09Z INFO: cleanup: Viewer disconnected 2008-05-06T20:47:09Z INFO: cleanup: Cleaning Up 2008-05-06T20:47:09Z INFO: cleanup: HUD Objects cleaned up 2008-05-06T20:47:09Z INFO: cleanup: Global stuff deleted 2008-05-06T20:47:09Z WARNING: Hack, skipping audio engine cleanup 2008-05-06T20:47:09Z INFO: cleanup: Settings patched up 2008-05-06T20:47:09Z INFO: cleanup: Cache files removed 2008-05-06T20:47:09Z INFO: cleanup: Shutting down. 2008-05-06T20:47:09Z INFO: ~LLViewerWindow: Cleaning up pipeline 2008-05-06T20:47:09Z INFO: ~LLViewerWindow: Cleaning up select manager 2008-05-06T20:47:09Z INFO: ~LLViewerWindow: Stopping GL during shutdown 2008-05-06T20:47:09Z INFO: stopGL: Shutting down GL... 2008-05-06T20:47:09Z INFO: stopGL: Remaining allocated texture memory: 0 bytes 2008-05-06T20:47:09Z INFO: ~LLViewerWindow: Destroying Window 2008-05-06T20:47:09Z INFO: destroyContext begins 2008-05-06T20:47:09Z INFO: destroyContext: shutdownGL begins 2008-05-06T20:47:09Z INFO: destroyContext: SDL_QuitSS/VID begins 2008-05-06T20:47:09Z INFO: Skipping quitCursors: mWindow already gone. 2008-05-06T20:47:09Z INFO: destroyContext begins 2008-05-06T20:47:09Z INFO: destroyContext: shutdownGL begins 2008-05-06T20:47:09Z INFO: destroyContext: SDL_QuitSS/VID begins 2008-05-06T20:47:09Z INFO: cleanup: ViewerWindow deleted 2008-05-06T20:47:09Z INFO: cleanup: VFS cleaned up 2008-05-06T20:47:09Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/user_settings/settings_releasecandidate.xml 2008-05-06T20:47:09Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/kamilion_schnook/settings_per_account.xml 2008-05-06T20:47:09Z INFO: cleanup: Saved settings 2008-05-06T20:47:09Z INFO: saveToFile: Saved to /home/kamilion/.secondlife/user_settings/settings_crash_behavior.xml 2008-05-06T20:47:09Z INFO: removeMarkerFile() 2008-05-06T20:47:09Z INFO: closeDebug: Opening debug file /home/kamilion/.secondlife/logs/debug_info.log 2008-05-06T20:47:09Z WARNING: cleanup: Quitting with pending background tasks. 2008-05-06T20:47:09Z INFO: run: QUEUED THREAD TextureCache EXITING. 2008-05-06T20:47:09Z INFO: LLThread::staticRun() Exiting: TextureCache 2008-05-06T20:47:09Z INFO: run: QUEUED THREAD ImageDecode EXITING. 2008-05-06T20:47:09Z INFO: LLThread::staticRun() Exiting: ImageDecode 2008-05-06T20:47:09Z INFO: run: QUEUED THREAD VFS EXITING. 2008-05-06T20:47:09Z INFO: LLThread::staticRun() Exiting: VFS 2008-05-06T20:47:09Z INFO: run: QUEUED THREAD LFS EXITING. 2008-05-06T20:47:09Z INFO: LLThread::staticRun() Exiting: LFS 2008-05-06T20:47:09Z INFO: cleanup: VFS Thread finished 2008-05-06T20:47:09Z INFO: end_messaging_system: START MESSAGE LOG SUMMARY Run time: 44.419 seconds Incoming: Total bytes received: 0 ( 0.00 kbits per second) Total packets received: 0 ( 0.00 packets per second) Average packet size: nan bytes Total reliable packets: 0 ( 0.00%) Total compressed packets: 0 ( 0.00%) Total compression savings: 0 bytes Avg comp packet savings: 0 ( 0.00 : 1) Avg overall comp savings: 0 ( 0.00 : 1) Outgoing: Total bytes sent: 0 ( 0.00 kbits per second) Total packets sent: 0 ( 0.00 packets per second) Average packet size: nan bytes Total reliable packets: 0 ( 0.00%) Total compressed packets: 0 ( 0.00%) Total compression savings: 0 bytes Avg comp packet savings: 0 ( 0.00 : 1) Avg overall comp savings: 0 ( 0.00 : 1) SendPacket failures: 0 Dropped packets: 0 Resent packets: 0 Failed reliable resends: 0 Off-circuit rejected packets: 0 On-circuit invalid packets: 0 Decoding: Message Count Time Max Avg END MESSAGE LOG SUMMARY 2008-05-06T20:47:09Z INFO: cleanup: Goodbye 2008-05-06T20:47:09Z INFO: removeMarkerFile() 2008-05-06T20:47:09Z INFO: LLThread::staticRun() Exiting: Error 2008-05-06T20:47:09Z INFO: ll_cleanup_apr: Cleaning up APR ******************************************************* This is a BETA release of the Second Life linux client. Thank you for testing! Please see README-linux.txt before reporting problems. From rdw at lindenlab.com Tue May 6 14:02:17 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue May 6 14:02:18 2008 Subject: [sldev] Re: Font Corruption in 1.20RC5,Need download links for previous linux builds. In-Reply-To: References: Message-ID: <4820C759.8030406@lindenlab.com> Kamilion wrote: > Okay, this is really getting annoying. > I'm trying to log in with RC2, but no matter what I do, I keep getting > the Download/Quit msgbox. > > I've tried: > ./secondlife --channel rc5isbroken > ./secondlife --channel "rc5isbroken" > ./secondlife --channel=rc5isbroken > ./secondlife --channel="rc5isbroken" > > What am I missing here? Does --channel simply not work on linux? > > Hmmm... that would be bad. Alternatively you could try -channel (single dash was the oldschool nasty way). Or stick the argument in gridargs.txt. I believe it prints out the command-line arguments in the logs as it starts up, so that would be a good way to confirm that it's reading the right thing. -RYaN (cc-ing sldev, sorry for the dupe kamilion) From kamilion at gmail.com Tue May 6 14:15:21 2008 From: kamilion at gmail.com (Kamilion) Date: Tue May 6 14:15:25 2008 Subject: [sldev] Re: Font Corruption in 1.20RC5, Need download links for previous linux builds. In-Reply-To: <4820C759.8030406@lindenlab.com> References: <4820C759.8030406@lindenlab.com> Message-ID: Thanks, gridargs.dat seemed to work. I was able to log in without a problem on RC2. It appears that it was somehow overriding my command line options with the options in gridargs.dat, might want to take a closer look at that as well, with the new boost-provided command line parser. Any ideas on the font corruption? I'm happy to help track it down, and I'm in the south bay area if any linden would like to take a closer look at my hardware. (and yes, I know this is an unsupported graphics configuration, and won't work at all in windows due to the lack of hardware texture and lighting, but I've been running SL on this laptop under linux at ~10FPS/24mFarClip for over a year without any major problems other than all the vowels in certain fonts like the IM *window* being a pixel lower than they should be, and I can live with that. It's been happening since 1.17, and I've even grown rather fond of it, but it would be nice to have it fixed.) On Tue, May 6, 2008 at 2:02 PM, Ryan Williams (Which) wrote: > Hmmm... that would be bad. Alternatively you could try -channel (single > dash was the oldschool nasty way). Or stick the argument in gridargs.txt. > > I believe it prints out the command-line arguments in the logs as it > starts up, so that would be a good way to confirm that it's reading the > right thing. > > -RYaN > > (cc-ing sldev, sorry for the dupe kamilion) Oh, and thanks so much for window-izing the statistics bar, it's the main reason I use dazzle... the original dazzle Bright Blue color scheme made my eyes bleed, but this muted blue is much much better. Kudos for listening to us on the eye-bleedyness. Now off to repair the script I've been trying to log in for hours to fix! Thanks, Ryan! -- Kamilion "Never feel stupid for asking questions, feel stupid for ignoring answers." From seg at haxxed.com Tue May 6 16:29:59 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue May 6 16:31:51 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <001a01c8af31$4f62c330$a400000a@gwsystems2.com> References: <001a01c8af31$4f62c330$a400000a@gwsystems2.com> Message-ID: <1210116599.31741.5.camel@localhost> On Tue, 2008-05-06 at 00:26 -0400, Gary Wardell wrote: > > Isn't it possible to stop supporting pre-SP4 Windows 2000? > > I use Win2K, it's very solid and a smaller footprint that later > Windows. Also I object to the activation requirement/limitations > of later windows. My installs of Win XP Pro have no such activation bullcrap. Actually it seems to depend directly on the key you use. Using the exact same XP Pro install disk, using the legit key off the bottom of my laptop, and with certain *cough* not so legit keys, I never ever get bothered about activation, ever. But with certain other illicit keys, it demands I activate upon the first boot. Seriously people, upgrade already. Sheesh. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080506/60f391bf/attachment.pgp From sakkaku at gmail.com Tue May 6 16:36:24 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Tue May 6 16:36:26 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <1210116599.31741.5.camel@localhost> References: <001a01c8af31$4f62c330$a400000a@gwsystems2.com> <1210116599.31741.5.camel@localhost> Message-ID: <79e704e0805061636y6bc8946ra3d2efc49656342e@mail.gmail.com> > My installs of Win XP Pro have no such activation bullcrap. Actually it > seems to depend directly on the key you use. Using the exact same XP Pro > install disk, using the legit key off the bottom of my laptop, and with > certain *cough* not so legit keys, I never ever get bothered about > activation, ever. But with certain other illicit keys, it demands I > activate upon the first boot. > > Seriously people, upgrade already. Sheesh. Retail XP copies require you to activate it, either via web or phone. After a few reinstalls you actually have to call up and go through a really lame process to say a 24 digit or something key then copy down an even longer key into the boxes. Try doing that with a few dozen systems in a day and keep your sanity. From ettore_pasquini at 3dconnexion.com Tue May 6 16:51:54 2008 From: ettore_pasquini at 3dconnexion.com (Ettore Pasquini) Date: Tue May 6 16:51:58 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <1210116599.31741.5.camel@localhost> Message-ID: On 5/6/08 4:29 PM, "Callum Lerwick" wrote: > On Tue, 2008-05-06 at 00:26 -0400, Gary Wardell wrote: >>> Isn't it possible to stop supporting pre-SP4 Windows 2000? >> >> I use Win2K, it's very solid and a smaller footprint that later >> Windows. Also I object to the activation requirement/limitations >> of later windows. > > My installs of Win XP Pro have no such activation bullcrap. Actually it > seems to depend directly on the key you use. Using the exact same XP Pro > install disk, using the legit key off the bottom of my laptop, and with > certain *cough* not so legit keys, I never ever get bothered about > activation, ever. But with certain other illicit keys, it demands I > activate upon the first boot. > > Seriously people, upgrade already. Sheesh. People still use Windows? Really? Jesus. :) Ettore From rdw at lindenlab.com Tue May 6 18:52:53 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue May 6 18:52:59 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <4820306E.70800@streamsense.net> References: <45cf5s5ti8Yt2rtGYovrkG68.alissa_sabre@yahoo.co.jp><2B198A1D-BD6C-405A-8C76-F60602FAE35A@gmail.com> <4820306E.70800@streamsense.net> Message-ID: <48210B75.4050200@lindenlab.com> Thomas Grimshaw wrote: > Argent Stonecutter wrote: >> On 2008-05-05, at 21:26, Alissa Sabre wrote: >>> Isn't it possible to stop supporting pre-SP4 Windows 2000? >> >> Microsoft is making it increasingly difficult to download updates for >> Windows 2000, including SP4. > That's more a case of Microsoft dropping support for w2k which of course > we can do nothing about, however I can't find anything which suggests > it's not easy to download SP4. > > http://www.microsoft.com/downloads/details.aspx?familyid=1001AAF1-749F-49F4-8010-297BD6CA33A0&displaylang=en > > > It doesn't even try to check if you have a genuine copy of windows, > which most microsoft downloads do. But, in any case, even if they do > remove the download.. > > http://www.google.co.uk/search?hl=en&q=%22Index+of%22+%09W2KSP4_EN.EXE&btnG=Google+Search&meta= > > > Can we get some demographics from LL outlining a) the number of w2k > users, and b) the number of w2k SP4 users? I'm not sure if I'm interpreting these numbers correctly, but we seem to have this amount of usage of Win2K: Microsoft Windows 2000 0.774% Microsoft Windows 2000 Service Pack 4 (Build 2195) 0.038% My reading of this is that some special builds of Win2k report longer version strings (Build 2195), but normally Win2k isn't differentiated by service pack level. Still, that's an approximation of the % of users who run Win2K. Similarly: OS X 10.3.9 0.236% This is roughly 3% of OS X usage. This data may be out of date and/or my crunching of the raw numbers may be off, do not put data in mouth, etc etc. -RYaN From robla at lindenlab.com Tue May 6 21:36:52 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue May 6 21:37:00 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> Message-ID: <482131E4.4040508@lindenlab.com> Hi Richard, This set off a good discussion at Linden Lab on this topic. Rather than keep everyone in the dark about where our thinking is at, I'm going to just let you know where we're at. More inline: On 5/4/08 1:08 PM, Richard M Stallman wrote: > Allowing the contributor of a change to use his own code > however he wishes, even after he has contributed it to > the original program, is the right thing to do. But I think > it is not enough to deal with this issue. > > The possibility I would like to avoid is that the developer might > include my code in a non-free version while not including it in his > comparable free version. If he did that, then my contribution would > primarily aid non-free software. Even though I would be allowed to > add it myself to a free fork -- supposing there is one -- that would > not be enough to change the situation. If I understand this correctly, you're worried that we might take a contribution and include it in a proprietary fork of the code, while also publishing a free version of the code that doesn't include the contribution. We'll call this scenario #1 for purposes of this conversation (you'll see why in a bit). If that's all the issue is, I agree that'd be kind of a crummy thing to do. I can't see why we'd have an interest in doing that. However, any legally binding commitment we make would likely result in us unintentionally surrendering legal rights that we'd still like to reserve, which I'll describe below. To address one of many elephants in the room (scenario #2): let's say that Linden Lab decides that it wants to stop publishing the source code for the viewer. This is a very unlikely scenario in my view, but one I can't unequivocally rule out. Since we can't easily extract contributions that are marbled in with our original code, any commitment we make for the contributed code is practically intertwined with our own code. Thus, with a commitment in place not to close ours+contributed code, we'd be powerless to ever close it. While that may seem a desirable outcome for the free software community, that's a very tough commitment to make for a company which has so much invested in this asset. Looking at this from the point of view of our investors, if we became convinced that we just wouldn't get contribution at all without making that commitment, we'd /possibly/ change our tune, but it's also very possible that being forced to commit to making all future versions free forever might instead drive us away from being fuller members of the free software community. Another elephant (scenario #3): we do allow license our source code (with contributions) to third parties under separate license. The way we view such deals is that they give us revenue to hire developers that write more free software. Such software can also be used by proprietary developers, but free software developers get the advantage of not having to pay us for the privilege, where as companies that want to keep their modifications closed have to pay. I think this is a net win for the free software community. Yet another elephant (scenario #4): we have a few proprietary third party components, most of which were added prior to freeing our viewer source code. We've generally advocated to everyone that has licensed us proprietary technology that they offer their code as free software and have had some pretty stern conversations in a case or two. We even purchased a company (Windwark Mark) and together subsequently freed the software they wrote. However, this is a pretty tough market segment to find all-free software and still stay competitive with proprietary competitors. We've had many a debate as to where to draw the line, and I think that while we're moving more slowly than I would like us to, we're moving surely enough toward publishing our own all-free version of the viewer, and others have been able to make very functional all-free alternatives using our codebase. We'll likely be removing at least one of the non-free components (FMOD) soon thanks to community contribution (under this agreement!). All that said, we're not at a point yet where we can jettison all of our proprietary components nor have we yet successfully convinced the developers of all of these components to free their software, but we've made progress. So, while we agree that scenario #1 is bad, I think that in order to really figure out any possible changes in our commitment, we'd have to agree on the right outcomes to scenarios #2-4, and then craft wording that was well-adjusted to all of these scenarios. > So I think that we should call on such developers to make a promise > such as, "If we include your code in a non-free version, we will > include your code with equal functionality and technical advantahes in > a free version, and that free version will have all the features and > capabilities that are common to that non-free version and the free > version you improved." > > With that promise, you will know that your code will contribute to a > free version that isn't just demoware. While we aspire toward that goal, I don't think we can make a legally binding commitment for the reasons described above. However, even in its current state, a 100% free viewer is a viable option, and well past "demoware" state. Furthermore, I think contributing source code back to us is the most efficient way for everyone involved to keep improving toward a better viewer. Rob From seg at haxxed.com Tue May 6 22:07:42 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue May 6 22:07:50 2008 Subject: [sldev] Patch format question In-Reply-To: References: <4820A0B6.60405@gmx.net> Message-ID: <1210136862.31741.11.camel@localhost> On Tue, 2008-05-06 at 14:27 -0500, Soft wrote: > A svn diff is fine. patch accepts that as input without any problems. > ToirtoiseSVN's diff output is fine as well. It needs a little cleanup > because it mixes line ending styles between the header and the body, > but that's trivial for the importer to fix. Trivial my ass. Someone needs to be dragged out in to the street and shot. *Mixing* line ending types completely breaks the ability to automatically detect line ending types, which is what would otherwise happen in every tool I've thrown at it. Pick a line ending, TortoiseSVN, we're at war. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080507/08b3eaae/attachment-0001.pgp From enus at lindenlab.com Wed May 7 00:11:26 2008 From: enus at lindenlab.com (Enus Linden) Date: Wed May 7 00:11:27 2008 Subject: [sldev] Summarizing AWG/LL Open Grid Test Harness discussion & request for further discussion Message-ID: <4821561E.2070500@lindenlab.com> posted to https://wiki.secondlife.com/wiki/AWG_Test_Harness -------------------------------------------------------------------------------- At the AWG meeting held April 29, we discussed what a test harness could look like that would be used to test the agent-domain, rez-avatar, and overall work being done implementing the open grid protocols. I'd like to summarize, and continue the discussion on the mailing list, in-world, and on the wiki. Chat log here: http://wiki.secondlife.com/wiki/AWGroupies-2008-04-29 The goal wrt testing, is to build a test harness that enables testing of published Open Grid protocols (see http://wiki.secondlife.com/wiki/SLGOGP_Draft_1). The intent is not to test SL or OpenSim (or gridX) themselves. Rather, the desire is to create a framework where the implementations of the protocols can be tested independent of environment. We plan to be able to test at the smallest functional level possible, akin to unit testing, and to have the ability to use the framework to sequence steps to enable state specific tests to be run. The longer term vision is essentially a client library, capable of navigating the grid and interacting with the various hosts, sitting next to a testing framework, happily running along telling us what works where, and where something needs a little attention to work according to specification... Shorter term, how do we start? Let's work on defining the test harness components (from the meeting): 1. Login 2. Caps (and while it's around the UDP pipe) 3. Message Handlers (see chttp) 4. Basic web server parts for the Agent, Region and grid bits (ideally a snap in framework) 5. Test framework 6. Test data (I put this here, not really as a component of the harness, more as a "i'm not telling you my test account's password and what are we gonna do about it" thing) Python seems to be the flavor of choice here, with a requirement that it accommodate non-python components as needed. The repository for the code is proposed to be maintained by Linden Lab, distributed as an open source export, under the Apache v2 License (see http://opensource.org/licenses/apache2.0.php). The process and details here are tentative, and need more attention... There is plenty to be figured out obviously. How to start, who wants to play, details are all tbd. My role is primarily intended as one who will facilitate dialogue and contribute as much as possible, but this is intended as a joint effort. So, who wants to play? thanks, enus From seg at haxxed.com Wed May 7 01:02:11 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed May 7 01:02:21 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482131E4.4040508@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: <1210147332.31741.107.camel@localhost> On Tue, 2008-05-06 at 21:36 -0700, Rob Lanphier wrote: > If I understand this correctly, you're worried that we might take a > contribution and include it in a proprietary fork of the code, while > also publishing a free version of the code that doesn't include the > contribution. We'll call this scenario #1 for purposes of this > conversation (you'll see why in a bit). If that's all the issue is, I > agree that'd be kind of a crummy thing to do. I can't see why we'd have > an interest in doing that. However, any legally binding commitment we > make would likely result in us unintentionally surrendering legal rights > that we'd still like to reserve, which I'll describe below. Yes, I for one would see this as a major breach of trust with the community. As such, I really don't think the community needs a promise from Linden Lab. Rather, I think the the promise should go in the other direction. Should Linden Lab resort to such shenanigans, the open source community will quite possibly abandon Linden Lab in a heartbeat and fork our own project. > To address one of many elephants in the room (scenario #2): let's say > that Linden Lab decides that it wants to stop publishing the source code > for the viewer. This is a very unlikely scenario in my view, but one I > can't unequivocally rule out. IMHO, Linden Lab turning around like this would be a bigger loss for Linden Lab than it is for the community. And probably a PR nightmare for LL on top of that. Thus yes, I don't see this happening. ...unless Linden Lab gets bought out by, say, Microsoft. Such things are possible in the world of business. Business, and life, is risk. Linden Lab could get bought out next week. I could get hit by a bus tomorrow. If you spend all your time trying to avoid any risk of anything ever not going perfectly your way, you'll never go anywhere or do anything. Personally I don't think further legally binding assurances are necessary. The GPL license and not giving up ownership of my own code are all the assurance I need. (Is this a bad time to mention I really wish LL would move to GPLv3 or at least GPLv2+ to get rid of the APR incompatibility, which ironically makes the viewer unable to merge in outside GPL code? :) > But it's also very possible that being forced to commit to making all > future versions free forever might instead drive us away from being > fuller members of > the free software community. I don't understand this reasoning. "Free forever" is the fundamental goal of the Free Software movement, is it not? > Another elephant (scenario #3): we do allow license our source code > (with contributions) to third parties under separate license. The way > we view such deals is that they give us revenue to hire developers that > write more free software. Such software can also be used by proprietary > developers, but free software developers get the advantage of not having > to pay us for the privilege, where as companies that want to keep their > modifications closed have to pay. I think this is a net win for the > free software community. This seems perfectly reasonable to me. And Linden Lab is not the first, or only company to adopt this model. > Yet another elephant (scenario #4): we have a few proprietary third > party components, most of which were added prior to freeing our viewer > source code. We've generally advocated to everyone that has licensed us > proprietary technology that they offer their code as free software and > have had some pretty stern conversations in a case or two. We even > purchased a company (Windwark Mark) and together subsequently freed the > software they wrote. However, this is a pretty tough market segment to > find all-free software and still stay competitive with proprietary > competitors. By "stay competitive" LL seems to mean "we like to avoid doing any work we can instead license from others". Which may seem reasonable from a pure business sense, but is ultimately a self fulfilling prophecy. If there's a lack of open source solutions, it's because *you* haven't worked to create it. The whole power of FLOSS is in that it only has to be done right once, and everyone thereafter benefits. Keep in mind, I myself, and others, are willing to, and have *already* put quite a bit of work in to clearing proprietary dependencies from the viewer. Without even being paid by LL for it. All that I, for one, ask is that LL not further bog me down by continuing to add more proprietary dependencies. It would be a huge slap in the face and a major breach of trust. As much as I generally hate black and white thinking, you really can't have it both ways here. You either have to fully commit to adding no further closed dependencies, and eliminating existing ones, or I'm just wasting my time trying to get the viewer into Fedora. (Well, actually I'm not. Forking is always an option...) > We've had many a debate as to where to draw the line, and > I think that while we're moving more slowly than I would like us to, > we're moving surely enough toward publishing our own all-free version of > the viewer, and others have been able to make very functional all-free > alternatives using our codebase. I really haven't heard much feedback about OpenJPEG 1.3. Especially not from LL. Personally I find its performance quite satisfactory as is, though I am currently sitting on another %15-%25 speedup via some T1 optimization, the merging of which is pending figuring out the situation with OpenJPEG 2.0... (I see a tarball is up on their download page now, I still need to take a look at it.) (Also note that it has been confirmed, MSVC doesn't seem to optimize worth crap. There is something like an order of magnitude (!) performance difference between compiling OpenJPEG with MSVC vs gcc. Also note Intel C++ gets similar performance to gcc. So... don't be surprised if it's still slow with MSVC. For now use gcc or Intel C++. :P) > We'll likely be removing at least one of the non-free components > (FMOD) soon thanks to community contribution (under this agreement!). fmod 3 is a dead end anyway. Work has to be put in to move to a different API anyway, so might as well make that API OpenAL... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080507/3fc5ebef/attachment.pgp From seg at haxxed.com Wed May 7 01:07:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed May 7 01:07:47 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: References: <481F7279.809@watson.ibm.com> Message-ID: <1210147663.31741.109.camel@localhost> On Mon, 2008-05-05 at 19:51 -0500, Dale Mahalko wrote: > An interesting approach, doing all rendering on a remote server and > just streaming 2D video to the client. I've run the client over VNC before... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080507/cdf3c131/attachment.pgp From kfa at gmx.net Wed May 7 01:13:45 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed May 7 01:14:33 2008 Subject: [sldev] Patch format question In-Reply-To: <1210136862.31741.11.camel@localhost> References: <4820A0B6.60405@gmx.net> <1210136862.31741.11.camel@localhost> Message-ID: <482164B9.9000009@gmx.net> Callum Lerwick wrote: > On Tue, 2008-05-06 at 14:27 -0500, Soft wrote: >> A svn diff is fine. patch accepts that as input without any problems. >> ToirtoiseSVN's diff output is fine as well. It needs a little cleanup >> because it mixes line ending styles between the header and the body, >> but that's trivial for the importer to fix. > > Trivial my ass. Someone needs to be dragged out in to the street and > shot. *Mixing* line ending types completely breaks the ability to > automatically detect line ending types, which is what would otherwise > happen in every tool I've thrown at it. > > Pick a line ending, TortoiseSVN, we're at war. > > LOL. Yes that would be bad indeed. But I don't think that is an issue with SVN or Tortoise. Tortoise is really just a GUI that calls SVN with appropriate commands and options. If you ever get a line ending changed, then your editor is to blame or whatever you threw at it. Here is a relevant chapter from the SVN manual addressing the subject of line endings: http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5 I'm not exactly sure how mixing can occur. A wild guess would be that it happens when you create a patch on Windows from a file in UNIX format, both in the repository and in your working copy. Or vice versa. With no conversion option specified, SVN should treat it as binary, but write out the headers in native format of the OS where it is run (would have to look into the SVN source to verify, didn't find it documented). If you download the SL source in the appropriate format for your platform, work on it and give it back from there, then no mixing should occur. (???) But my knowledge of that is rather patchy - no pun intended ;). I didn't want to start a discussion that takes resources from more important work. If Soft says it's ok then I'm grateful for the alleviation and take it for granted until proven wrong. From kfa at gmx.net Wed May 7 02:31:15 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed May 7 02:32:07 2008 Subject: Replacing FMOD - was: Re: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482131E4.4040508@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: <482176E3.6000605@gmx.net> Rob Lanphier wrote: > ... > alternatives using our codebase. We'll likely be removing at least one > of the non-free components (FMOD) soon thanks to community contribution > (under this agreement!). All that said, we're not at a point yet where > ... Cool :) Replace with what? JUCE? http://rawmaterialsoftware.com/juce/index.php That'd be awesome for anyone into music... From tao.takashi at googlemail.com Wed May 7 03:09:12 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Wed May 7 03:09:15 2008 Subject: [sldev] Summarizing AWG/LL Open Grid Test Harness discussion & request for further discussion In-Reply-To: <4821561E.2070500@lindenlab.com> References: <4821561E.2070500@lindenlab.com> Message-ID: <23bbb49e0805070309t111b045bl2dc2a9f4867dedae@mail.gmail.com> Hi! On Wed, May 7, 2008 at 9:11 AM, Enus Linden wrote: > posted to https://wiki.secondlife.com/wiki/AWG_Test_Harness > > > At the AWG meeting held April 29, we discussed what a test harness could > look like that would be used to test the agent-domain, rez-avatar, and > overall work being done implementing the open grid protocols. I'd like to > summarize, and continue the discussion on the mailing list, in-world, and on > the wiki. Chat log here: > http://wiki.secondlife.com/wiki/AWGroupies-2008-04-29 > > The goal wrt testing, is to build a test harness that enables testing of > published Open Grid protocols (see > http://wiki.secondlife.com/wiki/SLGOGP_Draft_1). The intent is not to test > SL or OpenSim (or gridX) themselves. Rather, the desire is to create a > framework where the implementations of the protocols can be tested > independent of environment. We plan to be able to test at the smallest > functional level possible, akin to unit testing, and to have the ability to > use the framework to sequence steps to enable state specific tests to be > run. > > The longer term vision is essentially a client library, capable of > navigating the grid and interacting with the various hosts, sitting next to > a testing framework, happily running along telling us what works where, and > where something needs a little attention to work according to > specification... > > Shorter term, how do we start? > > Let's work on defining the test harness components (from the meeting): > 1. Login > 2. Caps (and while it's around the UDP pipe) > 3. Message Handlers (see chttp) > 4. Basic web server parts for the Agent, Region and grid bits (ideally a > snap in framework) > 5. Test framework > 6. Test data (I put this here, not really as a component of the harness, > more as a "i'm not telling you my test account's password and what are we > gonna do about it" thing) add reverse HTTP to it now ;-) > Python seems to be the flavor of choice here, with a requirement that it > accommodate non-python components as needed. The repository for the code is > proposed to be maintained by Linden Lab, distributed as an open source > export, under the Apache v2 License (see > http://opensource.org/licenses/apache2.0.php). The process and details here > are tentative, and need more attention... Open Source Export means that there is no direct SVN access possible? Because for regulat contributors I would find that easier. As for the framework itself I would propose to create a pluggable one where people might even be able to plugin test components without having access to the main source. I would propose the Zope Component Architecture here and can also quickly make an example of how it could work. It's basically a global registry. I would also encourage people to directly lay everything out as eggs. Using buildout would make sense here as well as people can then very easily setup their test sandbox. I can also demo/document all that. Plugins/tests could then also be made available through the cheeseshop. > There is plenty to be figured out obviously. How to start, who wants to > play, details are all tbd. My role is primarily intended as one who will > facilitate dialogue and contribute as much as possible, but this is intended > as a joint effort. > > So, who wants to play? Apparently me, as I wanted to work on some agent domain stuff anyway and tests make sense then. (depending on time constraints though as alyways) cheers, Christian -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From secret.argent at gmail.com Wed May 7 03:33:37 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed May 7 03:33:07 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" In-Reply-To: <1210116599.31741.5.camel@localhost> References: <001a01c8af31$4f62c330$a400000a@gwsystems2.com> <1210116599.31741.5.camel@localhost> Message-ID: <65F500CC-94CC-40BD-9817-B694934FF3C7@gmail.com> On 2008-05-06, at 18:29, Callum Lerwick wrote: > Seriously people, upgrade already. Sheesh. Ah, right, if you're lucky or you use an illicit key you might not trigger the time-bomb in XP. If I did something like what Microsoft is doing, as a contractor, I'd be out on my ass. No way in hell will I risk upgrading to a version with code like that in it. From sakkaku at gmail.com Wed May 7 05:52:52 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed May 7 05:52:55 2008 Subject: Replacing FMOD - was: Re: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482176E3.6000605@gmx.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482176E3.6000605@gmx.net> Message-ID: <79e704e0805070552s37614826va159570ecfa1329f@mail.gmail.com> > Rob Lanphier wrote: > > ... > > alternatives using our codebase. We'll likely be removing at least one > > of the non-free components (FMOD) soon thanks to community contribution > > (under this agreement!). All that said, we're not at a point yet where > > ... > > > Cool :) Replace with what? > > JUCE? > > http://rawmaterialsoftware.com/juce/index.php > > That'd be awesome for anyone into music... My guess would be OpenAL as it has a lot of the features already in use (ie pitch shifting, doppler). From agrimes at speakeasy.net Wed May 7 08:35:36 2008 From: agrimes at speakeasy.net (Alan Grimes) Date: Wed May 7 09:34:47 2008 Subject: [sldev] Please enable threading on linux! =( Message-ID: <4821CC48.3000404@speakeasy.net> I seem to remember that threading was enabled on linux for a while, why has it been disabled again? =((( I usually get between 8 and 10 fps on my old DDR 266 based dual athlon (circa 2003) I could do quite a bit better if even half of my second CPU were being used. Given that most new computers are SMP boxen, why disable this critical functionality? =( -- Ron Paul: A man of Peace. Chemistry.com: A total rip-off. Powers are not rights. We did not invade Iraq, the government did. From carjay at gmx.net Wed May 7 09:43:53 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed May 7 09:44:00 2008 Subject: [sldev] Patch format question In-Reply-To: <482164B9.9000009@gmx.net> References: <4820A0B6.60405@gmx.net> <1210136862.31741.11.camel@localhost> <482164B9.9000009@gmx.net> Message-ID: <4821DC49.5020604@gmx.net> Felix Duesenburg wrote: > I'm not exactly sure how mixing can occur. A wild guess would be that > it happens when you create a patch on Windows from a file in UNIX > format, both in the repository and in your working copy. Or vice > versa. With no conversion option specified, SVN should treat it as > binary, but write out the headers in native format of the OS where it > is run (would have to look into the SVN source to verify, didn't find > it documented). If That's what the svn:eol-style=native property is for. You need to set it explicitly or simply add a pattern to the svn config to have it set automatically for all source files. SVN will complain at checkin if it finds a file with a mix of line endings so you have a chance to undo any errors with unix2dos. Personally I never used TortoiseSVN much, I feel more comfortable with svn on a command line since I get things done more quickly that way. The only thing I liked about it compared to pure svn was the ability to use the context menu to solve 3-way merge conflicts. But after the TortoiseSVN cache repeatedly caused explorer.exe to hang (even when turned off) I wrote a small python script to do the 3-way merges and uninstalled it. I am not saying it is bad, I think it's very useful, it just didn't fit my needs. Regards, Carsten From rms at gnu.org Wed May 7 10:34:31 2008 From: rms at gnu.org (Richard M Stallman) Date: Wed May 7 10:35:15 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482131E4.4040508@lindenlab.com> (message from Rob Lanphier on Tue, 06 May 2008 21:36:52 -0700) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: It seems to me that your elephants are actually no problem for this. Yet another elephant (scenario #4): we have a few proprietary third party components, most of which were added prior to freeing our viewer source code. This is a serious problem for the use of your viewer -- people in the Free World cannot use those components -- so I am glad you are working on replacing them. But it isn't a problem for the issue at hand. Clearly the community contributions are not in those on-free components. The criterion I suggested should apply to whatever component the person's contributions are in. Another elephant (scenario #3): we do allow license our source code (with contributions) to third parties under separate license. The way we view such deals is that they give us revenue to hire developers that write more free software. I designed the criterion specifically with that in mind. You would be able to do that, using contributions under this criterion, provided that the version you license out in that way follows the criterion. In other words, the free version of the same component should have all the features as the version you license out. If they are in fact the same code, as is the case with Qt for instance, the criterion is automatically satisfied. To address one of many elephants in the room (scenario #2): let's say that Linden Lab decides that it wants to stop publishing the source code for the viewer. This is a very unlikely scenario in my view, but one I can't unequivocally rule out. In this situation, my criterion would require that you not include more of the contributor's code in the future non-free versions than you include in the last free version. That should not be difficult. To make future versions non-free would be rather shocking, and some contributors might feel betrayed. Thus, potential contributors ought to consider this possibility before deciding they want to contribute. However, that is a different issue, and doesn't interfere with use of this criterion. Use of thuis criterion could help convince community developers to accept the possibility you would stop releasing free versions -- because it would promise them that all of their code that you ever do use will be in one of your free versions (and most likely in the last one). From agrimes at speakeasy.net Wed May 7 10:17:47 2008 From: agrimes at speakeasy.net (Alan Grimes) Date: Wed May 7 11:16:49 2008 Subject: [sldev] library versions. =P Message-ID: <4821E43B.8050800@speakeasy.net> 2008-05-07T17:16:35Z INFO: ll_try_gtk_init: - Compiled against GTK version 2.4.14 2008-05-07T17:16:35Z INFO: ll_try_gtk_init: - Running against GTK version 2.12.9 2008-05-07T17:16:35Z INFO: createContext: Compiled against SDL 1.2.5 2008-05-07T17:16:35Z INFO: createContext: Running against SDL 1.2.13 -- Ron Paul: A man of Peace. Chemistry.com: A total rip-off. Powers are not rights. We did not invade Iraq, the government did. From monkowsk at watson.ibm.com Wed May 7 14:17:45 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed May 7 14:29:55 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: <48221C79.7000408@watson.ibm.com> Richard M Stallman wrote: ... > In other words, the free version of the same component should have all > the features as the version you license out. ... > Use of this criterion could help convince community developers to > accept the possibility you would stop releasing free versions -- > because it would promise them that all of their code that you ever do > use will be in one of your free versions (and most likely in the last > one). I don't get it. If Linden were to include your criterion and then do the opposite, then developers would hate them, would stop contributing code, and someone may sue. If Linden does not include the criterion, and does the opposite, then developers would hate them and would stop contributing code. The difference is lawyers. Somehow the assurance of being able to get lawyers involved would not convince me "to accept the possibility [Linden] would stop releasing free versions." You argue that your criterion is not incompatible with Linden's policies, but compatibility is not a good enough reason to include it. Mike From lenglish5 at cox.net Wed May 7 14:36:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed May 7 14:36:52 2008 Subject: [sldev] Summarizing AWG/LL Open Grid Test Harness discussion & request for further discussion In-Reply-To: <23bbb49e0805070309t111b045bl2dc2a9f4867dedae@mail.gmail.com> References: <4821561E.2070500@lindenlab.com> <23bbb49e0805070309t111b045bl2dc2a9f4867dedae@mail.gmail.com> Message-ID: <482220DB.7010706@cox.net> Christian Scholz / Tao Takashi (SL) wrote: > Hi! > > On Wed, May 7, 2008 at 9:11 AM, Enus Linden wrote: > >> posted to https://wiki.secondlife.com/wiki/AWG_Test_Harness >> >> >> At the AWG meeting held April 29, we discussed what a test harness could >> look like that would be used to test the agent-domain, rez-avatar, and >> overall work being done implementing the open grid protocols. I'd like to >> summarize, and continue the discussion on the mailing list, in-world, and on >> the wiki. Chat log here: >> http://wiki.secondlife.com/wiki/AWGroupies-2008-04-29 >> >> The goal wrt testing, is to build a test harness that enables testing of >> published Open Grid protocols (see >> http://wiki.secondlife.com/wiki/SLGOGP_Draft_1). The intent is not to test >> SL or OpenSim (or gridX) themselves. Rather, the desire is to create a >> framework where the implementations of the protocols can be tested >> independent of environment. We plan to be able to test at the smallest >> functional level possible, akin to unit testing, and to have the ability to >> use the framework to sequence steps to enable state specific tests to be >> run. >> >> The longer term vision is essentially a client library, capable of >> navigating the grid and interacting with the various hosts, sitting next to >> a testing framework, happily running along telling us what works where, and >> where something needs a little attention to work according to >> specification... >> >> Shorter term, how do we start? >> >> Let's work on defining the test harness components (from the meeting): >> 1. Login >> 2. Caps (and while it's around the UDP pipe) >> 3. Message Handlers (see chttp) >> 4. Basic web server parts for the Agent, Region and grid bits (ideally a >> snap in framework) >> 5. Test framework >> 6. Test data (I put this here, not really as a component of the harness, >> more as a "i'm not telling you my test account's password and what are we >> gonna do about it" thing) >> > > add reverse HTTP to it now ;-) > > >> Python seems to be the flavor of choice here, with a requirement that it >> accommodate non-python components as needed. The repository for the code is >> proposed to be maintained by Linden Lab, distributed as an open source >> export, under the Apache v2 License (see >> http://opensource.org/licenses/apache2.0.php). The process and details here >> are tentative, and need more attention... >> > > Open Source Export means that there is no direct SVN access possible? > Because for regulat contributors > I would find that easier. > > As for the framework itself I would propose to create a pluggable one > where people might even be able > to plugin test components without having access to the main source. I > would propose the Zope Component > Architecture here and can also quickly make an example of how it could > work. It's basically a global registry. > I would also encourage people to directly lay everything out as eggs. > Using buildout would make sense here > as well as people can then very easily setup their test sandbox. I can > also demo/document all that. > Plugins/tests could then also be made available through the cheeseshop. > > >> There is plenty to be figured out obviously. How to start, who wants to >> play, details are all tbd. My role is primarily intended as one who will >> facilitate dialogue and contribute as much as possible, but this is intended >> as a joint effort. >> >> So, who wants to play? >> > > Apparently me, as I wanted to work on some agent domain stuff anyway > and tests make sense then. > (depending on time constraints though as alyways) > > cheers, > > Christian > > > The login presence script on the wiki contains a generic UDP packet handler, though only a handful of packets are fully supported beyond being able to evaluate the packet header (just those needed to keep a "presence" on the grid). The chat bot I've been working on since forever, handles even less robustly the EventQueueGet but that's mostly because I'm not sure what long-poll events need handling in the first place. Any UDP packet might need to be handled via the EventQueueGet handler, which functionality wold be trivial to extend via a generic packet assembler ala the LL viewer or libsl, but the less/ill/un-defined EventQUeueGet-only messages are a different story. There's no real documentation anywhere that I know of save in the source code of the LL viewer and the libsl. Regardless, UDP and EventQueueGet handlers are trivial to implement. Functionality might be another story, of course. On the topic of scale, I tested 300 separate Python scripts running a simple http faux-POST server as an avie remote command processor last night, just to see if the idea would be viable under a heavy load. Seems that it is since all 300 were able to process a few messages in less than a minute on a single dual G5 PowerMac purchased over 3 years ago, including startup/initialization/respond-to-POST/print-to-file/quit time. If we adopt the Zope control mechanism and use the test harness(es) as distributed Zope objects that might exist on any number of remote machines, we could, in theory, do a full stress test of any beta grid with as few as 10 to as many as one hundredK test harnesses running simultaneously on a few thousand machines, controlled by one or more servers dedicated to that control... That last may seem a bit pie-in-the-sky-ish, but if we're serious about Zero's "scary numbers" of the open grid that's actually a rather minimal number to get a feel for scaling of things like group IM, inventory management and even login. Lawson From lenglish5 at cox.net Wed May 7 14:57:53 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed May 7 14:57:55 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: <482225E1.70205@cox.net> Richard M Stallman wrote: Rob L wrote: > Another elephant (scenario #3): we do allow license our source code > (with contributions) to third parties under separate license. The way > we view such deals is that they give us revenue to hire developers that > write more free software. > > I designed the criterion specifically with that in mind. You would be > able to do that, using contributions under this criterion, provided > that the version you license out in that way follows the criterion. > In other words, the free version of the same component should have all > the features as the version you license out. If they are in fact the > same code, as is the case with Qt for instance, the criterion is > automatically satisfied. > I think this is where I was (perhaps am) confused. As far as I know, the commercial license that Electric Sheep has to produce the onrez SL viewer for use by CSI-NY allows them to use any GPLed components of the LL GPLed viewer that they like. The sticking point, and it just may be I'm not reading things well, is that they decided to deliberately cripple the functionality of their viewer in order to make it more CSI:NY-audience-friendly. IOW, on THEIR side, they made a marketing decision to leave out functions that are available in the GPL version. They had access to them, as far as I know, and decided NOT to use them for the sake of simplicity. So the functions were available for the *programmers* to use but were not included in the final product that was released. It is probably just a wording issue that is causing my confusion since normally one would assume that the commercially licensed version will have MORE features--and it did have NEW ones as well--but the onrez commercial licensed viewer also left common features out. Lawson From mark at identityserver.net Wed May 7 15:18:14 2008 From: mark at identityserver.net (Domino Marama) Date: Wed May 7 15:18:32 2008 Subject: [sldev] Python indra libs Message-ID: <1210198694.7503.5.camel@domino-laptop> Are the python modules in "linden/indra/lib/python/indra" actually installed anywhere? These seem like they should be separate from the main client source and ideally available via easy_install (.egg) for Python development of client utilities. It's something I'll need for my Blender scripts as I add LLSD support, and I have thought an official Linden package would be more appropriate than doing my own unofficial one :) From matthew.dowd at hotmail.co.uk Wed May 7 15:21:49 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed May 7 15:21:51 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482225E1.70205@cox.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: > I think this is where I was (perhaps am) confused. As far as I know, the > commercial license that Electric Sheep has to produce the onrez SL > viewer for use by CSI-NY allows them to use any GPLed components of the > LL GPLed viewer that they like. As I understand Richard's criterion, is that Richard wants the contribution agreement to ensure that if LL takes a contribution, that contribution *must* be included in *at least one* release of the open source/free viewer. The agreement will (as now) give LL the right to include that contribution in a closed source/commercial viewer, but also (as now) give LL the right not to include the contribution. Also (as now), LL has the right not to include the contribution in future versions (either closedsource/commercial or free/opensource), but if LL includes the contribution in any version (closedsource/commercial or free/opensource or whatever), at least one (and possible only one) of the free/opensource released must include it. This of course doesn't stop LL entering into a special agreement with a programmer if they really want a contribution in a closedsource viewer, which they don't want ever to appear in the opensource/free one, and if the contributor is happy with that. In theory, LL could include a contribution for just one release and then immediately roll the contribution back on in the next release just to get around this, but I can't really see a real life scenario where there would be any advantage for them to do this which would sufficient offset the loss of trust from the opensource community which doing this would cause! Matthew _________________________________________________________________ Great deals on almost anything at eBay.co.uk. Search, bid, find and win on eBay today! http://clk.atdmt.com/UKM/go/msnnkmgl0010000004ukm/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080507/0076b1c7/attachment.htm From kf6kjg at gmail.com Wed May 7 15:44:22 2008 From: kf6kjg at gmail.com (Ricky) Date: Wed May 7 15:44:24 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: <3bb9647e0805071544r54baab11ldbc35e022e44fb66@mail.gmail.com> Just my 2 cents ;D As has been stated, any perceived "violation of trust" by LL would immediately result in a fork. Forking is common in Open Source, and I believe in Free Software as well, whenever there is an irreconcilable difference in ideology or implementation. That ability is our (the OS Developers,) safety net. If LL, or any company/group/individual publishing open source software, breaks trust, then the community forks. This is not to say that I expect such. Again, this was only my 2 cents. Ricky (Cron Stardust) On Wed, May 7, 2008 at 3:21 PM, Matthew Dowd wrote: > > > > I think this is where I was (perhaps am) confused. As far as I know, the > > > commercial license that Electric Sheep has to produce the onrez SL > > viewer for use by CSI-NY allows them to use any GPLed components of the > > LL GPLed viewer that they like. > > As I understand Richard's criterion, is that Richard wants the > contribution agreement to ensure that if LL takes a contribution, that > contribution *must* be included in *at least one* release of the open > source/free viewer. > > The agreement will (as now) give LL the right to include that contribution > in a closed source/commercial viewer, but also (as now) give LL the right > not to include the contribution. > > Also (as now), LL has the right not to include the contribution in future > versions (either closedsource/commercial or free/opensource), > > but if LL includes the contribution in any version > (closedsource/commercial or free/opensource or whatever), at least one (and > possible only one) of the free/opensource released must include it. > > This of course doesn't stop LL entering into a special agreement with a > programmer if they really want a contribution in a closedsource viewer, > which they don't want ever to appear in the opensource/free one, and if the > contributor is happy with that. > > In theory, LL could include a contribution for just one release and then > immediately roll the contribution back on in the next release just to get > around this, but I can't really see a real life scenario where there would > be any advantage for them to do this which would sufficient offset the loss > of trust from the opensource community which doing this would cause! > > Matthew > > > ------------------------------ > Get 5GB of online storage for free! Get it Now! > > > _______________________________________________ > 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/20080507/e3f9f1ef/attachment-0001.htm From mark at identityserver.net Wed May 7 15:46:23 2008 From: mark at identityserver.net (Domino Marama) Date: Wed May 7 15:46:32 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> Message-ID: <1210200383.7503.17.camel@domino-laptop> > Use of this criterion could help convince community developers to > accept the possibility you would stop releasing free versions -- > because it would promise them that all of their code that you ever do > use will be in one of your free versions (and most likely in the last > one). Thanks for raising this interesting point. I'm sure a lot of people would be somewhat annoyed if the client did revert to closed source and all the community patches that haven't been applied yet went into that version. In such a scenario (however unlikely) I can see why the criterion would be important. From dahliatrimble at gmail.com Wed May 7 15:54:11 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed May 7 15:54:14 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482225E1.70205@cox.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: Would the onrez viewer be an example where the submission agreement would be applicable instead of GPL? Also, I vaguely recall hearing complaints that the OnRez viewer was similar to the linden viewer with a notable exception that content creation tools were obfuscated. If true it would seem to me to be somewhat antithetical to the spirit behind GPL. On Wed, May 7, 2008 at 2:57 PM, Lawson English wrote: > Richard M Stallman wrote: > Rob L wrote: > > > Another elephant (scenario #3): we do allow license our source code > > (with contributions) to third parties under separate license. The way > > we view such deals is that they give us revenue to hire developers that > > write more free software. > > > > I designed the criterion specifically with that in mind. You would be > > able to do that, using contributions under this criterion, provided > > that the version you license out in that way follows the criterion. > > In other words, the free version of the same component should have all > > the features as the version you license out. If they are in fact the > > same code, as is the case with Qt for instance, the criterion is > > automatically satisfied. > > > > > > I think this is where I was (perhaps am) confused. As far as I know, the > commercial license that Electric Sheep has to produce the onrez SL viewer > for use by CSI-NY allows them to use any GPLed components of the LL GPLed > viewer that they like. The sticking point, and it just may be I'm not > reading things well, is that they decided to deliberately cripple the > functionality of their viewer in order to make it more > CSI:NY-audience-friendly. > > IOW, on THEIR side, they made a marketing decision to leave out functions > that are available in the GPL version. They had access to them, as far as I > know, and decided NOT to use them for the sake of simplicity. So the > functions were available for the *programmers* to use but were not included > in the final product that was released. > > > > It is probably just a wording issue that is causing my confusion since > normally one would assume that the commercially licensed version will have > MORE features--and it did have NEW ones as well--but the onrez commercial > licensed viewer also left common features out. > > > Lawson > > _______________________________________________ > 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/20080507/8a29ae4e/attachment.htm From rdw at lindenlab.com Wed May 7 16:04:40 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed May 7 16:04:44 2008 Subject: [sldev] Python indra libs In-Reply-To: <1210198694.7503.5.camel@domino-laptop> References: <1210198694.7503.5.camel@domino-laptop> Message-ID: <48223588.9070907@lindenlab.com> Domino Marama wrote: > Are the python modules in "linden/indra/lib/python/indra" actually > installed anywhere? > > These seem like they should be separate from the main client source and > ideally available via easy_install (.egg) for Python development of > client utilities. > > It's something I'll need for my Blender scripts as I add LLSD support, > and I have thought an official Linden package would be more appropriate > than doing my own unofficial one :) > > The llsd library could be packaged up on its own, but realistically the rest of them mostly constitute miscellaneous libraries. We could technically package them up in one ugly bundle, but it doesn't seem like anyone would use them in that form. I'm even a little uncomfortable with packaging up llsd.py because the API is not so good and I don't want to even imply that we're not gonna muck with it. :-) -RYaN From mark at identityserver.net Wed May 7 16:24:37 2008 From: mark at identityserver.net (Domino Marama) Date: Wed May 7 16:24:49 2008 Subject: [sldev] Python indra libs In-Reply-To: <48223588.9070907@lindenlab.com> References: <1210198694.7503.5.camel@domino-laptop> <48223588.9070907@lindenlab.com> Message-ID: <1210202677.7503.25.camel@domino-laptop> On Wed, 2008-05-07 at 16:04 -0700, Ryan Williams (Which) wrote: > Domino Marama wrote: > > Are the python modules in "linden/indra/lib/python/indra" actually > > installed anywhere? > > > > These seem like they should be separate from the main client source and > > ideally available via easy_install (.egg) for Python development of > > client utilities. > The llsd library could be packaged up on its own, but realistically the > rest of them mostly constitute miscellaneous libraries. We could > technically package them up in one ugly bundle, but it doesn't seem like > anyone would use them in that form. Fair enough, though I suspect more people would use them in that form than hidden away in the viewer source ;) > I'm even a little uncomfortable with packaging up llsd.py because the > API is not so good and I don't want to even imply that we're not gonna > muck with it. :-) No worries. I'll just pull out the bits I need then. Might be better for me as I can possibly get away with the cut down Python in Blender that way. Thanks for the quick response :) Domino From paulratnadeep at yahoo.com Wed May 7 17:52:59 2008 From: paulratnadeep at yahoo.com (Ratnadeep Paul) Date: Wed May 7 17:53:03 2008 Subject: [sldev] Rotation Message-ID: <547504.35454.qm@web57910.mail.re3.yahoo.com> Hi All I am a pretty new user to Linden Scripting. I have a specific problem. I need to rotate an object using scripts. My task is to rotate the prim about Y-axis, X-axis and Z-axis in that order plus I would like to rotate each time about the global axes and not the local axes. Can somebody help me? I know it must be very simple but I would like some push or hint in a general direction. Any help is welcome. Regards Paul --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080507/0271857b/attachment.htm From sakkaku at gmail.com Wed May 7 18:31:26 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed May 7 18:31:29 2008 Subject: [sldev] Rotation In-Reply-To: <547504.35454.qm@web57910.mail.re3.yahoo.com> References: <547504.35454.qm@web57910.mail.re3.yahoo.com> Message-ID: <79e704e0805071831q129c2f8en1f9d9cdb172503b8@mail.gmail.com> On Wed, May 7, 2008 at 8:52 PM, Ratnadeep Paul wrote: > Hi All > > I am a pretty new user to Linden Scripting. I have a specific problem. I > need to rotate an object using scripts. My task is to rotate the prim about > Y-axis, X-axis and Z-axis in that order plus I would like to rotate each > time about the global axes and not the local axes. > Can somebody help me? I know it must be very simple but I would like some > push or hint in a general direction. > Any help is welcome. > > Regards > Paul I am going to assume this is an attachment? To rotate around in a circle I wrote up this function awhile back: list GenerateRotationList(integer num) { list RotationList = []; float increment = 360 / (float) num; vector Rot = <0,0,0>; while(num--) RotationList += llEuler2Rot( (Rot += <0,0,increment>) * DEG_TO_RAD ); return RotationList; } Where num is the "points" around the axis that you would like with the last one being on ZERO_ROTATION. If you don't actually need that precision (and just want to rotate constantly) you can use llTargetOmega and it will rotate constantly (without making the sim have to be tortured by a timer). I think you get get the region (not local) rotation by multiplying the rotation by the avatars global rotation but I haven't tested this though. From rdw at lindenlab.com Wed May 7 18:44:35 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed May 7 18:44:37 2008 Subject: [sldev] Python indra libs In-Reply-To: <1210202677.7503.25.camel@domino-laptop> References: <1210198694.7503.5.camel@domino-laptop> <48223588.9070907@lindenlab.com> <1210202677.7503.25.camel@domino-laptop> Message-ID: <48225B03.3010303@lindenlab.com> Domino Marama wrote: > On Wed, 2008-05-07 at 16:04 -0700, Ryan Williams (Which) wrote: >> Domino Marama wrote: >>> Are the python modules in "linden/indra/lib/python/indra" actually >>> installed anywhere? >>> >>> These seem like they should be separate from the main client source and >>> ideally available via easy_install (.egg) for Python development of >>> client utilities. >> The llsd library could be packaged up on its own, but realistically the >> rest of them mostly constitute miscellaneous libraries. We could >> technically package them up in one ugly bundle, but it doesn't seem like >> anyone would use them in that form. > > Fair enough, though I suspect more people would use them in that form than hidden away in the viewer source ;) > >> I'm even a little uncomfortable with packaging up llsd.py because the >> API is not so good and I don't want to even imply that we're not gonna >> muck with it. :-) > > No worries. I'll just pull out the bits I need then. Might be better for > me as I can possibly get away with the cut down Python in Blender that > way. Cool beans. I do agree we should clean them up, and package them for easier consumption. We will eventually. :-) -RYaN From timothyhorrigan at mac.com Wed May 7 19:01:25 2008 From: timothyhorrigan at mac.com (Timothy Horrigan) Date: Wed May 7 19:01:37 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: <48225EF5.1000906@mac.com> I used OnRez for a while... although currently I prefer the official 1.19.1.4. If I recall, the build tools were the same except there was no Build button on the tool bar, and the various build functions were (mostly) regrouped under one Build menu. It was actually a good client for building. The only thing OnRez nerfed (as far as I could tell) were atmospherics and texture rendering, which were made simpler and quicker for less powerful graphics cards. --Tammy Nowotny Dahlia Trimble wrote: > Would the onrez viewer be an example where the submission agreement > would be applicable instead of GPL? > > Also, I vaguely recall hearing complaints that the OnRez viewer was > similar to the linden viewer with a notable exception that content > creation tools were obfuscated. If true it would seem to me to be > somewhat antithetical to the spirit behind GPL. > > > From lenglish5 at cox.net Wed May 7 19:53:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed May 7 19:53:51 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <481B3172.4080702@watson.ibm.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207 @lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> Message-ID: <48226B3D.2080303@cox.net> Mike Monkowski wrote: > Callum Lerwick wrote: >> Ever seen the surface editors in something like Lightwave or Maya? Guess >> what SL is missing... :) Not to mention they support shader plugins. I >> still think the future lies in supporting user-supplied GLSL shaders... >> >> (This is the cue for the sldev peanut gallery to shout me down and >> explain how I'm an idiot for even suggesting such a thing.) > > I don't understand why you would expect to be shouted down. I don't > remember anyone objecting to plugins before. I don't know if there's > been any discussion about shader plugins specifically, but shaders are > just code. You have access to all of the GLSL code for the viewer. > The only argument you might get is that you say "the future" and I > would suggest it should be "the present." Why wait? > The problem with any plugin architrecture for the SL viewer is that it requires a great deal of "buy-in" from Linden Lab to make it work. And my own view, speaking as a documentor of SL prototocols, is that plugins won't make much sense until the protocols are well-documented, and the transition to a new viewer structure (which will hopefully happen as the protocols change radically over the next 2 years) is far enough along for people to see what makes sense as far as plugin APIs go. As we create new viewer test harnesses to test login, inventory, gorup IM, etc., it would make sense to create test modules for new graphics as well. The modular-viewer VAG proposal is still sitting there if anyone wants to forgo jumping on the libsl/openviewer/realXtend bandwagon and design the modular/pluggable viewer of the future.... http://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft Lawson From sakkaku at gmail.com Wed May 7 20:55:09 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed May 7 20:55:12 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <48226B3D.2080303@cox.net> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> Message-ID: <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> On Wed, May 7, 2008 at 10:53 PM, Lawson English wrote: > Mike Monkowski wrote: > > > Callum Lerwick wrote: > > > > > Ever seen the surface editors in something like Lightwave or Maya? Guess > > > what SL is missing... :) Not to mention they support shader plugins. I > > > still think the future lies in supporting user-supplied GLSL shaders... > > > > > > (This is the cue for the sldev peanut gallery to shout me down and > > > explain how I'm an idiot for even suggesting such a thing.) > > > > > > > I don't understand why you would expect to be shouted down. I don't > remember anyone objecting to plugins before. I don't know if there's been > any discussion about shader plugins specifically, but shaders are just code. > You have access to all of the GLSL code for the viewer. The only argument > you might get is that you say "the future" and I would suggest it should be > "the present." Why wait? > > > > > > The problem with any plugin architrecture for the SL viewer is that it > requires a great deal of "buy-in" from Linden Lab to make it work. And my > own view, speaking as a documentor of SL prototocols, is that plugins won't > make much sense until the protocols are well-documented, and the transition > to a new viewer structure (which will hopefully happen as the protocols > change radically over the next 2 years) is far enough along for people to > see what makes sense as far as plugin APIs go. > > As we create new viewer test harnesses to test login, inventory, gorup IM, > etc., it would make sense to create test modules for new graphics as well. > The modular-viewer VAG proposal is still sitting there if anyone wants to > forgo jumping on the libsl/openviewer/realXtend bandwagon and design the > modular/pluggable viewer of the future.... > > http://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft > > > > > Lawson What I really want (as an LSL scripter) is to have the ability to make localized HUDs (like Vendetta Online and WoW, which use LUA) as it doesn't really make sense to do all of the processing on the server (as it is incredibly slow to update, particularly during teleports and general asset loading on the client). The downside would be allowing people/customers to have the source or bytecode on their machine, which could be problematic if people don't want their UI and/or communications protocols exposed. The transferring the data between the two entities would be problematic, but something like an IM or XML-RPC communications channel wouldn't be too bad. From lenglish5 at cox.net Wed May 7 23:31:41 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed May 7 23:31:43 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> Message-ID: <48229E4D.9090507@cox.net> M[...]atthew Underwood wrote: > > What I really want (as an LSL scripter) is to have the ability to make > localized HUDs (like Vendetta Online and WoW, which use LUA) as it > doesn't really make sense to do all of the processing on the server > (as it is incredibly slow to update, particularly during teleports and > general asset loading on the client). The downside would be allowing > people/customers to have the source or bytecode on their machine, > which could be problematic if people don't want their UI and/or > communications protocols exposed. The transferring the data between > the two entities would be problematic, but something like an IM or > XML-RPC communications channel wouldn't be too bad. > > Well, please not XML-RPC, and while the current HUD browser (tutorial menu item in the RC) still probably isn't what you need, an interactive HUD browser that can handle flash or even SVG (especially as found in the HUD inventory) would go a long way towards making your dreams come true. Lawson From sakkaku at gmail.com Wed May 7 23:59:25 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Wed May 7 23:59:27 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <48229E4D.9090507@cox.net> References: <4818F526.8030704@lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> <48229E4D.9090507@cox.net> Message-ID: <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> On Thu, May 8, 2008 at 2:31 AM, Lawson English wrote: > M[...]atthew Underwood wrote: >> >> What I really want (as an LSL scripter) is to have the ability to make >> localized HUDs (like Vendetta Online and WoW, which use LUA) as it >> doesn't really make sense to do all of the processing on the server >> (as it is incredibly slow to update, particularly during teleports and >> general asset loading on the client). The downside would be allowing >> people/customers to have the source or bytecode on their machine, >> which could be problematic if people don't want their UI and/or >> communications protocols exposed. The transferring the data between >> the two entities would be problematic, but something like an IM or >> XML-RPC communications channel wouldn't be too bad. >> >> > > Well, please not XML-RPC, and while the current HUD browser (tutorial menu > item in the RC) still probably isn't what you need, an interactive HUD > browser that can handle flash or even SVG (especially as found in the HUD > inventory) would go a long way towards making your dreams come true. > > Lawson > While that would solve some issues, in the end that will be using Email and/or XML-RPC so nothing is really solved. In most cases that would be actually slower then using an LSL object in world due to the delay and increases the complexity immensely (some form of authentication, user registration, tracking object/communication keys, variables, etc). While for simple items without dealing with the actual object interaction that would be a major boon. From kamilion at gmail.com Thu May 8 02:08:20 2008 From: kamilion at gmail.com (Kamilion) Date: Thu May 8 02:08:25 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> References: <4818F526.8030704@lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> <48229E4D.9090507@cox.net> <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> Message-ID: On Wed, May 7, 2008 at 11:59 PM, Matthew Underwood wrote: > On Thu, May 8, 2008 at 2:31 AM, Lawson English wrote: > > Matthew Underwood wrote: > > > What I really want (as an LSL scripter) is to have the ability to make > > > localized HUDs (like Vendetta Online and WoW, which use LUA) as it > > > doesn't really make sense to do all of the processing on the server > > > (as it is incredibly slow to update, particularly during teleports and > > > general asset loading on the client). The downside would be allowing > > > people/customers to have the source or bytecode on their machine, > > > which could be problematic if people don't want their UI and/or > > > communications protocols exposed. The transferring the data between > > > the two entities would be problematic, but something like an IM or > > > XML-RPC communications channel wouldn't be too bad. > > > > Well, please not XML-RPC, and while the current HUD browser (tutorial menu > > item in the RC) still probably isn't what you need, an interactive HUD > > browser that can handle flash or even SVG (especially as found in the HUD > > inventory) would go a long way towards making your dreams come true. > > > > Lawson > > While that would solve some issues, in the end that will be using > Email and/or XML-RPC so nothing is really solved. In most cases that > would be actually slower then using an LSL object in world due to the > delay and increases the complexity immensely (some form of > authentication, user registration, tracking object/communication keys, > variables, etc). While for simple items without dealing with the > actual object interaction that would be a major boon. Seems like this would be a perfect time to point out: http://wiki.secondlife.com/wiki/LSL_http_server http://jira.secondlife.com/browse/SVC-1086 http://jira.secondlife.com/browse/SVC-913 By embedding a HTTP server within a LSL script, you'd get around most of the problems of a clientside UI/HUD with a RESTful or SOAPy interface. With that, there'd be no need for llEmail or the choke-pointed XML:RPC servers. Most of the authenication bits are covered with security-by-obscurity by the format of the URLS: calling llRequestHTTPServerURL() gives you https://sim123.agni.lindenlab.com/cap/f23b4b94-012d-44f2-bd0c-16c328321221 which you can choose to either reuse, or call llClearHTTPServerURL() and tear down the old server UUID and then llRequestHTTPServerURL() for a new, fresh URL. 128-bit keyspace is large enough so 'keyscanning'/portscanning would be extremely prohibitive. -- Kamilion "Never feel stupid for asking questions, feel stupid for ignoring answers." From open at autistici.org Thu May 8 03:14:51 2008 From: open at autistici.org (Opensource Obscure) Date: Thu May 8 03:15:54 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) Message-ID: On Wed, 7 May 2008 15:54:11 -0700, "Dahlia Trimble" wrote: > Would the onrez viewer be an example where the submission agreement would > be > applicable instead of GPL? > > Also, I vaguely recall hearing complaints that the OnRez viewer was > similar > to the linden viewer with a notable exception that content creation tools > were obfuscated. If true it would seem to me to be somewhat antithetical > to > the spirit behind GPL. The OnRez viewer also features a "Back" button, a simple yet useful feature to get back to your previous location. Unfortunately this feature still isn't in the official LL client. Also, there are no sources of OnRez viewer and ESC doesn't make a Linux release, so that I can't use the OnRez viewer because I'm on Linux. Opensource Obscure http://friendfeed.com/oobscure From overtake at keynet.com.br Thu May 8 03:22:58 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Thu May 8 03:37:58 2008 Subject: [sldev] Rotation References: <547504.35454.qm@web57910.mail.re3.yahoo.com> Message-ID: <006c01c8b0f7$8b257e40$6e00a8c0@eaurouge> Hi Paul Ah, I also thought that at first... then learned it isn?t easy at all (: Welcome to the quaternion world. Check here: http://wiki.secondlife.com/wiki/Rotation {}Overtake ----- Original Message ----- From: Ratnadeep Paul To: sldev@lists.secondlife.com Sent: Wednesday, May 07, 2008 9:52 PM Subject: [sldev] Rotation Hi All I am a pretty new user to Linden Scripting. I have a specific problem. I need to rotate an object using scripts. My task is to rotate the prim about Y-axis, X-axis and Z-axis in that order plus I would like to rotate each time about the global axes and not the local axes. Can somebody help me? I know it must be very simple but I would like some push or hint in a general direction. Any help is welcome. Regards Paul ------------------------------------------------------------------------------ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ------------------------------------------------------------------------------ _______________________________________________ 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/20080508/330736af/attachment-0001.htm From GordonWendt at gmail.com Thu May 8 04:10:46 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu May 8 04:10:49 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: Message-ID: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> As far as I'm concerned LL already has betrayed the trust of their contributors the moment they decided to downline license rights to the viewer essentially making that version that they licensed out closed source even though it was based off open source contributions and as of yet nothing has been gotten back by the contributors by LL's selling out. Rob, you have to admit that it's quite hypocritical that LL expects it's contributors to give up most of the rights to their contributions without condition when LL is unwilling to do the same in case they "change their mind" especially since once you sign the contribution agreement (an act I have not taken and most likely never will) a contributor has his/her hands tied. -G.W. P-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 .S -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD4DBQFIIt++qJF30JM0FpARAt2rAJi3oh2sAjc4c8otavnwQ24QHzFTAJ0eq1MT S9vq8QjeghYwggXakLRjgQ== =TqN5 -----END PGP SIGNATURE----- . Richard if you haven't already I suggest you go back into this list's archives to read into the background of the "re-licensing" of the source code to the "Electric Sheep Company". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080508/9f256ded/attachment.htm From GordonWendt at gmail.com Thu May 8 04:12:15 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu May 8 04:12:18 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> References: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> Message-ID: <493033a70805080412u27a28dc2ie24542a4ff2d626d@mail.gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ignore that previous signature, it was broken by the formatting of my message (let that be a lesson to always use preview) I will sign this message and double check that the pgp key comes out correctly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFIIuAQqJF30JM0FpARAoSwAJsFfGNF1PjlpuTm9iLt1ZssWjSPywCeIcU1 klHCdwCHEr0+JDGd/Mex9HY= =zw+B -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080508/f837ec45/attachment.htm From DrScofield at xyzzyxyzzy.net Thu May 8 04:25:22 2008 From: DrScofield at xyzzyxyzzy.net (Dr Scofield) Date: Thu May 8 04:25:27 2008 Subject: [sldev] vivox.com hard-coded in viewer? In-Reply-To: <47FF8BBE.2000705@watson.ibm.com> References: <1207906958.22021.53.camel@localhost.localdomain> <47FF8BBE.2000705@watson.ibm.com> Message-ID: <4822E322.5060806@xyzzyxyzzy.net> Mike Monkowski wrote: > I'm not exactly sure what you're looking for, but there is this > > VivoxDebugServerName > bhd.vivox.com > Hostname of the vivox account server to use for voice when not > connected to Agni. it would be good if the SLVoice.exe would use the information from ProvisionVoiceAcccount instead of using something hard coded... cheers dr scofield -- dr dirk husemann, mathmatics and computer science, ibm zurich research lab SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ From tofu.linden at lindenlab.com Thu May 8 05:15:25 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu May 8 05:15:04 2008 Subject: [sldev] library versions. =P In-Reply-To: <4821E43B.8050800@speakeasy.net> References: <4821E43B.8050800@speakeasy.net> Message-ID: <4822EEDD.3000100@lindenlab.com> Alan Grimes wrote: > 2008-05-07T17:16:35Z INFO: ll_try_gtk_init: - Compiled against GTK > version 2.4.14 > 2008-05-07T17:16:35Z INFO: ll_try_gtk_init: - Running against GTK > version 2.12.9 > 2008-05-07T17:16:35Z INFO: createContext: Compiled against SDL 1.2.5 > 2008-05-07T17:16:35Z INFO: createContext: Running against SDL 1.2.13 What is the question/problem? From secret.argent at gmail.com Thu May 8 05:56:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu May 8 05:56:12 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> Message-ID: <432AFC7D-7365-4014-80F4-6D54A1463C8F@gmail.com> > The downside would be allowing > people/customers to have the source or bytecode on their machine, > which could be problematic if people don't want their UI and/or > communications protocols exposed. Yeh, that's proven to be such a bad deal for Google. :p From secret.argent at gmail.com Thu May 8 06:23:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu May 8 06:22:47 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> References: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> Message-ID: On 2008-05-08, at 06:10, Gordon Wendt wrote: > As far as I'm concerned LL already has betrayed the trust of their > contributors the moment they decided to downline license rights to > the viewer essentially making that version that they licensed out > closed source even though it was based off open source > contributions and as of yet nothing has been gotten back by the > contributors by LL's selling out. How do you feel about Trolltech's dual license? What if LL did what Trolltech has done, and agree to BSDL (or equivalent) the SL viewer if they quit supporting it? From secret.argent at gmail.com Thu May 8 06:20:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu May 8 06:24:06 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: Message-ID: <81C560E3-5F36-4EBE-BFD2-850C8FE1BFB3@gmail.com> On 2008-05-08, at 05:14, Opensource Obscure wrote: > The OnRez viewer also features a "Back" button, a simple yet useful > feature to get back to your previous location. Was that feature implemented from an open source contribution? > Unfortunately this feature still isn't in the official LL client. The official client gives you a history of all the places you teleport from as links in chat that you can use to bring up a map and go back to the previous location. From labrat.hb at gmail.com Thu May 8 09:25:29 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu May 8 09:25:33 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <81C560E3-5F36-4EBE-BFD2-850C8FE1BFB3@gmail.com> References: <81C560E3-5F36-4EBE-BFD2-850C8FE1BFB3@gmail.com> Message-ID: This arguement about the contribution agreement is getting kinda stupid at this point. If you don't want to sign it then don't, just don't bitch because LL isn't accepting your patches. I've done some writing in the past and submitted things to be published in magazines, the LL contribution agreement isn't much different then the contract you would have to sign with a magazine publisher when they publish an article you wrote. Depending on the publisher they will ask for various "rights", you yourself retain full rights to your work. And the publisher gets the rights they specified. Generally that would be the "North American Distribution Rights" That's exactly what the Contribution Agreement with Linden Lab is. You are giving them rights to the code you submit, but you are not giving up any rights you have over that code. You can publish it, give it away, use it in your own programs, whatever you want. All the complaints boil down to one thing: "Oh noes... Linden Lab may make money from licensing a closed source viewer that used my contribution" As of right now we know of exactly one closed source license deal that LL has made. And I'm pretty sure they didn't get metric tons of cash for that license. Honestly they probably made more from selling 10 private islands then they got from ESC for the license. From lenglish5 at cox.net Thu May 8 09:57:44 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu May 8 09:57:47 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> References: <4818F526.8030704@lindenlab.com> <5F2227B2-1BC7-4ADF-B251-126CAB5C75E5@gmail.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> <48229E4D.9090507@cox.net> <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> Message-ID: <48233108.8020607@cox.net> Matthew Underwood wrote: > On Thu, May 8, 2008 at 2:31 AM, Lawson English wrote: > >> M[...]atthew Underwood wrote: >> >>> What I really want (as an LSL scripter) is to have the ability to make >>> localized HUDs (like Vendetta Online and WoW, which use LUA) as it >>> doesn't really make sense to do all of the processing on the server >>> (as it is incredibly slow to update, particularly during teleports and >>> general asset loading on the client). The downside would be allowing >>> people/customers to have the source or bytecode on their machine, >>> which could be problematic if people don't want their UI and/or >>> communications protocols exposed. The transferring the data between >>> the two entities would be problematic, but something like an IM or >>> XML-RPC communications channel wouldn't be too bad. >>> >>> >>> >> Well, please not XML-RPC, and while the current HUD browser (tutorial menu >> item in the RC) still probably isn't what you need, an interactive HUD >> browser that can handle flash or even SVG (especially as found in the HUD >> inventory) would go a long way towards making your dreams come true. >> >> Lawson >> >> > > While that would solve some issues, in the end that will be using > Email and/or XML-RPC so nothing is really solved. In most cases that > would be actually slower then using an LSL object in world due to the > delay and increases the complexity immensely (some form of > authentication, user registration, tracking object/communication keys, > variables, etc). While for simple items without dealing with the > actual object interaction that would be a major boon. > Well, no. The llMiniBrowserCreate call will allow HUDs to display a webpage specified via the LSL call in the client's HUDbrowser window and receive feedback via a chat channel. The current tutorial is a non-interactive example of the interface in the client. http://wiki.secondlife.com/wiki/LSL_Browser_HUD Lawson From sakkaku at gmail.com Thu May 8 10:21:03 2008 From: sakkaku at gmail.com (Matthew Underwood) Date: Thu May 8 10:21:05 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <48233108.8020607@cox.net> References: <4818F526.8030704@lindenlab.com> <481A0A00.6000909@lindenlab.com> <481A40FC.1080406@streamsense.net> <1209696260.12336.23.camel@localhost> <481B3172.4080702@watson.ibm.com> <48226B3D.2080303@cox.net> <79e704e0805072055x17812f82xca1aa68566f2f176@mail.gmail.com> <48229E4D.9090507@cox.net> <79e704e0805072359y849c833v8c532e88dd7d0d2@mail.gmail.com> <48233108.8020607@cox.net> Message-ID: <79e704e0805081021w634b9964tffdc73ad6a5db85b@mail.gmail.com> On Thu, May 8, 2008 at 12:57 PM, Lawson English wrote: > Matthew Underwood wrote: >> >> On Thu, May 8, 2008 at 2:31 AM, Lawson English wrote: >> >>> >>> M[...]atthew Underwood wrote: >>> >>>> >>>> What I really want (as an LSL scripter) is to have the ability to make >>>> localized HUDs (like Vendetta Online and WoW, which use LUA) as it >>>> doesn't really make sense to do all of the processing on the server >>>> (as it is incredibly slow to update, particularly during teleports and >>>> general asset loading on the client). The downside would be allowing >>>> people/customers to have the source or bytecode on their machine, >>>> which could be problematic if people don't want their UI and/or >>>> communications protocols exposed. The transferring the data between >>>> the two entities would be problematic, but something like an IM or >>>> XML-RPC communications channel wouldn't be too bad. >>>> >>>> >>>> >>> >>> Well, please not XML-RPC, and while the current HUD browser (tutorial >>> menu >>> item in the RC) still probably isn't what you need, an interactive HUD >>> browser that can handle flash or even SVG (especially as found in the >>> HUD >>> inventory) would go a long way towards making your dreams come true. >>> >>> Lawson >>> >>> >> >> While that would solve some issues, in the end that will be using >> Email and/or XML-RPC so nothing is really solved. In most cases that >> would be actually slower then using an LSL object in world due to the >> delay and increases the complexity immensely (some form of >> authentication, user registration, tracking object/communication keys, >> variables, etc). While for simple items without dealing with the >> actual object interaction that would be a major boon. >> > > Well, no. The llMiniBrowserCreate call will allow HUDs to display a webpage > specified via the LSL call in the client's HUDbrowser window and receive > feedback via a chat channel. The current tutorial is a non-interactive > example of the interface in the client. > > http://wiki.secondlife.com/wiki/LSL_Browser_HUD > > Lawson Interesting, from the description I am assuming that the clicked links will be passed back on the channel. So you could parse the return and decide whether to update the page, execute a command, etc. I just hope they don't make it one per agent, that could degrade into an ugly competition between attachments. From Harleen at comcast.net Wed May 7 06:29:33 2008 From: Harleen at comcast.net (Harleen Gretzky) Date: Thu May 8 12:05:07 2008 Subject: [sldev] Thoughts regarding "OS X Panther support" References: <001a01c8af31$4f62c330$a400000a@gwsystems2.com><1210116599.31741.5.camel@localhost> <65F500CC-94CC-40BD-9817-B694934FF3C7@gmail.com> Message-ID: <2B31FE0E03244F49BF0859F28BBE89EF@Serenity> Another problem with supporting Windows 2000 and other older O/S, is that other companies such as Apple have stopped supporting it, which causes issues like http://jira.secondlife.com/browse/VWR-5198 that leaves Windows 2000 users vulnerable to bugs and exploits in plugins like Quicktime. -------------------------------------------------- From: "Argent Stonecutter" Sent: Wednesday, May 07, 2008 6:33 AM To: "SL-Dev Mailing List" Subject: Re: [sldev] Thoughts regarding "OS X Panther support" > On 2008-05-06, at 18:29, Callum Lerwick wrote: >> Seriously people, upgrade already. Sheesh. > > > Ah, right, if you're lucky or you use an illicit key you might not > trigger the time-bomb in XP. > > If I did something like what Microsoft is doing, as a contractor, I'd be > out on my ass. > > No way in hell will I risk upgrading to a version with code like that in > it. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gwardell at gwsystemsdns.net Thu May 8 14:44:10 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Thu May 8 14:44:15 2008 Subject: [sldev] Windows 2000 - was: Thoughts regarding "OS X Panther support" In-Reply-To: <2B31FE0E03244F49BF0859F28BBE89EF@Serenity> Message-ID: <00af01c8b154$a6dc8c20$a400000a@gwsystems2.com> Hi, According to Microsoft extended support for Windows 2000 runs through 7/13/2010. And Extended Support includes Security Updates. So as I read this us Win2K users are covered for security issues through the first half of 2010. However, most security issues in Win2K are already fixed since it's a fairly mature product. Gary http://support.microsoft.com/lifecycle/?LN=en-us&x=9&y=10&p1=3071 http://support.microsoft.com/gp/lifepolicy > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of > Harleen Gretzky > Sent: Wed, May 07, 2008 9:30 AM > To: SL-Dev Mailing List > Subject: Re: [sldev] Thoughts regarding "OS X Panther support" > > > Another problem with supporting Windows 2000 and other older > O/S, is that > other companies such as Apple have stopped supporting it, > which causes > issues like http://jira.secondlife.com/browse/VWR-5198 that > leaves Windows > 2000 users vulnerable to bugs and exploits in plugins like Quicktime. > > -------------------------------------------------- > From: "Argent Stonecutter" > Sent: Wednesday, May 07, 2008 6:33 AM > To: "SL-Dev Mailing List" > Subject: Re: [sldev] Thoughts regarding "OS X Panther support" > > > On 2008-05-06, at 18:29, Callum Lerwick wrote: > >> Seriously people, upgrade already. Sheesh. > > > > > > Ah, right, if you're lucky or you use an illicit key you might not > > trigger the time-bomb in XP. > > > > If I did something like what Microsoft is doing, as a > contractor, I'd be > > out on my ass. > > > > No way in hell will I risk upgrading to a version with code > like that in > > it. > > > > _______________________________________________ > > 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 rms at gnu.org Thu May 8 15:28:33 2008 From: rms at gnu.org (Richard M Stallman) Date: Thu May 8 15:29:21 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <48221C79.7000408@watson.ibm.com> (message from Mike Monkowski on Wed, 07 May 2008 17:17:45 -0400) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <48221C79.7000408@watson.ibm.com> Message-ID: > Use of this criterion could help convince community developers to > accept the possibility you would stop releasing free versions -- > because it would promise them that all of their code that you ever do > use will be in one of your free versions (and most likely in the last > one). I don't get it. If Linden were to include your criterion and then do the opposite, then developers would hate them, would stop contributing code, and someone may sue. The possibility of getting sued makes it quite unlikely Linden will do that. My point is that that some people might be comfortable contributing because they see it is quite unlikely Linden will do that. From rms at gnu.org Thu May 8 15:28:37 2008 From: rms at gnu.org (Richard M Stallman) Date: Thu May 8 15:29:26 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <482225E1.70205@cox.net> (message from Lawson English on Wed, 07 May 2008 14:57:53 -0700) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: I think this is where I was (perhaps am) confused. As far as I know, the commercial license that Electric Sheep has to produce the onrez SL viewer for use by CSI-NY allows them to use any GPLed components of the LL GPLed viewer that they like. The sticking point, and it just may be I'm not reading things well, is that they decided to deliberately cripple the functionality of their viewer in order to make it more CSI:NY-audience-friendly. The really bad problem case, as it seems to me, is where Linden Labs releases code, for non-free software, that has MORE features than the free version from Linden Labs. In this case, the non-free version has LESS features. I don't think of such cases as a reason to refuse to contribute. From tateru.nino at gmail.com Thu May 8 15:52:36 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu May 8 15:58:11 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> References: <493033a70805080410h1b30f721xb3d007106832809a@mail.gmail.com> Message-ID: <48238434.1070703@gmail.com> Most (admittedly not all) of the not-in-the-standard-viewer features in the OnRez client were released as source code, as I recall. I don't know if they were released to Linden Lab with contribution agreements, though. If not, then you could certainly use that code - but Linden Lab couldn't practically incorporate it into their tree. Anyway, there was code released, as I recall, and it was on this list. Gordon Wendt wrote: > As far as I'm concerned LL already has betrayed the trust of their contributors the moment they decided to downline license rights to the viewer essentially making that version that they licensed out closed source even though it was based off open source contributions and as of yet nothing has been gotten back by the contributors by LL's selling out. > > Rob, you have to admit that it's quite hypocritical that LL expects it's contributors to give up most of the rights to their contributions without condition when LL is unwilling to do the same in case they "change their mind" especially since once you sign the contribution agreement (an act I have not taken and most likely never will) a contributor has his/her hands tied. > > -G.W. > > P -- Tateru Nino http://www.massively.com/ From josh at lindenlab.com Thu May 8 17:15:27 2008 From: josh at lindenlab.com (Joshua Bell) Date: Thu May 8 17:13:31 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <1210147663.31741.109.camel@localhost> References: <481F7279.809@watson.ibm.com> <1210147663.31741.109.camel@localhost> Message-ID: <4823979F.40405@lindenlab.com> Callum Lerwick wrote: > On Mon, 2008-05-05 at 19:51 -0500, Dale Mahalko wrote: > >> An interesting approach, doing all rendering on a remote server and >> just streaming 2D video to the client. >> > > I've run the client over VNC before... :) > It even works on some seriously low-powered hardware: http://www.calormen.com/vnIIc Joshua ;-) (Disclaimers: This was an "art project", with no serious use intended. The name "vnIIc" is a play on the names, not intended to imply protocol compatibility. And there is nothing SL-specific about it, except it was FUN. FYI it has advanced beyond the capabilities shown in the video - keystrokes are now transmitted from the client and can be used to drive apps on the server; mouse and joystick support is also coded but I need to tweak the protocol a bit to make it fully functional.) From lenglish5 at cox.net Thu May 8 17:28:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu May 8 17:28:59 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> Message-ID: <48239AC9.1020108@cox.net> Richard M Stallman wrote: > I think this is where I was (perhaps am) confused. As far as I know, the > commercial license that Electric Sheep has to produce the onrez SL > viewer for use by CSI-NY allows them to use any GPLed components of the > LL GPLed viewer that they like. The sticking point, and it just may be > I'm not reading things well, is that they decided to deliberately > cripple the functionality of their viewer in order to make it more > CSI:NY-audience-friendly. > > The really bad problem case, as it seems to me, is where Linden Labs > releases code, for non-free software, that has MORE features than the > free version from Linden Labs. > > In this case, the non-free version has LESS features. > > I don't think of such cases as a reason to refuse to contribute. > > I guess what I'm trying to clarify is: as long as the original code base that Linden Lab issues a non-free (in your sense) license for is identical in features to the libre version, is it an issue if the licensee adds to or subtracts from that code base for their non-libre licensed software? The original code that LL licensed is identical WHEN the 3rd party receives it, and they add or delete features in-house and sell or give away their compiled version that consists of the non-libre code with missing features and/or new features. In other words, originally it was identical, but by the time it was released, it was not. Does it matter from your perspective if features were added/taken-away by the licensee as long as LL provided the licensee with non-libre source code with features identical to the libre source code? Lawson From sempuki1 at gmail.com Thu May 8 18:12:42 2008 From: sempuki1 at gmail.com (Ryan McDougall) Date: Thu May 8 18:12:48 2008 Subject: [sldev] vivox.com hard-coded in viewer? In-Reply-To: <4822E322.5060806@xyzzyxyzzy.net> References: <1207906958.22021.53.camel@localhost.localdomain> <47FF8BBE.2000705@watson.ibm.com> <4822E322.5060806@xyzzyxyzzy.net> Message-ID: <1210295562.3781.26.camel@localhost.localdomain> On Thu, 2008-05-08 at 13:25 +0200, Dr Scofield wrote: > Mike Monkowski wrote: > > I'm not exactly sure what you're looking for, but there is this > > > > VivoxDebugServerName > > bhd.vivox.com > > Hostname of the vivox account server to use for voice when not > > connected to Agni. > it would be good if the SLVoice.exe would use the information from > ProvisionVoiceAcccount instead of using something hard coded... > > cheers > dr scofield > Yeah we just ignore the AccountManagementServer in the Connector. Have no idea what it is, and as Dr. Scofield has pointed out, its entirely unnecessary. //.. https://www.bhr.vivox.com/api2/ //.. Cheers, From carjay at gmx.net Thu May 8 18:31:33 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu May 8 18:31:41 2008 Subject: [sldev] iPhone/iPod Touch as a Second Life I/O device In-Reply-To: <4823979F.40405@lindenlab.com> References: <481F7279.809@watson.ibm.com> <1210147663.31741.109.camel@localhost> <4823979F.40405@lindenlab.com> Message-ID: <4823A975.9010005@gmx.net> Joshua Bell wrote: > It even works on some seriously low-powered hardware: > http://www.calormen.com/vnIIc :) awesome idea Regards, Carsten From rms at gnu.org Sat May 10 01:55:35 2008 From: rms at gnu.org (Richard M Stallman) Date: Sat May 10 01:56:30 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <48239AC9.1020108@cox.net> (message from Lawson English on Thu, 08 May 2008 17:28:57 -0700) References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> <482131E4.4040508@lindenlab.com> <482225E1.70205@cox.net> <48239AC9.1020108@cox.net> Message-ID: as long as the original code base that Linden Lab issues a non-free (in your sense) license for is identical in features to the libre version, is it an issue if the licensee adds to or subtracts from that code base for their non-libre licensed software? For the most part, I think that is NOT an issue. Here's my basis for looking at these issues. Suppose that the program were released under the Revised BSD license. That is free software, thus basically ethical. It would allow anyone at all to make modified proprietary versions, and they wouldn't even have to pay Linden Labs. But I don't think it is wrong to contribute to that program if I am confident its developers will continue to release it under the same Revised BSD license. If a scenario for this licensing scheme is no worse than that scenario, then I don't see a it as a reason to refuse to contribute. I designed my suggestion on this basis. From kaleajinkya at gmail.com Sat May 10 10:09:48 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sat May 10 10:09:51 2008 Subject: [sldev] Serial port data Message-ID: hello, How can I poll and get serial port data in SL chat bar ? I am using viewer source on windows system .... Any suggestions ? -- Regards, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080510/556c4818/attachment.htm From kaleajinkya at gmail.com Sat May 10 22:29:22 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sat May 10 22:29:24 2008 Subject: [sldev] Serial port errors Message-ID: In the idle() function of llappviewer.cpp I did the following to continuously poll serial port data : void LLAppViewer::idle() { LLSD info; LPWSTR portSerial = new WCHAR[MAX_PATH]; //Get_Version_Str(info); info["COM1"] = ll_convert_wide_to_string(portSerial); HANDLE hSerial; hSerial = CreateFile(portSerial,GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); if(hSerial==INVALID_HANDLE_VALUE) { if(GetLastError()==ERROR_FILE_NOT_FOUND) { llinfos << "SERIAL PORT : Serial port does not exist" << llendl; } llinfos << "SERIAL PORT : we had an unknown error " << llendl; } DCB dcbSerialParams = {0}; if (!GetCommState(hSerial, &dcbSerialParams)) { llinfos << "SERIAL PORT : error getting serial port state " << llendl; } dcbSerialParams.BaudRate=CBR_19200; dcbSerialParams.ByteSize=8; dcbSerialParams.StopBits=ONESTOPBIT; dcbSerialParams.Parity=NOPARITY; if(!SetCommState(hSerial, &dcbSerialParams)) { llinfos << "SERIAL PORT : something went wrong with setting the serial port state. " << llendl; } COMMTIMEOUTS timeouts={0}; timeouts.ReadIntervalTimeout=50; timeouts.ReadTotalTimeoutConstant=50; timeouts.ReadTotalTimeoutMultiplier=10; timeouts.WriteTotalTimeoutConstant=50; timeouts.WriteTotalTimeoutMultiplier=10; if(!SetCommTimeouts(hSerial, &timeouts)) { llinfos << "SERIAL PORT : there was a problem setting the timeouts " << llendl; } char sBuff[2] = {0}; DWORD dwBytesRead = 0; if(!ReadFile(hSerial, sBuff, 1, &dwBytesRead, NULL)) { llinfos << "SERIAL PORT : error reading file" << llendl; } else { llinfos << sBuff << llendl; } CloseHandle(hSerial); -------------------------------------------------------------------------------------------------------------------------------------- When the viewer starts I get the following errors in the idle loop : INFO: LLAppViewer::idle: SERIAL PORT : we had an unknown error INFO: LLAppViewer::idle: SERIAL PORT : error getting serial port state INFO: LLAppViewer::idle: SERIAL PORT : something went wrong with setting the serial port state. INFO: LLAppViewer::idle: SERIAL PORT : there was a problem setting the timeouts INFO: LLAppViewer::idle: SERIAL PORT : error reading file Any suggestion ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080510/cb28f547/attachment.htm From robin.cornelius at gmail.com Sun May 11 00:36:10 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun May 11 00:36:15 2008 Subject: [sldev] Serial port errors In-Reply-To: References: Message-ID: <4826A1EA.4050206@gmail.com> Ajinkya Kale wrote: > In the idle() function of llappviewer.cpp I did the following to > continuously poll serial port data : Um, why are you doing a create file in the idle() loop? Open and initalise everything outside idle during startup somewhere and stash the device handle. Only in idle read the port, watch those timeouts they will stall the viewer. May be better creating a readthread and letting the serial poll as it needs to and fill a buffer, then in idle see if the buffer has data, then you get non blocking IO, as you really don't want any additional delays in idle(). Then at app close again out side idle clean up and close your port. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080511/c77d82b0/signature.pgp From carjay at gmx.net Sun May 11 03:35:00 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun May 11 03:35:05 2008 Subject: [sldev] Serial port errors In-Reply-To: References: Message-ID: <4826CBD4.1060104@gmx.net> Ajinkya Kale wrote: > void LLAppViewer::idle() > { > LLSD info; > LPWSTR portSerial = new WCHAR[MAX_PATH]; > > //Get_Version_Str(info); > > info["COM1"] = ll_convert_wide_to_string(portSerial); > > HANDLE hSerial; > hSerial = > CreateFile(portSerial,GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); The way it is quoted, portSerial is never initialized, so CreateFile will receive some garbage characters as the device name to open. Apart from that, like Robin said you cannot use a blocking call in idle() since it will stall the viewer. Either use overlapped I/O or create a different thread. What do you want to use this for? Regards, Carsten From kaleajinkya at gmail.com Sun May 11 03:40:06 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun May 11 03:40:09 2008 Subject: [sldev] Serial port errors In-Reply-To: <4826CBD4.1060104@gmx.net> References: <4826CBD4.1060104@gmx.net> Message-ID: In which function can I poll for serial port data in the SL source code. I want to poll for data only when the user is logged in so that I can write the serial port data to the chat bar. On Sun, May 11, 2008 at 3:35 AM, Carsten Juttner wrote: > Ajinkya Kale wrote: > >> void LLAppViewer::idle() >> { >> LLSD info; >> LPWSTR portSerial = new WCHAR[MAX_PATH]; >> >> //Get_Version_Str(info); >> >> info["COM1"] = ll_convert_wide_to_string(portSerial); >> >> HANDLE hSerial; >> hSerial = >> CreateFile(portSerial,GENERIC_READ|GENERIC_WRITE,0,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); >> > > The way it is quoted, portSerial is never initialized, so CreateFile will > receive some garbage characters as the device name to open. > > Apart from that, like Robin said you cannot use a blocking call in idle() > since it will stall the viewer. Either use overlapped I/O or create a > different thread. > > What do you want to use this for? > > > Regards, > Carsten > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080511/2d54b307/attachment.htm From secret.argent at gmail.com Sun May 11 04:01:28 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun May 11 04:00:49 2008 Subject: [sldev] Serial port errors In-Reply-To: <4826CBD4.1060104@gmx.net> References: <4826CBD4.1060104@gmx.net> Message-ID: <6A73FBD6-B592-46B0-AAB1-1E10B440A804@gmail.com> Not to mention that there's no standard name for "the serial port" (even on DOS), that doesn't appear to be a portable "open" call, and if the call to open the serial port fails you shouldn't even be making the rest of the calls no matter what thread you make it in. From able.whitman at gmail.com Sun May 11 13:32:15 2008 From: able.whitman at gmail.com (Able Whitman) Date: Sun May 11 13:32:17 2008 Subject: [sldev] A patch to address attached lights and particle sources Message-ID: <7b3a84fb0805111332p128571a4v19d36e67d7c22f61@mail.gmail.com> Howdy, It's been a while since I've been active on this list, or in SL in general. Alas, work and (real) life have consumed most of my free time for quite a while now. Mostly I've been lurking here, but I have always enjoyed the interesting and often spirited discussions. Anyhow, I'm trying to slowly get back up to speed with the current state of the viewer, since I haven't taken a serious look at the source since around the time voice was introduced (and boy howdy was THAT a ways back). To that end, rather than try to tackle big new features or major architectural issues, I've tried to do some small, but useful, improvements to the viewer. One of my contributions is VWR-6540: Add options to selectively render attached lights and attached particle sources. (An alternate title might be "Let people turn off bling attachments and facelamps".) This patch adds Advanced menu options to disable particle sources and light sources that emanate from attachments. Attached particle sources can not only be annoying, but they also contribute a lot to the Avatar Rendering Cost, so if bling annoys you or you're in a busy area, turning it off can help reduce visual lag. Attached lamps (usually facelamps) can also be annoying, in that they can interfere with ambient or environmental lights that happen to be part of neaby builds. Mostly this is due to the fact that most people aren't aware that there is a 6-light limit. I see a lot of people with 2 or 3 attached lights (although I've seen some people with 6 lights, and one time as many as 30! attached lights), and as they move around a sim, local stationary lights can flicker on and off depending on your location. The patch is attached to the JIRA issue, so I won't attach it here. It's fairly straightforward; particles aren't drawn if their source object is an attachment, and light sources whose source is an attachment are simply omitted from distance sorting when the viewer selects which ones to render. Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080511/a96496bb/attachment.htm From able.whitman at gmail.com Sun May 11 13:37:21 2008 From: able.whitman at gmail.com (Able Whitman) Date: Sun May 11 13:37:27 2008 Subject: [sldev] A patch to allow creation of megaprims from within the viewer Message-ID: <7b3a84fb0805111337n1c63aa07s5304d427c76416ad@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: megaprim-create.patch.jpg Type: image/jpeg Size: 114757 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080511/769c766f/megaprim-create.patch-0001.jpg -------------- next part -------------- diff -wru -X x.txt linden-orig\/indra/llmath/xform.h linden\/indra/llmath/xform.h --- linden-orig\/indra/llmath/xform.h 2008-04-07 19:45:36.000000000 -0400 +++ linden\/indra/llmath/xform.h 2008-05-10 18:48:15.197000000 -0400 @@ -35,10 +35,10 @@ #include "m4math.h" #include "llquaternion.h" -const F32 MAX_OBJECT_Z = 768.f; +const F32 MAX_OBJECT_Z = 4096.f; const F32 MIN_OBJECT_Z = -256.f; -const F32 MIN_OBJECT_SCALE = 0.01f; -const F32 MAX_OBJECT_SCALE = 10.f; +const F32 MIN_OBJECT_SCALE = 0.0001f; +const F32 MAX_OBJECT_SCALE = 512.f; class LLXform { diff -wru -X x.txt linden-orig\/indra/newview/llcontroldef.cpp linden\/indra/newview/llcontroldef.cpp --- linden-orig\/indra/newview/llcontroldef.cpp 2008-04-07 19:45:42.000000000 -0400 +++ linden\/indra/newview/llcontroldef.cpp 2008-05-11 11:49:41.402000000 -0400 @@ -1582,6 +1586,11 @@ gSavedSettings.declareBOOL("SaveMinidump", TRUE, "Save minidump for developer debugging on crash"); + // default new object scale + gSavedSettings.declareF32("RezNewScaleX", 0.5f, "Default X dimension scale when creating a new prim"); + gSavedSettings.declareF32("RezNewScaleY", 0.5f, "Default Y dimension scale when creating a new prim"); + gSavedSettings.declareF32("RezNewScaleZ", 0.5f, "Default Z dimension scale when creating a new prim"); + // // crash_settings.xml // diff -wru -X x.txt linden-orig\/indra/newview/llfloatertools.cpp linden\/indra/newview/llfloatertools.cpp --- linden-orig\/indra/newview/llfloatertools.cpp 2008-04-07 19:45:42.000000000 -0400 +++ linden\/indra/newview/llfloatertools.cpp 2008-05-11 14:55:05.810000000 -0400 @@ -54,6 +54,7 @@ #include "llpanelvolume.h" #include "llpanelpermissions.h" #include "llselectmgr.h" +#include "llspinctrl.h" #include "llstatusbar.h" #include "lltabcontainer.h" #include "lltextbox.h" @@ -114,6 +115,9 @@ void commit_radio_pan(LLUICtrl *, void*); void commit_grid_mode(LLUICtrl *, void*); void commit_slider_zoom(LLUICtrl *, void*); +void commit_new_x(LLUICtrl *ctrl, void *data); +void commit_new_y(LLUICtrl *ctrl, void *data); +void commit_new_z(LLUICtrl *ctrl, void *data); //static @@ -284,6 +288,21 @@ childSetValue("checkbox copy centers",(BOOL)gSavedSettings.getBOOL("CreateToolCopyCenters")); mCheckCopyRotates = LLUICtrlFactory::getCheckBoxByName(this,"checkbox copy rotates"); childSetValue("checkbox copy rotates",(BOOL)gSavedSettings.getBOOL("CreateToolCopyRotates")); + + mLabelNewSize = LLUICtrlFactory::getTextBoxByName(this, "CreateToolNewSizeLabel"); + + mSpinNewX = LLUICtrlFactory::getSpinnerByName(this, "CreateToolNewX"); + childSetValue("CreateToolNewX", (F32)gSavedSettings.getF32("RezNewScaleX")); + childSetCommitCallback("CreateToolNewX", commit_new_x, mSpinNewX); + + mSpinNewY = LLUICtrlFactory::getSpinnerByName(this, "CreateToolNewY"); + childSetValue("CreateToolNewY", (F32)gSavedSettings.getF32("RezNewScaleY")); + childSetCommitCallback("CreateToolNewY", commit_new_y, mSpinNewY); + + mSpinNewZ = LLUICtrlFactory::getSpinnerByName(this, "CreateToolNewZ"); + childSetValue("CreateToolNewZ", (F32)gSavedSettings.getF32("RezNewScaleZ")); + childSetCommitCallback("CreateToolNewZ", commit_new_z, mSpinNewZ); + mRadioSelectLand = LLUICtrlFactory::getCheckBoxByName(this,"radio select land"); childSetCommitCallback("radio select land",commit_select_tool, gToolParcel); mRadioDozerFlatten = LLUICtrlFactory::getCheckBoxByName(this,"radio flatten"); @@ -373,6 +392,12 @@ mCheckCopySelection(NULL), mCheckCopyCenters(NULL), mCheckCopyRotates(NULL), + + mLabelNewSize(NULL), + mSpinNewX(NULL), + mSpinNewY(NULL), + mSpinNewZ(NULL), + mRadioSelectLand(NULL), mRadioDozerFlatten(NULL), mRadioDozerRaise(NULL), @@ -674,6 +699,11 @@ if (mCheckCopyCenters) mCheckCopyCenters ->setVisible( create_visible ); if (mCheckCopyRotates) mCheckCopyRotates ->setVisible( create_visible ); + if (mLabelNewSize) mLabelNewSize ->setVisible( create_visible ); + if (mSpinNewX) mSpinNewX ->setVisible( create_visible ); + if (mSpinNewY) mSpinNewY ->setVisible( create_visible ); + if (mSpinNewZ) mSpinNewZ ->setVisible( create_visible ); + if (mCheckCopyCenters) mCheckCopyCenters->setEnabled( mCheckCopySelection->get() ); if (mCheckCopyRotates) mCheckCopyRotates->setEnabled( mCheckCopySelection->get() ); @@ -935,6 +965,24 @@ gSavedSettings.setBOOL("ShowParcelOwners", show_owners); } +void commit_new_x(LLUICtrl *ctrl, void *data) +{ + LLSpinCtrl* spin = (LLSpinCtrl*) data; + gSavedSettings.setF32("RezNewScaleX", spin->get()); +} + +void commit_new_y(LLUICtrl *ctrl, void *data) +{ + LLSpinCtrl* spin = (LLSpinCtrl*) data; + gSavedSettings.setF32("RezNewScaleY", spin->get()); +} + +void commit_new_z(LLUICtrl *ctrl, void *data) +{ + LLSpinCtrl* spin = (LLSpinCtrl*) data; + gSavedSettings.setF32("RezNewScaleZ", spin->get()); +} + void commit_select_component(LLUICtrl *ctrl, void *data) { LLFloaterTools* floaterp = (LLFloaterTools*)data; diff -wru -X x.txt linden-orig\/indra/newview/llfloatertools.h linden\/indra/newview/llfloatertools.h --- linden-orig\/indra/newview/llfloatertools.h 2008-04-07 19:45:40.000000000 -0400 +++ linden\/indra/newview/llfloatertools.h 2008-05-11 14:53:12.757000000 -0400 @@ -50,6 +50,7 @@ class LLComboBox; class LLParcelSelection; class LLObjectSelection; +class LLSpinCtrl; typedef LLSafeHandle LLObjectSelectionHandle; @@ -157,6 +158,11 @@ LLCheckBoxCtrl *mCheckCopyCenters; LLCheckBoxCtrl *mCheckCopyRotates; + LLTextBox *mLabelNewSize; + LLSpinCtrl *mSpinNewX; + LLSpinCtrl *mSpinNewY; + LLSpinCtrl *mSpinNewZ; + // Land buttons // LLCheckBoxCtrl *mRadioEditLand; LLCheckBoxCtrl *mRadioSelectLand; diff -wru -X x.txt linden-orig\/indra/newview/lltoolplacer.cpp linden\/indra/newview/lltoolplacer.cpp --- linden-orig\/indra/newview/lltoolplacer.cpp 2008-04-07 19:45:42.000000000 -0400 +++ linden\/indra/newview/lltoolplacer.cpp 2008-05-10 23:04:42.176000000 -0400 @@ -64,8 +64,6 @@ #include "llviewercamera.h" #include "llviewerstats.h" -const LLVector3 DEFAULT_OBJECT_SCALE(0.5f, 0.5f, 0.5f); - //static LLPCode LLToolPlacer::sObjectType = LL_PCODE_CUBE; @@ -182,7 +180,7 @@ // Set params for new object based on its PCode. LLQuaternion rotation; - LLVector3 scale = DEFAULT_OBJECT_SCALE; + LLVector3 scale(gSavedSettings.getF32("RezNewScaleX"), gSavedSettings.getF32("RezNewScaleY"), gSavedSettings.getF32("RezNewScaleZ")); U8 material = LL_MCODE_WOOD; BOOL create_selected = FALSE; LLVolumeParams volume_params; diff -wru -X x.txt linden-orig\/indra/newview/skins/xui/en-us/floater_tools.xml linden\/indra/newview/skins/xui/en-us/floater_tools.xml --- linden-orig\/indra/newview/skins/xui/en-us/floater_tools.xml 2008-04-07 19:45:42.000000000 -0400 +++ linden\/indra/newview/skins/xui/en-us/floater_tools.xml 2008-05-11 14:33:23.043000000 -0400 @@ -208,6 +208,26 @@ image_unselected="object_grass.tga" label="" label_selected="" left_delta="23" mouse_opaque="true" name="ToolGrass" scale_image="TRUE" width="24" /> + + + New Object Size (meters) + + + + +