From tayra.dagostino at gmail.com Sat Aug 1 06:54:11 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 1 Aug 2009 15:54:11 +0200 Subject: [sldev] adult flag in snowglobe Message-ID: <20090801155411.4c7a2d84.tayra.dagostino@gmail.com> cannot find in JIRA a already opened ticket... in 1.1.1 SnowGlobe i see "adult" sims like "mature" (if i log with older viewer i see them as "(unknow)", can somebody tell to me if there is a JIRA about this? From gretzky.harleen at gmail.com Sat Aug 1 07:46:29 2009 From: gretzky.harleen at gmail.com (Harleen Gretzky) Date: Sat, 1 Aug 2009 10:46:29 -0400 Subject: [sldev] adult flag in snowglobe In-Reply-To: <20090801155411.4c7a2d84.tayra.dagostino@gmail.com> References: <20090801155411.4c7a2d84.tayra.dagostino@gmail.com> Message-ID: <5c63fe8c0908010746j5cbcad30i8fa24d4471a1230@mail.gmail.com> It was SNOW-99, the viewer-side has been fixed, but there is a server-side fix needed also. So it has been moved to http://jira.secondlife.com/browse/SVC-4644 On Sat, Aug 1, 2009 at 9:54 AM, Tayra Dagostino wrote: > cannot find in JIRA a already opened ticket... > > in 1.1.1 SnowGlobe i see "adult" sims like "mature" (if i log with > older viewer i see them as "(unknow)", can somebody tell to me if there > is a JIRA about this? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090801/7caa8178/attachment.htm From robla at lindenlab.com Sat Aug 1 10:39:01 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sat, 01 Aug 2009 10:39:01 -0700 Subject: [sldev] Snowglobe RC2 Message-ID: <4A747DB5.6080309@lindenlab.com> Hi folks, Snowglobe RC2 is available from here: http://wiki.secondlife.com/wiki/Snowglobe If you missed RC1, well, that's ok. There really hasn't been any substantial changes over the past couple of days. To see the list, look here: http://svn.secondlife.com/trac/linden/log/projects/2009/snowglobe/1.1?verbose=on The main thing has been updating the about dialog, some copyright strings, and other miscellaneous cleanup. So, barring any unforeseen complications or showstopper regressions from 1.0, this exact build will be put up as the new download for Snowglobe on Monday. Please give this one a spin, and let us know if there's any new bugs. Thanks! Rob From aleric.inglewood at gmail.com Sat Aug 1 10:45:33 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 1 Aug 2009 19:45:33 +0200 Subject: [sldev] How to solve this bug? (OpenAL blocking) In-Reply-To: <4A734C65.40008@lindenlab.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <4A734C65.40008@lindenlab.com> Message-ID: <1e01733d0908011045t3f4761eave03af67bf5a25c7@mail.gmail.com> Hi, I profiled secondlife-bin and it turns out that libopenal is by FAR the largest CPU munger in a single place: Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000 samples cum. samples % cum. % image name symbol name 1235671 1235671 25.4705 25.4705 libopenal.so.1.8.466 aluMixData 435456 1671127 8.9759 34.4464 libGLcore.so.173.14.09 (no symbols) 187716 1858843 3.8693 38.3157 libopenal.so.1.8.466 lpFilter2P 153707 2012550 3.1683 41.4840 libopenal.so.1.8.466 lpFilter4P 96160 2108710 1.9821 43.4662 libcwd_r.so.1.0.0 less::operator()(libcwd::memblk_key_ct const&, libcwd::memblk_key_ct const&) const 95587 2204297 1.9703 45.4365 libcwd_r.so.1.0.0 libcwd::memblk_key_ct::operator<(libcwd::memblk_key_ct) const 89712 2294009 1.8492 47.2857 libcwd_r.so.1.0.0 .plt 77128 2371137 1.5898 48.8755 libopenal.so.1.8.466 CalcSourceParams 76892 2448029 1.5849 50.4604 libstdc++.so.6.0.12 (no symbols) 62967 2510996 1.2979 51.7583 libpthread-2.9.so pthread_mutex_lock Note how aluMixData, the function that I was talking about, eats 25% of all (profile) samples! This was recorded without that the bug happened: the application is able to keep up with the mixing and 'waits' every call, so that the main thread can easily get the lock. Ie, Calls/second: 2757; average time spend: 232 microseconds (63.962400%); average loop count: 31; average playing count: 28; average size: 64, time per loop: 7 microseconds; avail_check: 5341; avail_wait: 2584 where avail_wait (the number of times that data was available so that the application waited for the sound card before calling aluMixData again) is almost equal to the number of calls (per second). From aleric.inglewood at gmail.com Sat Aug 1 10:53:25 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 1 Aug 2009 19:53:25 +0200 Subject: [sldev] How to solve this bug? (OpenAL blocking) In-Reply-To: <1e01733d0908011045t3f4761eave03af67bf5a25c7@mail.gmail.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <4A734C65.40008@lindenlab.com> <1e01733d0908011045t3f4761eave03af67bf5a25c7@mail.gmail.com> Message-ID: <1e01733d0908011053y6341ab22meb12d6cf839c076d@mail.gmail.com> Here is a list with a summary per library: CPU_CLK_UNHALT...| samples| %| ------------------ 4851409 100.000 secondlife-bin CPU_CLK_UNHALT...| samples| %| ------------------ 1767553 36.4338 libopenal.so.1.8.466 1343214 27.6871 secondlife-bin 789953 16.2830 libcwd_r.so.1.0.0 435456 8.9759 libGLcore.so.173.14.09 130706 2.6942 libc-2.9.so 122414 2.5233 libpthread-2.9.so 80000 1.6490 libm-2.9.so 76892 1.5849 libstdc++.so.6.0.12 44566 0.9186 [vdso] (tgid:27957 range:0x7fffd97ff000-0x7fffd9800000) 28766 0.5929 libopenjpeg-2.1.3.0.so 12131 0.2501 libGL.so.173.14.09 5597 0.1154 libfreetype.so.6.3.20 4204 0.0867 zero 2875 0.0593 libasound.so.2.0.0 1764 0.0364 ld-2.9.so 1309 0.0270 libcrypto.so.0.9.8 1309 0.0270 libvorbis.so.0.4.0 782 0.0161 libapr-1.so.0.3.5 329 0.0068 libGLU.so.1.3.070004 257 0.0053 libX11.so.6.2.0 246 0.0051 libogg.so.0.5.3 242 0.0050 libcurl-cares.so.4.1.0 219 0.0045 libSDL-1.2.so.0.11.2 137 0.0028 libglib-2.0.so.0.2000.1 119 0.0025 libvorbisfile.so.3.2.0 84 0.0017 libXext.so.6.4.0 63 0.0013 libdbus-1.so.3.4.0 53 0.0011 libxcb.so.1.1.0 44 9.1e-04 libcares.so.2.0.0 38 7.8e-04 librt-2.9.so 25 5.2e-04 libgtk-x11-2.0.so.0.1600.1 15 3.1e-04 libgdk-x11-2.0.so.0.1600.1 15 3.1e-04 libz.so.1.2.3.3 10 2.1e-04 libssl.so.0.9.8 9 1.9e-04 libdbus-glib-1.so.2.1.0 7 1.4e-04 libalut.so.0.1.0 6 1.2e-04 libgthread-2.0.so.0.2000.1 Note that libcwd_r is a debug library that eats 16% cpu because it keeps track of all memory allications. libopenal is at the very top, even above secondlife-bin itself! Is this really normal? From armin.weatherwax at googlemail.com Sat Aug 1 12:16:51 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sat, 1 Aug 2009 21:16:51 +0200 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim Message-ID: <200908012116.51731.Armin.Weatherwax@gmail.com> Hi, I opened http://jira.secondlife.com/browse/SNOW-157, because of almost no textures show up logging on OpenSim (0.6.5; Debian Lenny). My assumption is that is caused by the change of the TEXTURE_CACHE_ENTRY_SIZE from 600 to 1024 bytes in Changeset 2486. But I'm not actually into the texture cache and also not into whether or not a OpenSim should support this or not. For Snowglobe rocks, it would be great to have it also working on OpenSim. :) Armin From tayra.dagostino at gmail.com Sat Aug 1 12:31:59 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 1 Aug 2009 21:31:59 +0200 Subject: [sldev] Snowglobe RC2 In-Reply-To: <4A747DB5.6080309@lindenlab.com> References: <4A747DB5.6080309@lindenlab.com> Message-ID: <20090801213159.b0574d3d.tayra.dagostino@gmail.com> On Sat, 01 Aug 2009 10:39:01 -0700 Rob Lanphier wrote: > So, barring any unforeseen complications or showstopper regressions > from 1.0, this exact build will be put up as the new download for > Snowglobe on Monday. Please give this one a spin, and let us know if > there's any new bugs. Snowglobe 1.1.2 (2584) Jul 31 2009 18:48:57 (Snowglobe Release) still a lot of: 2009-08-01T19:29:37Z WARNING: LLViewerImage::setIsMissingAsset: 5c1ffa2b-3a33-6cf6-f0b0-cd925ebd5ecc: Marking image as missing texture (both opened from inventory and applied on prims) are marked as MISSING, if i wait few mins (memcache expire) same etxture are marked BAD and removed, after few mins too viewer rezz (but not always) From robla at lindenlab.com Sat Aug 1 12:55:05 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sat, 01 Aug 2009 12:55:05 -0700 Subject: [sldev] Snowglobe RC2 In-Reply-To: <20090801213159.b0574d3d.tayra.dagostino@gmail.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> Message-ID: <4A749D99.2080406@lindenlab.com> On 08/01/2009 12:31 PM, Tayra Dagostino wrote: > On Sat, 01 Aug 2009 10:39:01 -0700 > Rob Lanphier wrote: > > >> So, barring any unforeseen complications or showstopper regressions >> from 1.0, this exact build will be put up as the new download for >> Snowglobe on Monday. Please give this one a spin, and let us know if >> there's any new bugs. >> > > > Snowglobe 1.1.2 (2584) Jul 31 2009 18:48:57 (Snowglobe Release) > > still a lot of: > > 2009-08-01T19:29:37Z WARNING: LLViewerImage::setIsMissingAsset: > 5c1ffa2b-3a33-6cf6-f0b0-cd925ebd5ecc: Marking image as missing > > texture (both opened from inventory and applied on prims) are marked as > MISSING, if i wait few mins (memcache expire) same etxture are marked > BAD and removed, after few mins too viewer rezz (but not always) > Is this new to Snowglobe 1.1, or was this a problem with Snowglobe 1.0? Is there something in the bug tracker for this problem? Rob From tayra.dagostino at gmail.com Sat Aug 1 13:32:16 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 1 Aug 2009 22:32:16 +0200 Subject: [sldev] Snowglobe RC2 In-Reply-To: <4A749D99.2080406@lindenlab.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <4A749D99.2080406@lindenlab.com> Message-ID: <20090801223216.2ec560a9.tayra.dagostino@gmail.com> On Sat, 01 Aug 2009 12:55:05 -0700 Rob Lanphier wrote: > >> So, barring any unforeseen complications or showstopper regressions > >> from 1.0, this exact build will be put up as the new download for > >> Snowglobe on Monday. Please give this one a spin, and let us know > >> if there's any new bugs. > >> > > > > > > Snowglobe 1.1.2 (2584) Jul 31 2009 18:48:57 (Snowglobe Release) > > > > still a lot of: > > > > 2009-08-01T19:29:37Z WARNING: LLViewerImage::setIsMissingAsset: > > 5c1ffa2b-3a33-6cf6-f0b0-cd925ebd5ecc: Marking image as missing > > > > texture (both opened from inventory and applied on prims) are > > marked as MISSING, if i wait few mins (memcache expire) same > > etxture are marked BAD and removed, after few mins too viewer rezz > > (but not always) > > Is this new to Snowglobe 1.1, or was this a problem with Snowglobe > 1.0? Is there something in the bug tracker for this problem? since 1.1.x already sayd few day ago on BSI group chat we (i'm not the only suffer this bug) think is something related to http://jira.secondlife.com/browse/SNOW-59 or http://jira.secondlife.com/browse/SNOW-48 (but not only megaprims) From tayra.dagostino at gmail.com Sat Aug 1 13:54:50 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sat, 1 Aug 2009 22:54:50 +0200 Subject: [sldev] Snowglobe RC2 In-Reply-To: <20090801223216.2ec560a9.tayra.dagostino@gmail.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <4A749D99.2080406@lindenlab.com> <20090801223216.2ec560a9.tayra.dagostino@gmail.com> Message-ID: <20090801225450.1cdfdc48.tayra.dagostino@gmail.com> On Sat, 1 Aug 2009 22:32:16 +0200 Tayra Dagostino wrote: > we (i'm not the only suffer this bug) think is something related to > http://jira.secondlife.com/browse/SNOW-59 or > http://jira.secondlife.com/browse/SNOW-48 (but not only megaprims) same texture first open from inventory: 2009-08-01T20:37:08Z WARNING: LLViewerImage::setIsMissingAsset: 3e5faf4c-ce45-f2b0-50df-83aa747d9d91: Marking image as missing wait about 5 mins or more and try again: 2009-08-01T20:41:21Z WARNING: setupPacketData: Bad CACHED TEXTURE size: 768 removing. (same texture) cannot rezz texture from inventory....... other time 3rd stepo after 5-6 mins let texture downloaded and decoded.... From blackhat at blackhatdesign.com Sat Aug 1 13:54:44 2009 From: blackhat at blackhatdesign.com (Black Hat Design) Date: Sat, 1 Aug 2009 15:54:44 -0500 Subject: [sldev] Snowglobe RC2 In-Reply-To: <4A749D99.2080406@lindenlab.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <4A749D99.2080406@lindenlab.com> Message-ID: <08ab01ca12ea$4d45d5b0$e7d18110$@com> It's not crashing but SNOW-48 is still an issue. So although the viewer may not crash, a lot of offsim island and ocean wave content is fuzzy and blurry. I'm not sure how long anyone can stand using the viewer very long with that happening. That sort of content is on just about every beach in SL. I love Snowglobe otherwise. This particular issue is the only reason that I don't use it constantly. http://jira.secondlife.com/browse/SNOW-48 Repro SNOW-48 at this location. http://slurl.com/secondlife/Galahad/142/29/22 Dirk Talamasca dirk at dirktalamasca.com Skype: Dirk Talamasca Yahoo: blackhat AIM: Black Hat Design Google: dirktalamasca at gmail.com -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Rob Lanphier Sent: Saturday, August 01, 2009 2:55 PM To: Tayra Dagostino Cc: sldev at lists.secondlife.com Subject: Re: [sldev] Snowglobe RC2 On 08/01/2009 12:31 PM, Tayra Dagostino wrote: > On Sat, 01 Aug 2009 10:39:01 -0700 > Rob Lanphier wrote: > > >> So, barring any unforeseen complications or showstopper regressions >> from 1.0, this exact build will be put up as the new download for >> Snowglobe on Monday. Please give this one a spin, and let us know if >> there's any new bugs. >> > > > Snowglobe 1.1.2 (2584) Jul 31 2009 18:48:57 (Snowglobe Release) > > still a lot of: > > 2009-08-01T19:29:37Z WARNING: LLViewerImage::setIsMissingAsset: > 5c1ffa2b-3a33-6cf6-f0b0-cd925ebd5ecc: Marking image as missing > > texture (both opened from inventory and applied on prims) are marked as > MISSING, if i wait few mins (memcache expire) same etxture are marked > BAD and removed, after few mins too viewer rezz (but not always) > Is this new to Snowglobe 1.1, or was this a problem with Snowglobe 1.0? Is there something in the bug tracker for this problem? Rob _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.34/2268 - Release Date: 08/01/09 09:38:00 From carlo at alinoe.com Sat Aug 1 15:20:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 2 Aug 2009 00:20:55 +0200 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim In-Reply-To: <200908012116.51731.Armin.Weatherwax@gmail.com> References: <200908012116.51731.Armin.Weatherwax@gmail.com> Message-ID: <20090801222055.GA9861@alinoe.com> Confirming this... I haven't been able to go to an opensim grid using snowglobe because of this :/ On Sat, Aug 01, 2009 at 09:16:51PM +0200, Armin Weatherwax wrote: > Hi, > > I opened http://jira.secondlife.com/browse/SNOW-157, because of almost > no textures show up logging on OpenSim (0.6.5; Debian Lenny). -- Carlo Wood From teravus at gmail.com Sat Aug 1 15:21:40 2009 From: teravus at gmail.com (Teravus Ovares) Date: Sat, 1 Aug 2009 18:21:40 -0400 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim In-Reply-To: <200908012116.51731.Armin.Weatherwax@gmail.com> References: <200908012116.51731.Armin.Weatherwax@gmail.com> Message-ID: <34cc66250908011521t7d91dcebvf829c0461c330134@mail.gmail.com> Seems like an interesting change. Is the new first image packet supposed to contain 1024 bytes of texture data instead of 600? My guess is this isn't backwards compatible with the standard viewers also. If the above statements are true, then OpenSimulator won't be able to support it unless there is viewer version tracking in the UDP stack. Currently, it treats all viewers the same regardless of version. I suppose the only place that it can get this information is from the login service as well. Maybe a new part of the AgentCircuit data is warranted to keep this information propagated on sim crossings. Let me know and I'll pass this info on to the opensim-dev e-mail list Regards Teravus On Sat, Aug 1, 2009 at 3:16 PM, Armin Weatherwax wrote: > Hi, > > I opened http://jira.secondlife.com/browse/SNOW-157, because of almost > no textures show up logging on OpenSim (0.6.5; Debian Lenny). > My assumption is that is caused by the change of the > TEXTURE_CACHE_ENTRY_SIZE from 600 to ?1024 bytes in ?Changeset 2486. > But I'm not actually into the texture cache and also not into whether or > not a OpenSim should support this or not. > For Snowglobe rocks, it would be great to have it also working on > OpenSim. > > :) > Armin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From missannotoole at yahoo.com Sat Aug 1 15:54:19 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 1 Aug 2009 15:54:19 -0700 (PDT) Subject: [sldev] Snowglobe RC2 In-Reply-To: <20090801213159.b0574d3d.tayra.dagostino@gmail.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> Message-ID: <36078.49370.qm@web59102.mail.re1.yahoo.com> http://jira.secondlife.com/browse/VWR-12987 is still present in Snowglobe RC2 but for flexible prims only. Anyone else care to confirm? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090801/32ed6913/attachment.htm From tayra.dagostino at gmail.com Sat Aug 1 16:22:22 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Sun, 2 Aug 2009 01:22:22 +0200 Subject: [sldev] Snowglobe RC2 In-Reply-To: <36078.49370.qm@web59102.mail.re1.yahoo.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <36078.49370.qm@web59102.mail.re1.yahoo.com> Message-ID: <20090802012222.d38bbfb5.tayra.dagostino@gmail.com> On Sat, 1 Aug 2009 15:54:19 -0700 (PDT) Ann Otoole wrote: > http://jira.secondlife.com/browse/VWR-12987 is still present in > Snowglobe RC2 but for flexible prims only. Anyone else care to > confirm? i think the fix is client side, take a look at bottom of page, just raise up rendermaxnode and all work (fps performance loss on medium/old pc) From missannotoole at yahoo.com Sat Aug 1 17:12:21 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 1 Aug 2009 17:12:21 -0700 (PDT) Subject: [sldev] Snowglobe RC2 In-Reply-To: <20090802012222.d38bbfb5.tayra.dagostino@gmail.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <36078.49370.qm@web59102.mail.re1.yahoo.com> <20090802012222.d38bbfb5.tayra.dagostino@gmail.com> Message-ID: <770085.39612.qm@web59106.mail.re1.yahoo.com> rendermaxnodesize has nothing to do with this defect. ________________________________ From: Tayra Dagostino To: sldev at lists.secondlife.com Sent: Saturday, August 1, 2009 7:22:22 PM Subject: Re: [sldev] Snowglobe RC2 On Sat, 1 Aug 2009 15:54:19 -0700 (PDT) Ann Otoole wrote: > http://jira.secondlife.com/browse/VWR-12987 is still present in > Snowglobe RC2 but for flexible prims only. Anyone else care to > confirm? i think the fix is client side, take a look at bottom of page, just raise up rendermaxnode and all work (fps performance loss on medium/old pc) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090801/3be346df/attachment-0001.htm From vector at leafpile.com Sun Aug 2 01:03:18 2009 From: vector at leafpile.com (Vector Hastings) Date: Sun, 2 Aug 2009 01:03:18 -0700 Subject: [sldev] Audio Driver Version: (none) In-Reply-To: <770085.39612.qm@web59106.mail.re1.yahoo.com> Message-ID: Remembering that I'm in way over my head... any thoughts on how I'm managing to compile this without invoking the fmod audio drivers? MSVS 2005 Express Cmake fmod pieces are installed as per the wiki in libraries\include, in libraries\i686-wub32\lib\release and lib\debug, and the fmod.dll is in indra\newview. Under Secondlife-bin > properites > Linker > Input > Additional Dependencies, fmodvc.lib is there. The source I'm compiling right now is a combo of 1.23 and snowglobe, but I've had this problem my last build, which was 1.23 with just a wee patch applied. Under help > About, I see: libcurl Version: libcurl/7.19.6-CVS OpenSSL/0.9.8j c-ares/1.6.0 J2C Decoder Version: KDU Audio Driver Version: (none) LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25810 (Mozilla GRE version 1.8.1.21_0000000000) Packets Lost: 0/4407 (0.0%) But when I run a client compiled by someone else, from that same configuration, I get Audio Driver Version: FMOD 3.75 (and the sound works) Thanks for any suggestions, Vector -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090802/8019f630/attachment.htm From tom at streamsense.net Sun Aug 2 01:15:31 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Sun, 02 Aug 2009 09:15:31 +0100 Subject: [sldev] Audio Driver Version: (none) In-Reply-To: References: Message-ID: <4A754B23.3060200@streamsense.net> Did you run develop.py after installing the libraries? ~T Vector Hastings wrote: > Remembering that I'm in way over my head... any thoughts on how I'm > managing to compile this without invoking the fmod audio drivers? > > MSVS 2005 Express > > Cmake > > fmod pieces are installed as per the wiki in libraries\include, in > libraries\i686-wub32\lib\release and lib\debug, and the fmod.dll is in > indra\newview. > > Under Secondlife-bin > properites > Linker > Input > Additional > Dependencies, fmodvc.lib is there. > > The source I'm compiling right now is a combo of 1.23 and snowglobe, > but I've had this problem my last build, which was 1.23 with just a > wee patch applied. > > Under help > About, I see: > > libcurl Version: libcurl/7.19.6-CVS OpenSSL/0.9.8j c-ares/1.6.0 > J2C Decoder Version: KDU > *Audio Driver Version: (none) > *LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25810 (Mozilla GRE > version 1.8.1.21_0000000000) > Packets Lost: 0/4407 (0.0%) > > But when I run a client compiled by someone else, from that same > configuration, I get Audio Driver Version: FMOD 3.75 (and the sound works) > > Thanks for any suggestions, > > Vector > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From vector at leafpile.com Sun Aug 2 01:54:39 2009 From: vector at leafpile.com (Vector Hastings) Date: Sun, 2 Aug 2009 01:54:39 -0700 Subject: [sldev] Audio Driver Version: (none) In-Reply-To: <4A754B23.3060200@streamsense.net> Message-ID: Thanks, but that didn't do it. I re-ran develop.py, same result. I did notice I have the DirectX SDK loaded twice (and two versions older than August 2008). Am going to try uninstalling and installing just the one... wiki says can cause problems. -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Thomas Grimshaw Sent: Sunday, August 02, 2009 1:16 AM To: Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Did you run develop.py after installing the libraries? ~T Vector Hastings wrote: > Remembering that I'm in way over my head... any thoughts on how I'm > managing to compile this without invoking the fmod audio drivers? > > MSVS 2005 Express > > Cmake > > fmod pieces are installed as per the wiki in libraries\include, in > libraries\i686-wub32\lib\release and lib\debug, and the fmod.dll is in > indra\newview. > > Under Secondlife-bin > properites > Linker > Input > Additional > Dependencies, fmodvc.lib is there. > > The source I'm compiling right now is a combo of 1.23 and snowglobe, > but I've had this problem my last build, which was 1.23 with just a > wee patch applied. > > Under help > About, I see: > > libcurl Version: libcurl/7.19.6-CVS OpenSSL/0.9.8j c-ares/1.6.0 > J2C Decoder Version: KDU > *Audio Driver Version: (none) > *LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25810 (Mozilla GRE > version 1.8.1.21_0000000000) > Packets Lost: 0/4407 (0.0%) > > But when I run a client compiled by someone else, from that same > configuration, I get Audio Driver Version: FMOD 3.75 (and the sound works) > > Thanks for any suggestions, > > Vector > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From vector at leafpile.com Sun Aug 2 03:15:15 2009 From: vector at leafpile.com (Vector Hastings) Date: Sun, 2 Aug 2009 03:15:15 -0700 Subject: [sldev] Audio Driver Version: (none) In-Reply-To: Message-ID: Thought I had it when uninstalling Nov 2007 SDK honked at me about XAudio... But I still have no sound and "Audio Driver Version: (none)" darn -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Vector Hastings Sent: Sunday, August 02, 2009 1:55 AM To: Thomas Grimshaw; Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Thanks, but that didn't do it. I re-ran develop.py, same result. I did notice I have the DirectX SDK loaded twice (and two versions older than August 2008). Am going to try uninstalling and installing just the one... wiki says can cause problems. -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Thomas Grimshaw Sent: Sunday, August 02, 2009 1:16 AM To: Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Did you run develop.py after installing the libraries? ~T Vector Hastings wrote: > Remembering that I'm in way over my head... any thoughts on how I'm > managing to compile this without invoking the fmod audio drivers? > > MSVS 2005 Express > > Cmake > > fmod pieces are installed as per the wiki in libraries\include, in > libraries\i686-wub32\lib\release and lib\debug, and the fmod.dll is in > indra\newview. > > Under Secondlife-bin > properites > Linker > Input > Additional > Dependencies, fmodvc.lib is there. > > The source I'm compiling right now is a combo of 1.23 and snowglobe, > but I've had this problem my last build, which was 1.23 with just a > wee patch applied. > > Under help > About, I see: > > libcurl Version: libcurl/7.19.6-CVS OpenSSL/0.9.8j c-ares/1.6.0 > J2C Decoder Version: KDU > *Audio Driver Version: (none) > *LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25810 (Mozilla GRE > version 1.8.1.21_0000000000) > Packets Lost: 0/4407 (0.0%) > > But when I run a client compiled by someone else, from that same > configuration, I get Audio Driver Version: FMOD 3.75 (and the sound works) > > Thanks for any suggestions, > > Vector > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From billwindwalker at rocketmail.com Sun Aug 2 04:32:54 2009 From: billwindwalker at rocketmail.com (Bill Windwalker) Date: Sun, 2 Aug 2009 04:32:54 -0700 (PDT) Subject: [sldev] Snowglobe RC2 In-Reply-To: <20090801225450.1cdfdc48.tayra.dagostino@gmail.com> References: <4A747DB5.6080309@lindenlab.com> <20090801213159.b0574d3d.tayra.dagostino@gmail.com> <4A749D99.2080406@lindenlab.com> <20090801223216.2ec560a9.tayra.dagostino@gmail.com> <20090801225450.1cdfdc48.tayra.dagostino@gmail.com> Message-ID: <857331.25526.qm@web111201.mail.gq1.yahoo.com> SnowBlobe Crash by opening to many windows with in snowglobe. just as a heads up do not open up to many profile windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090802/774bc661/attachment.htm From carlo at alinoe.com Sun Aug 2 05:28:36 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 2 Aug 2009 14:28:36 +0200 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim In-Reply-To: <34cc66250908011521t7d91dcebvf829c0461c330134@mail.gmail.com> References: <200908012116.51731.Armin.Weatherwax@gmail.com> <34cc66250908011521t7d91dcebvf829c0461c330134@mail.gmail.com> Message-ID: <20090802122836.GA21962@alinoe.com> On Sat, Aug 01, 2009 at 06:21:40PM -0400, Teravus Ovares wrote: > Seems like an interesting change. > > Is the new first image packet supposed to contain 1024 bytes of > texture data instead of 600? TEXTURE_CACHE_ENTRY_SIZE was changed from FIRST_PACKET_SIZE to 1024. FIRST_PACKET_SIZE was and still is 600. > My guess is this isn't backwards compatible with the standard viewers also. > > If the above statements are true, then OpenSimulator won't be able to > support it unless there is viewer version tracking in the UDP stack. > Currently, it treats all viewers the same regardless of version. I > suppose the only place that it can get this information is from the > login service as well. Maybe a new part of the AgentCircuit data is > warranted to keep this information propagated on sim crossings. I doubt this is the case (LL is not changing the protocol based on viewer version). But it would be nice if a Linden could confirm that. > Let me know and I'll pass this info on to the opensim-dev e-mail list > > Regards > > Teravus > > > > On Sat, Aug 1, 2009 at 3:16 PM, Armin > Weatherwax wrote: > > Hi, > > > > I opened http://jira.secondlife.com/browse/SNOW-157, because of almost > > no textures show up logging on OpenSim (0.6.5; Debian Lenny). > > My assumption is that is caused by the change of the > > TEXTURE_CACHE_ENTRY_SIZE from 600 to ?1024 bytes in ?Changeset 2486. > > But I'm not actually into the texture cache and also not into whether or > > not a OpenSim should support this or not. > > For Snowglobe rocks, it would be great to have it also working on > > OpenSim. > > > > :) > > Armin > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From armin.weatherwax at googlemail.com Sun Aug 2 07:14:26 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Sun, 2 Aug 2009 16:14:26 +0200 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim In-Reply-To: <20090802122836.GA21962@alinoe.com> References: <200908012116.51731.Armin.Weatherwax@gmail.com> <34cc66250908011521t7d91dcebvf829c0461c330134@mail.gmail.com> <20090802122836.GA21962@alinoe.com> Message-ID: <200908021614.26161.Armin.Weatherwax@gmail.com> OpenSiM developers are unaware of the viewer code - what is the representation of TEXTURE_CACHE_ENTRY_SIZE for them ? Bezieht sich auf die Nachricht vom 02.08.2009: > On Sat, Aug 01, 2009 at 06:21:40PM -0400, Teravus Ovares wrote: > > Seems like an interesting change. > > > > Is the new first image packet supposed to contain 1024 bytes of > > texture data instead of 600? > > TEXTURE_CACHE_ENTRY_SIZE was changed from FIRST_PACKET_SIZE to 1024. > FIRST_PACKET_SIZE was and still is 600. > > > My guess is this isn't backwards compatible with the standard > > viewers also. > > > > If the above statements are true, then OpenSimulator won't be able > > to support it unless there is viewer version tracking in the UDP > > stack. Currently, it treats all viewers the same regardless of > > version. I suppose the only place that it can get this > > information is from the login service as well. Maybe a new part > > of the AgentCircuit data is warranted to keep this information > > propagated on sim crossings. > > I doubt this is the case (LL is not changing the protocol based on > viewer version). But it would be nice if a Linden could confirm that. > > > Let me know and I'll pass this info on to the opensim-dev e-mail > > list > > > > Regards > > > > Teravus > > > > > > > > On Sat, Aug 1, 2009 at 3:16 PM, Armin > > > > Weatherwax wrote: > > > Hi, > > > > > > I opened http://jira.secondlife.com/browse/SNOW-157, because of > > > almost no textures show up logging on OpenSim (0.6.5; Debian > > > Lenny). My assumption is that is caused by the change of the > > > TEXTURE_CACHE_ENTRY_SIZE from 600 to ?1024 bytes in ?Changeset > > > 2486. But I'm not actually into the texture cache and also not > > > into whether or not a OpenSim should support this or not. > > > For Snowglobe rocks, it would be great to have it also working on > > > OpenSim. > > > > > > :) > > > > > > Armin > > > _______________________________________________ > > > Policies and (un)subscribe information available here: > > > http://wiki.secondlife.com/wiki/SLDev > > > Please read the policies before posting to keep unmoderated > > > posting privileges > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges From carlo at alinoe.com Sun Aug 2 07:41:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 2 Aug 2009 16:41:55 +0200 Subject: [sldev] Snowglobe1.1.0.2565 : almost no textures logging on OpenSim In-Reply-To: <200908021614.26161.Armin.Weatherwax@gmail.com> References: <200908012116.51731.Armin.Weatherwax@gmail.com> <34cc66250908011521t7d91dcebvf829c0461c330134@mail.gmail.com> <20090802122836.GA21962@alinoe.com> <200908021614.26161.Armin.Weatherwax@gmail.com> Message-ID: <20090802144155.GB21962@alinoe.com> On Sun, Aug 02, 2009 at 04:14:26PM +0200, Armin Weatherwax wrote: > OpenSiM developers are unaware of the viewer code - what is the > representation of TEXTURE_CACHE_ENTRY_SIZE for them ? The viewer stores the first TEXTURE_CACHE_ENTRY_SIZE bytes of each texture (including the header thus, which is garanteed smaller) in cache/texture.cache (basically in some random order), the rest of the texture, if any, goes in cache/textures/[0-f]/UUID.texture Therefore, this TEXTURE_CACHE_ENTRY_SIZE is only relevant for the local cache of the viewer and not for the server side of things imho. -- Carlo Wood From lists.secondlife.com at trap.wereanimal.net Sun Aug 2 18:55:03 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Sun, 2 Aug 2009 21:55:03 -0400 Subject: [sldev] Playing with beacons. Message-ID: <200908022155.03826.lists.secondlife.com@trap.wereanimal.net> I started out today playing around with beacons and seeing if I could change a beacon to represent something else. Original code: void renderScriptedBeacons(LLDrawable* drawablep) { LLViewerObject *vobj = drawablep->getVObj(); if (vobj && !vobj->isAvatar() && !vobj->getParent() && vobj->flagScripted()) Changed code: void renderScriptedBeacons(LLDrawable* drawablep) { LLViewerObject *vobj = drawablep->getVObj(); LLSelectNode *nodep = ??????????; if (vobj && !vobj->isAvatar() && !vobj->getParent() && nodep->mSaleInfo.isForSale()) The question marks is where I got stuck. Spent a few hours experimenting to no avail. Feel free to bonk me in the head for overlooking something obvious. :-) --Techwolf Lupindo From vector at leafpile.com Sun Aug 2 20:29:31 2009 From: vector at leafpile.com (Vector Hastings) Date: Sun, 2 Aug 2009 20:29:31 -0700 Subject: [sldev] Audio Driver Version: (none) In-Reply-To: Message-ID: To finish the thread, somewhere I had CMake assuming Fmod was off... used the gui interface to turn it on. Required starting over from scratch, but it works now. Yay. Thanks to all. Vector -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Vector Hastings Sent: Sunday, August 02, 2009 3:15 AM To: Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Thought I had it when uninstalling Nov 2007 SDK honked at me about XAudio... But I still have no sound and "Audio Driver Version: (none)" darn -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Vector Hastings Sent: Sunday, August 02, 2009 1:55 AM To: Thomas Grimshaw; Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Thanks, but that didn't do it. I re-ran develop.py, same result. I did notice I have the DirectX SDK loaded twice (and two versions older than August 2008). Am going to try uninstalling and installing just the one... wiki says can cause problems. -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com]On Behalf Of Thomas Grimshaw Sent: Sunday, August 02, 2009 1:16 AM To: Second Life Developer Mailing List Subject: Re: [sldev] Audio Driver Version: (none) Did you run develop.py after installing the libraries? ~T Vector Hastings wrote: > Remembering that I'm in way over my head... any thoughts on how I'm > managing to compile this without invoking the fmod audio drivers? > > MSVS 2005 Express > > Cmake > > fmod pieces are installed as per the wiki in libraries\include, in > libraries\i686-wub32\lib\release and lib\debug, and the fmod.dll is in > indra\newview. > > Under Secondlife-bin > properites > Linker > Input > Additional > Dependencies, fmodvc.lib is there. > > The source I'm compiling right now is a combo of 1.23 and snowglobe, > but I've had this problem my last build, which was 1.23 with just a > wee patch applied. > > Under help > About, I see: > > libcurl Version: libcurl/7.19.6-CVS OpenSSL/0.9.8j c-ares/1.6.0 > J2C Decoder Version: KDU > *Audio Driver Version: (none) > *LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.25810 (Mozilla GRE > version 1.8.1.21_0000000000) > Packets Lost: 0/4407 (0.0%) > > But when I run a client compiled by someone else, from that same > configuration, I get Audio Driver Version: FMOD 3.75 (and the sound works) > > Thanks for any suggestions, > > Vector > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From tayra.dagostino at gmail.com Mon Aug 3 07:53:56 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Mon, 3 Aug 2009 16:53:56 +0200 Subject: [sldev] [Snowglobe-automails] Crash/usage stats from 2009-07-20 to 2009-08-03 In-Reply-To: <20090803125505.2EFE61A405D@borkbork.lindenlab.com> References: <20090803125505.2EFE61A405D@borkbork.lindenlab.com> Message-ID: <20090803165356.18cd9cbf.tayra.dagostino@gmail.com> On Mon, 3 Aug 2009 05:55:05 -0700 (PDT) roblabot wrote: > Crash and usage stats for the sliding window of 2009-07-20 to > 2009-08-03 > > 2009-08-03: > Total: 9 crashes from 9 agents > Snowglobe Release 1.1.2.2584: 1 crashes from 1 agents [cut] > 2009-08-02: > Total: 79 crashes from 71 agents [cut] > Snowglobe Release 1.1.2.2584: 3 crashes from 3 agents [cut] something wrong, i'm crashed 2 times yesterday, i dunno if this stat are based on pdt time, but impossible crash number is same of agents.... From tigrospottystripes at gmail.com Mon Aug 3 15:16:18 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 03 Aug 2009 19:16:18 -0300 Subject: [sldev] [Fwd: Re: remaping a space that is a sphere folded on itself (and you thought spinning tesseracts were insane)] Message-ID: <4A7761B2.80005@Gmail.com> -------------- next part -------------- An embedded message was scrubbed... From: Simone Gateaux Subject: Re: remaping a space that is a sphere folded on itself (and you thought spinning tesseracts were insane) Date: Wed, 10 Jun 2009 14:12:09 -0500 Size: 2163 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20090803/005139fa/attachment.eml From robla at lindenlab.com Mon Aug 3 16:16:32 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 03 Aug 2009 16:16:32 -0700 Subject: [sldev] Snowglobe 1.1 is out Message-ID: <4A776FD0.7040805@lindenlab.com> Hi folks, It's up on the download page: http://secondlife.com/support/downloads.php Here are the release notes: https://wiki.secondlife.com/wiki/Release_Notes/Snowglobe_Release/1.1 Thanks everyone who helped out on this release! More later when I'm not rushing around to make sure I've got everything done I need to. Rob From aleric.inglewood at gmail.com Mon Aug 3 17:57:40 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Tue, 4 Aug 2009 02:57:40 +0200 Subject: [sldev] How to solve this bug? In-Reply-To: <4A72E8E7.6090406@lindenlab.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> Message-ID: <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> On Fri, Jul 31, 2009 at 2:51 PM, Tofu Linden wrote: > If I understand your description correctly - > > I think the bug is that OpenAL should NOT be mixing sources that are > not in a playing state. ?That would be an AL bug (especially since > sources are traditionally considered a 'cheap' resource in AL as > long as they're not doing anything). They are not doing that, I was counting the number of elements in a linked list, but those sources that are non-playing are skipped in that list and don't use CPU. > Now, if we're leaving those sources in a playing state but just > feeding silence into them - that would be a viewer bug. This turns out to be the case. A muted sound is left playing and it's gain is set to 0. Effectively this means that we're mixing silence. In fact, it turns out to be a lot worse than just mixing silence: libopenal for some reason uses 2 to 3 times more cpu to mix a channel that has it's gain set to 0, than mixing one with a large gain! The whole "intermittent" comes from the fact that I can play 31 non-muted channels, but not 31 muted ones. In the latter case the lock is hardly released by the audio thread thus. > I don't think that moving AL calls out of the main thread is > the correct solution - (most) AL calls are not expected to significantly > block in the first place, and this sounds like it is AL's own > calls waiting for locks on AL's own backend. ?This would bite > any AL-using app - this AL implementation should be fixed. > > I suggest investigating whether the viewer is doing the right thing > (stopping non-playing sources) and if so, taking investigation over > to the problematic AL implementation (openal-soft?). > > Thanks! I'd be happy, now that I know that mixing channels with a gain of 0 cost much more cpu, to fix and close this bug by stopping sound sources instead of setting their gain to 0. From tigrospottystripes at gmail.com Mon Aug 3 18:29:38 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 03 Aug 2009 22:29:38 -0300 Subject: [sldev] SLDev post acknowledgement (oops wrong list) In-Reply-To: References: Message-ID: <4A778F02.1060609@Gmail.com> oops, sorry, I jsut realized I sent it to the wrong list sldev-bounces at lists.secondlife.com escreveu: > Your message entitled > > [Fwd: Re: remaping a space that is a sphere folded on itself (and you thought spinning tesseracts were insane)] > > was successfully received by the SLDev mailing list. > > List info page: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Your preferences: https://lists.secondlife.com/cgi-bin/mailman/options/sldev/tigrospottystripes%40gmail.com > > From tofu.linden at lindenlab.com Tue Aug 4 03:12:36 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue, 04 Aug 2009 11:12:36 +0100 Subject: [sldev] How to solve this bug? In-Reply-To: <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> Message-ID: <4A780994.8030309@lindenlab.com> Aleric Inglewood wrote: > I'd be happy, now that I know that mixing channels with a gain > of 0 cost much more cpu, to fix and close this bug by stopping sound > sources instead of setting their gain to 0. That definitely seems like the right direction - thanks! From sheet.spotter at gmail.com Tue Aug 4 06:33:27 2009 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Tue, 4 Aug 2009 08:33:27 -0500 Subject: [sldev] How to solve this bug? In-Reply-To: <4A780994.8030309@lindenlab.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com><1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> <4A780994.8030309@lindenlab.com> Message-ID: <93015DC698D045EEB6E0C3073C85B148@kenb> There may be two issues to consider before revising the implementation for sound. Firstly, stopping sound sources might have an undesirable side effect when moving your camera. In the worst case, moving your camera in and out might make the scene sound like rap music, constantly stopping and restarting the sound. Playing the sound with a gain of zero ensures that sounds continue to play while the camera is out of range. Secondly, the llPreloadSound scripting function is used to ensure that any clients within range have performed any necessary setup and initialization that allows the sound to be triggered later without delay. This operation might rely on playing the sound with zero gain. Do these issues constitute two requirements that any revised implementation should satisfy? 1. Sounds that fall out of range should continue playing (i.e., not restart when they fall back into range). 2. Sounds sent to the viewer by llPreloadSound should be triggered without delay. Sheet Spotter -----Original Message----- From: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Tofu Linden Sent: August 4, 2009 5:13 AM To: Second Life Developer Mailing List Subject: Re: [sldev] How to solve this bug? Aleric Inglewood wrote: > I'd be happy, now that I know that mixing channels with a gain > of 0 cost much more cpu, to fix and close this bug by stopping sound > sources instead of setting their gain to 0. That definitely seems like the right direction - thanks! From robertltux at gmail.com Tue Aug 4 08:33:21 2009 From: robertltux at gmail.com (Robert Martin) Date: Tue, 4 Aug 2009 11:33:21 -0400 Subject: [sldev] How to solve this bug? In-Reply-To: <93015DC698D045EEB6E0C3073C85B148@kenb> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> <4A780994.8030309@lindenlab.com> <93015DC698D045EEB6E0C3073C85B148@kenb> Message-ID: On Tue, Aug 4, 2009 at 9:33 AM, Sheet Spotter wrote: > > There may be two issues to consider before revising the implementation for > sound. > > Firstly, stopping sound sources might have an undesirable side effect when > moving your camera. In the worst case, moving your camera in and out might > make the scene sound like rap music, constantly stopping and restarting the > sound. Playing the sound with a gain of zero ensures that sounds continue to > play while the camera is out of range. > > Secondly, the llPreloadSound scripting function is used to ensure that any > clients within range have performed any necessary setup and initialization > that allows the sound to be triggered later without delay. This operation > might rely on playing the sound with zero gain. > > Do these issues constitute two requirements that any revised implementation > should satisfy? > 1. Sounds that fall out of range should continue playing (i.e., not restart > when they fall back into range). > 2. Sounds sent to the viewer by llPreloadSound should be triggered without > delay. > > > Sheet Spotter > > -----Original Message----- > From: sldev-bounces at lists.secondlife.com > [mailto:sldev-bounces at lists.secondlife.com] On Behalf Of Tofu Linden > Sent: August 4, 2009 5:13 AM > To: Second Life Developer Mailing List > Subject: Re: [sldev] How to solve this bug? > > Aleric Inglewood wrote: >> I'd be happy, now that I know that mixing channels with a gain >> of 0 cost much more cpu, to fix and close this bug by stopping sound >> sources instead of setting their gain to 0. > > That definitely seems like the right direction - thanks! > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > two somewhat goofy ways to fix this 1 instead of dropping the gain to full zero drop it down to minimum to prevent triggering the Zero Gain Bug (play the sound at like 0.01% or whatever the lowest possible gain is)* 2 have a timeout so that if you run back into range within say 20 seconds it will continue to play but if you are out of range at 21 seconds then the stream is cut *note if implemented the comments should have **please remove when lib bug is fixed ref jira VWR-14914** or something similar -- Robert L Martin From robla at lindenlab.com Tue Aug 4 13:30:48 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 04 Aug 2009 13:30:48 -0700 Subject: [sldev] Something is up with crash rate Message-ID: <4A789A78.5030300@lindenlab.com> Hi folks, One of the things I've been meaning to fix is the crash report stats that go out on the snowglobe-automails alias. What's currently being mailed to that mailing list is crash reports, which doesn't give the full range of problems that exist. Pulling the right number is something that I've not found the time to really automate right. In lieu of that I've started crunching the numbers for the crash rates for Monday, and unfortunately, the news isn't great: Crash rates per 100 hours: Snowglobe Release 1.0.2.2451 12.26 Snowglobe Release 1.0.3.2537 11.25 Snowglobe Release 1.1.2.2584 13.76 Snowglobe Test Build 1.1.0.2558 5.82 Snowglobe Test Build 1.1.0.2565 9.57 (lower is better) The test builds have a fraction of the usage of the release builds, so what we're seeing with the test builds may not be indicative of the true stability of the build. I've attached the raw spreadsheet I used to derive the numbers. The main column I'm using is the "last_exec_event" column, and treating non-zero values as a crash. Here's the decoder ring for that column: #*** 0 = Previous session ended normally #*** 1 = Froze #*** 2 = Fatal Error #*** 3 = Crash detected #*** 4 = Froze after logout #*** 5 = Crash after logout Assuming I'm making the calculation right, we've still got some work to do here. Unfortunately, in the crash reports, there's no standout crashers for us to find and kill. All of the reports I see come from two agents, max. Here's a couple of crashes: Crash #1 LLTextureFetchWorker::callbackCacheRead: ASSERT (imagesize >= 0) * [0] LLError::crashAndLoop o e:/w-sweeper/robla/linden/indra/llcommon/llerror.cpp:1214 * [1] LLError::Log::flush o e:/w-sweeper/robla/linden/indra/llcommon/llerror.cpp:1138 * [2] LLTextureFetchWorker::callbackCacheRead o e:/w-sweeper/robla/linden/indra/newview/lltexturefetch.cpp:1233 * [3] LLTextureFetchWorker::CacheReadResponder::completed o e:/w-sweeper/robla/linden/indra/newview/lltexturefetch.cpp:79 * [4] LLTextureCache::update o e:/w-sweeper/robla/linden/indra/newview/lltexturecache.cpp:791 * [5] LLAppViewer::mainLoop o e:/w-sweeper/robla/linden/indra/newview/llappviewer.cpp:1007 * [6] WinMain o e:/w-sweeper/robla/linden/indra/newview/llappviewerwin32.cpp:228 * [7] __tmainCRTStartup o f:/sp/vctools/crt_bld/self_x86/crt/src/crtexe.c:589 * [8] kernel32.dll * [9] ntdll.dll * [10] ntdll.dll 2 agents, 4 crashes. Crash #2: LLVertexBuffer::setupVertexBuffer: LLVertexBuffer::setupVertexBuffer missing required components for supplied data mask. [0] LLError::crashAndLoop [snowgloberelease.exe llerror.cpp] [1] LLError::Log::flush [snowgloberelease.exe llerror.cpp] [2] LLVertexBuffer::setupVertexBuffer [snowgloberelease.exe llvertexbuffer.cpp] [3] LLVertexBuffer::setBuffer [snowgloberelease.exe llvertexbuffer.cpp] [4] LLDrawPoolBump::pushBatch [snowgloberelease.exe lldrawpoolbump.cpp] [5] LLDrawPoolBump::renderDeferred [snowgloberelease.exe lldrawpoolbump.cpp] [6] LLPipeline::renderGeomDeferred [snowgloberelease.exe pipeline.cpp] [7] display [snowgloberelease.exe llviewerdisplay.cpp] [8] LLAppViewer::mainLoop [snowgloberelease.exe llappviewer.cpp] [9] WinMain [snowgloberelease.exe llappviewerwin32.cpp] [10] __tmainCRTStartup [snowgloberelease.exe crtexe.c] [11] Unknown [kernel32.dll ] 1 agent, 3 crashes Anyway, this is partial data, and I'm still sifting through the raw data. We'll have to see if the ratios hold, and if they do, figure out how we're going to fix our new batch of problems. Hopefully, there's something wrong with how I'm crunching the numbers rather than with Snowglobe 1.1. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: crashrates-2009-08-03.ods Type: application/vnd.oasis.opendocument.spreadsheet Size: 12126 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090804/3033f31a/attachment.ods From mike.dickson at hp.com Tue Aug 4 15:08:55 2009 From: mike.dickson at hp.com (Mike Dickson) Date: Tue, 04 Aug 2009 17:08:55 -0500 Subject: [sldev] Is is possible to build a 64bit (for Linux) SNOWGLOBE? In-Reply-To: <4A789A78.5030300@lindenlab.com> References: <4A789A78.5030300@lindenlab.com> Message-ID: <4A78B177.4090609@hp.com> I've seen snippets of info on 64bit before but don't really know the answer to this. My question, is it possible to build SNOWGLOBE as a 64 bit binary on Linux? If so can someone point me to instructions on how to do it? Thanks! Mike From carlo at alinoe.com Tue Aug 4 18:43:32 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 5 Aug 2009 03:43:32 +0200 Subject: [sldev] Is is possible to build a 64bit (for Linux) SNOWGLOBE? In-Reply-To: <4A78B177.4090609@hp.com> References: <4A789A78.5030300@lindenlab.com> <4A78B177.4090609@hp.com> Message-ID: <20090805014332.GA17264@alinoe.com> On Tue, Aug 04, 2009 at 05:08:55PM -0500, Mike Dickson wrote: > I've seen snippets of info on 64bit before but don't really know the > answer to this. My question, is it possible to build SNOWGLOBE as a 64 > bit binary on Linux? If so can someone point me to instructions on how > to do it? Thanks! Yes, I've never used anything else. configure: ./develop.py --type=Debug -m64 --standalone configure -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_CXX_FLAGS:STRING="$CXXFLAGS" -DCMAKE_EXE_LINKER_FLAGS:STRING="$LDFLAGS" of course you can leave the -Defines away if you don't need them. build: ./develop.py --type=Debug -m64 --standalone build Main problem is to have all libraries (and developer packages!) installed before this. -- Carlo Wood From tayra.dagostino at gmail.com Wed Aug 5 03:21:30 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Wed, 5 Aug 2009 12:21:30 +0200 Subject: [sldev] Something is up with crash rate In-Reply-To: <4A789A78.5030300@lindenlab.com> References: <4A789A78.5030300@lindenlab.com> Message-ID: <20090805122130.55a43125.tayra.dagostino@gmail.com> On Tue, 04 Aug 2009 13:30:48 -0700 Rob Lanphier wrote: > Crash rates per 100 hours: > > Snowglobe Release 1.0.2.2451 12.26 > Snowglobe Release 1.0.3.2537 11.25 > Snowglobe Release 1.1.2.2584 13.76 > Snowglobe Test Build 1.1.0.2558 5.82 > Snowglobe Test Build 1.1.0.2565 9.57 > > (lower is better) I cannot diagnose correctly why i crash, neither how crashlogger can report the reason, i can only say what i see just before crash... I crash very few time, what i see is: - all prims are grey, no texture rendering - HUD texture on avatar body (and other see too, not so good private IM visible on body) - other see me as shadow, skin is transparent - i have UI problem few time before crash (background of chat windows, inventory e map transparent) very few time if a teleport take a lot of time i'm disconnected by viewer, but i don't think this is a "crash" > Anyway, this is partial data, and I'm still sifting through the raw > data. We'll have to see if the ratios hold, and if they do, figure > out how we're going to fix our new batch of problems. Hopefully, > there's something wrong with how I'm crunching the numbers rather > than with Snowglobe 1.1. If i'm right more than 66% of lines pasted by you are related to cache (fetch, purging and so) there is a way to let crashlogger work with gdb/other to better diagnose why program exit? (maybe a new crashlogger, not lunched after viewer but crashlogger run viewer and continue to check all thread and calls) From tinselsilvera at frontiernet.net Wed Aug 5 03:42:15 2009 From: tinselsilvera at frontiernet.net (tinselsilvera at frontiernet.net) Date: Wed, 5 Aug 2009 10:42:15 +0000 (UTC) Subject: [sldev] Something is up with crash rate Message-ID: <1624333537.1385011249468935967.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> I can only speak of my own experience. I had no reportable issues with Release 1.0.2.2451 when I first used it. With the next two releases my experience got progressively worse. Crashing out, slow rezz, slow load, etc. I went back to the Release 1.0.2.2451 and the only two issues I'm currently having is my inventory doesn't fully load about half the time and I crash out when I have the upload window open too long when looking for files on my pc. Something seems to have changed along the way. -- Tinsel Silvera From carlo at alinoe.com Wed Aug 5 03:53:47 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 5 Aug 2009 12:53:47 +0200 Subject: [sldev] Something is up with crash rate In-Reply-To: <1624333537.1385011249468935967.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> References: <1624333537.1385011249468935967.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> Message-ID: <20090805105347.GA13382@alinoe.com> On Wed, Aug 05, 2009 at 10:42:15AM +0000, tinselsilvera at frontiernet.net wrote: > I can only speak of my own experience. I had no reportable issues with Release 1.0.2.2451 when I first used it. With the next two releases my experience got progressively worse. Crashing out, slow rezz, slow load, etc. I went back to the Release 1.0.2.2451 and the only two issues I'm currently having is my inventory doesn't fully load about half the time and I crash out when I have the upload window open too long when looking for files on my pc. Something seems to have changed along the way. Can you compile the viewer yourself? It would help a lot if you could pin point the exact revision at which the problems start to occur. Not all revisions are changes to snowglobe unfortunately, you could try a binary search for the following revisions (these are the ones that make a change to contributions.txt) r2580 | aimee.trescothick | 2009-07-31 20:51:59 +0200 (Fri, 31 Jul 2009) | 2 lines r2576 | aimee.trescothick | 2009-07-31 00:57:47 +0200 (Fri, 31 Jul 2009) | 3 lines r2574 | merov.linden | 2009-07-30 20:47:53 +0200 (Thu, 30 Jul 2009) | 1 line r2565 | robin.cornelius | 2009-07-26 18:11:58 +0200 (Sun, 26 Jul 2009) | 1 line r2561 | aimee.trescothick | 2009-07-25 22:35:02 +0200 (Sat, 25 Jul 2009) | 4 lines r2560 | rob.linden | 2009-07-25 18:56:54 +0200 (Sat, 25 Jul 2009) | 8 lines r2559 | thickbrick.sleaford | 2009-07-25 12:44:18 +0200 (Sat, 25 Jul 2009) | 1 line r2558 | rob.linden | 2009-07-24 05:53:52 +0200 (Fri, 24 Jul 2009) | 4 lines r2553 | rob.linden | 2009-07-22 23:18:57 +0200 (Wed, 22 Jul 2009) | 2 lines r2552 | robin.cornelius | 2009-07-22 23:11:13 +0200 (Wed, 22 Jul 2009) | 1 line r2547 | rob.linden | 2009-07-22 02:39:08 +0200 (Wed, 22 Jul 2009) | 7 lines r2511 | nyx.linden | 2009-07-14 19:52:45 +0200 (Tue, 14 Jul 2009) | 11 lines r2506 | thickbrick.sleaford | 2009-07-11 17:31:30 +0200 (Sat, 11 Jul 2009) | 1 line r2502 | aimee.trescothick | 2009-07-10 03:51:23 +0200 (Fri, 10 Jul 2009) | 3 lines r2482 | aimee.trescothick | 2009-07-03 00:11:46 +0200 (Fri, 03 Jul 2009) | 2 lines r2481 | aimee.trescothick | 2009-07-03 00:07:13 +0200 (Fri, 03 Jul 2009) | 2 lines r2480 | aimee.trescothick | 2009-07-02 23:14:06 +0200 (Thu, 02 Jul 2009) | 2 lines r2465 | robin.cornelius | 2009-06-29 23:14:55 +0200 (Mon, 29 Jun 2009) | 1 line r2463 | rob.linden | 2009-06-29 02:53:08 +0200 (Mon, 29 Jun 2009) | 3 lines r2462 | aimee.trescothick | 2009-06-28 00:49:27 +0200 (Sun, 28 Jun 2009) | 2 lines r2461 | aimee.trescothick | 2009-06-27 20:17:35 +0200 (Sat, 27 Jun 2009) | 2 lines r2460 | rob.linden | 2009-06-27 01:44:23 +0200 (Sat, 27 Jun 2009) | 2 lines r2459 | aimee.trescothick | 2009-06-27 00:36:23 +0200 (Sat, 27 Jun 2009) | 2 lines r2458 | aimee.trescothick | 2009-06-27 00:30:08 +0200 (Sat, 27 Jun 2009) | 2 lines r2456 | rob.linden | 2009-06-26 00:18:25 +0200 (Fri, 26 Jun 2009) | 2 lines Binary search meaning: you start with compiling 2580 and test if you crash with a self-compiled viewer (possibly in Debug mode). Then 2451 and test if you don't. Then 2502, and depending on whether you get the same crash or not (a different crash means you have to restart again) you either try 2463 or 2559, etc. -- Carlo Wood From I_really_needed_a_new_mailbox at gmx.de Wed Aug 5 06:15:01 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Wed, 5 Aug 2009 15:15:01 +0200 Subject: [sldev] SLURL to SLurl - an easy task? Message-ID: Hi there! Maybe this is an easy task for someone who can run a search and replace on the sourcecode and ensure that it doesn't bork something: VWR-14997 - Change SLURL to SLurl in the UI to sync documentation with viewer --zai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/934db788/attachment.htm From robla at lindenlab.com Wed Aug 5 10:21:21 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 05 Aug 2009 10:21:21 -0700 Subject: [sldev] Emerging top crashers in Snowglobe 1.1 Message-ID: <4A79BF91.6010000@lindenlab.com> Hi folks, More crash data has come in, and these two are emerging as the top crashers: LLTextureFetchWorker::callbackCacheRead: ASSERT (imagesize >= 0) 10 crashes by 6 agents: indra/newview/lltexturefetch.cpp:1233 http://jira.secondlife.com/browse/SNOW-170 LLViewerImage::doLoadedCallbacks: ASSERT (mRawImage.notNull() indra/newview/llviewerimage.cpp:1438 9 crashes by 5 agents: http://jira.secondlife.com/browse/SNOW-169 Any ideas as to the cause of these? Rob From robla at lindenlab.com Wed Aug 5 10:27:51 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 05 Aug 2009 10:27:51 -0700 Subject: [sldev] Something is up with crash rate In-Reply-To: <20090805105347.GA13382@alinoe.com> References: <1624333537.1385011249468935967.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> <20090805105347.GA13382@alinoe.com> Message-ID: <4A79C117.2000306@lindenlab.com> On 08/05/2009 03:53 AM, Carlo Wood wrote: > On Wed, Aug 05, 2009 at 10:42:15AM +0000, tinselsilvera at frontiernet.net wrote: > >> I can only speak of my own experience. I had no reportable issues with Release 1.0.2.2451 when I first used it. With the next two releases my experience got progressively worse. Crashing out, slow rezz, slow load, etc. I went back to the Release 1.0.2.2451 and the only two issues I'm currently having is my inventory doesn't fully load about half the time and I crash out when I have the upload window open too long when looking for files on my pc. Something seems to have changed along the way. >> > > Can you compile the viewer yourself? > It would help a lot if you could pin point the exact revision > at which the problems start to occur. > A couple of comments: 1. You don't need to compile your own viewer to help in this way. Older versions are available here: https://lists.secondlife.com/pipermail/sldev-commits/2009-July/date.html Look for the mails that say "successful build" 2. It's best to look through the full history, not just the doc/contributions.txt list as Carlo wrote: http://svn.secondlife.com/trac/linden/log/projects/2009/snowglobe/trunk While some of the commits are clearly not problematic (e.g. CG's test commits late in the game), there was a big change at r2486 that very well might be the culprit, but would be missed by looking at contributions.txt. Rob From carlo at alinoe.com Wed Aug 5 10:38:00 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 5 Aug 2009 19:38:00 +0200 Subject: [sldev] Something is up with crash rate In-Reply-To: <4A79C117.2000306@lindenlab.com> References: <1624333537.1385011249468935967.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> <20090805105347.GA13382@alinoe.com> <4A79C117.2000306@lindenlab.com> Message-ID: <20090805173800.GA11512@alinoe.com> Thanks for the links and correcting me, Rob :) On Wed, Aug 05, 2009 at 10:27:51AM -0700, Rob Lanphier wrote: > A couple of comments: > 1. You don't need to compile your own viewer to help in this way. > Older versions are available here: > https://lists.secondlife.com/pipermail/sldev-commits/2009-July/date.html > > Look for the mails that say "successful build" > > 2. It's best to look through the full history, not just the > doc/contributions.txt list as Carlo wrote: > http://svn.secondlife.com/trac/linden/log/projects/2009/snowglobe/trunk > > While some of the commits are clearly not problematic (e.g. CG's test > commits late in the game), there was a big change at r2486 that very > well might be the culprit, but would be missed by looking at > contributions.txt. > > Rob -- Carlo Wood From carlo at alinoe.com Wed Aug 5 10:39:51 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 5 Aug 2009 19:39:51 +0200 Subject: [sldev] Emerging top crashers in Snowglobe 1.1 In-Reply-To: <4A79BF91.6010000@lindenlab.com> References: <4A79BF91.6010000@lindenlab.com> Message-ID: <20090805173951.GB11512@alinoe.com> What I'd like to know if is those people cleared their cache before starting the new viewer. Or, if the crashes persist if they do. On Wed, Aug 05, 2009 at 10:21:21AM -0700, Rob Lanphier wrote: > Hi folks, > > More crash data has come in, and these two are emerging as the top crashers: > > LLTextureFetchWorker::callbackCacheRead: ASSERT (imagesize >= 0) > 10 crashes by 6 agents: > indra/newview/lltexturefetch.cpp:1233 > http://jira.secondlife.com/browse/SNOW-170 > > LLViewerImage::doLoadedCallbacks: ASSERT (mRawImage.notNull() > indra/newview/llviewerimage.cpp:1438 > 9 crashes by 5 agents: > http://jira.secondlife.com/browse/SNOW-169 > > Any ideas as to the cause of these? > > Rob -- Carlo Wood From robertltux at gmail.com Wed Aug 5 11:36:50 2009 From: robertltux at gmail.com (Robert Martin) Date: Wed, 5 Aug 2009 14:36:50 -0400 Subject: [sldev] Emerging top crashers in Snowglobe 1.1 In-Reply-To: <20090805173951.GB11512@alinoe.com> References: <4A79BF91.6010000@lindenlab.com> <20090805173951.GB11512@alinoe.com> Message-ID: Sideways issue to this is How is the profile data folder controlled?? Some of the issue may be from folks running multiple clients with a single profile folder (on my own system i have SL 1.23 , SnowGlobe 1.1.2?? and Emerald all pointed at the main secondlife profile data folder (oh and until vwr-6199 is updated to SG/1.23 i also have 1.20.6 in the mix) some of the crashes may be from a tiny bit of skew in the cache handling so if we could have the profile redirected to say %apdata%/SnowGlobe that may be useful for bug chasing. -- Robert L Martin Please tell me there is some XML file that can be edited and its not baked in the bin From robla at lindenlab.com Wed Aug 5 11:51:21 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 05 Aug 2009 11:51:21 -0700 Subject: [sldev] More crash rate statistics Message-ID: <4A79D4A9.4090101@lindenlab.com> Hi folks, I've attached a couple of things: 1. A graph showing the crash rates for the viewer 2. More granular data in table form. The graph is obviously more visually appealing, but the problem is that it shows the crash rate of the viewer is that it currently shows all "Snowglobe Test Build" lumped together in a way that's not going to be entirely indicative of the problems. Unfortunately, the tools we use to update the graph may not be flexible enough to keep rotating version numbers. The other problem is that there's a lot of junk versions in the version numbers. If we do graph by version number, we'd need to make sure we don't clutter up the data with bad version numbers. How would you all like to see this data presented? Discuss here: http://jira.secondlife.com/browse/SNOW-171 Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: crashrates-2009-07.csv Type: text/csv Size: 46649 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090805/07fe88d4/attachment-0001.csv -------------- next part -------------- A non-text attachment was scrubbed... Name: Snowglobe - Crashes per 100 Hours 2 MONTHS.png Type: image/png Size: 37309 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090805/07fe88d4/attachment-0001.png From armin.weatherwax at googlemail.com Wed Aug 5 12:30:23 2009 From: armin.weatherwax at googlemail.com (Armin Weatherwax) Date: Wed, 5 Aug 2009 21:30:23 +0200 Subject: [sldev] Emerging top crashers in Snowglobe 1.1 In-Reply-To: <4A79BF91.6010000@lindenlab.com> References: <4A79BF91.6010000@lindenlab.com> Message-ID: <200908052130.23501.Armin.Weatherwax@gmail.com> The sample sizes differ very much. The differences could be (partially) caused by different populations, e.g. developers may crash (more often) on purpose by checking a whether a bug (still) exists/ crash less often by avoiding a known crash bug because they are interested in something else. Early adopters may e.g. run more often into a crash bug by trying everything they hope to be fixed. Am Wednesday 05 August 2009 19:21:21 schrieb Rob Lanphier: > Hi folks, > > More crash data has come in, and these two are emerging as the top > crashers: > > LLTextureFetchWorker::callbackCacheRead: ASSERT (imagesize >= 0) > 10 crashes by 6 agents: > indra/newview/lltexturefetch.cpp:1233 > http://jira.secondlife.com/browse/SNOW-170 > > LLViewerImage::doLoadedCallbacks: ASSERT (mRawImage.notNull() > indra/newview/llviewerimage.cpp:1438 > 9 crashes by 5 agents: > http://jira.secondlife.com/browse/SNOW-169 > > Any ideas as to the cause of these? > > Rob > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From billwindwalker at rocketmail.com Wed Aug 5 12:35:12 2009 From: billwindwalker at rocketmail.com (Bill Windwalker) Date: Wed, 5 Aug 2009 12:35:12 -0700 (PDT) Subject: [sldev] More crash rate statistics In-Reply-To: <4A79D4A9.4090101@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> Message-ID: <733141.46616.qm@web111204.mail.gq1.yahoo.com> I am using the snowglobe test build 1.1 and have had it running over 40 hours non stop. but the crash i have had was do to this list of types. 1. bulk load time out crash.. trying to import textures to SL after texture edit out of sl. 2. missing or unknown texture attack by a griefer 3. invisi goo , pusher prim attacks spam flood pushing fps down to 0.1 then mini map started to blink red then a crash. 4. Unknown IM attack crash still do not know what happen no logs had taken place. 5. after doing more then 24 hours of builds client started to slow down and when i did try to TP to another sim i did crash some thing to do with can not find sim address time out. ? ________________________________ From: Rob Lanphier To: Second Life Developer Mailing List Sent: Wednesday, August 5, 2009 2:51:21 PM Subject: [sldev] More crash rate statistics Hi folks, I've attached a couple of things: 1.? A graph showing the crash rates for the viewer 2.? More granular data in table form. The graph is obviously more visually appealing, but the problem is that it shows the crash rate of the viewer is that it currently shows all "Snowglobe Test Build" lumped together in a way that's not going to be entirely indicative of the problems.? Unfortunately, the tools we use to update the graph may not be flexible enough to keep rotating version numbers. The other problem is that there's a lot of junk versions in the version numbers.? If we do graph by version number, we'd need to make sure we don't clutter up the data with bad version numbers. How would you all like to see this data presented? Discuss here: http://jira.secondlife.com/browse/SNOW-171 Rob __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/5fc88932/attachment.htm From GordonWendt at gmail.com Wed Aug 5 12:40:30 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 5 Aug 2009 15:40:30 -0400 Subject: [sldev] Something is up with crash rate In-Reply-To: <4A789A78.5030300@lindenlab.com> References: <4A789A78.5030300@lindenlab.com> Message-ID: <493033a70908051240i23b80517v92e3da686e076e5b@mail.gmail.com> On Tue, Aug 4, 2009 at 4:30 PM, Rob Lanphier wrote: > > #*** 0 = Previous session ended normally > #*** 1 = Froze > #*** 2 = Fatal Error > #*** 3 = Crash detected > #*** 4 = Froze after logout > #*** 5 = Crash after logout If this is only data being sent through official reports from the crash reporters then from experience and from observation I think the numbers for situation #4 and #5 are going to be artificially low since I think many people will attest to the fact that the are times when rather than exit neatly the viewer either crashes out or freezes the process during exit requiring a force quit and most of the time these situations do not trigger the crash reporter. Just something to keep in mind. -Gordon Wendt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/39298c05/attachment.htm From GordonWendt at gmail.com Wed Aug 5 12:45:45 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 5 Aug 2009 15:45:45 -0400 Subject: [sldev] More crash rate statistics In-Reply-To: <733141.46616.qm@web111204.mail.gq1.yahoo.com> References: <4A79D4A9.4090101@lindenlab.com> <733141.46616.qm@web111204.mail.gq1.yahoo.com> Message-ID: <493033a70908051245k19aa0e1dr2a29dc3c75df143e@mail.gmail.com> Can I say not again on this list? In reference to another teleport memory leak.... Not again. I've also had issues with having certain textures being able to crash the viewer although in my crashes I think it was accidental rather than griefer attacks but if there isn't already there should be a JIRA about that. -Gordon On Wed, Aug 5, 2009 at 3:35 PM, Bill Windwalker < billwindwalker at rocketmail.com> wrote: > I am using the snowglobe test build 1.1 and have had it running over 40 > hours non stop. > but the crash i have had was do to this list of types. > 1. bulk load time out crash.. trying to import textures to SL after texture > edit out of sl. > 2. missing or unknown texture attack by a griefer > 3. invisi goo , pusher prim attacks spam flood pushing fps down to 0.1 then > mini map started to blink red then a crash. > 4. Unknown IM attack crash still do not know what happen no logs had taken > place. > 5. after doing more then 24 hours of builds client started to slow down and > when i did try to TP to another sim i did crash some thing to do with can > not find sim address time out. > > > ------------------------------ > *From:* Rob Lanphier > *To:* Second Life Developer Mailing List > *Sent:* Wednesday, August 5, 2009 2:51:21 PM > *Subject:* [sldev] More crash rate statistics > > Hi folks, > > I've attached a couple of things: > 1. A graph showing the crash rates for the viewer > 2. More granular data in table form. > > The graph is obviously more visually appealing, but the problem is that > it shows the crash rate of the viewer is that it currently shows all > "Snowglobe Test Build" lumped together in a way that's not going to be > entirely indicative of the problems. Unfortunately, the tools we use to > update the graph may not be flexible enough to keep rotating version > numbers. > > The other problem is that there's a lot of junk versions in the version > numbers. If we do graph by version number, we'd need to make sure we > don't clutter up the data with bad version numbers. > > How would you all like to see this data presented? > > Discuss here: > http://jira.secondlife.com/browse/SNOW-171 > > Rob > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/7fb198b1/attachment.htm From missannotoole at yahoo.com Wed Aug 5 15:03:56 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 5 Aug 2009 15:03:56 -0700 (PDT) Subject: [sldev] Emerging top crashers in Snowglobe 1.1 In-Reply-To: References: <4A79BF91.6010000@lindenlab.com> <20090805173951.GB11512@alinoe.com> Message-ID: <713650.75360.qm@web59107.mail.re1.yahoo.com> Robert may be on to something here. The snowglobe client can use the same directory as the production viewer. However all settings for all clients are all in the same roaming folder and changes to stuff in one account affects all accounts. This tends to make me think the SL client is only safe for one version and one account per computer. Shouldn't it be such that each major version (Snowglobe, Secondlife, etc.) each has their own cache and settings directories and that each account on each client version has it's own separate cache directory? What happens when -multiple is used? How does SL keep track of what texture cache to hit if they are all the same? I made a seperate directory for snowglobe cache and brought up 3 sessions using the -multiple parameter. In this new cache directory one of the clients wrote a directory for one of the account names. This was the first client that was loaded. The 2 subsequent sessions did not write a user directory in the cache directory. The fact this user directory was created there seems to be an issue since all of the clients all use the appdata roaming secondlife directory for settings by account stuff. Meaning all clients seem to share stuff across main and snowglobe. However the main viewer did not pick up the setting to use the new cache directory due to snowglobe using a different settings xml file. Something about that user name directory being created in the cache directory for snowglobe seems odd. Why was it created when it is supposed to be using the directory structure identified as for logs?. Note that I can clearly see snowglobe is using a different designator in the cache files so if there is a conflict here it would have to be some snippet of code not looking in the right one if they are all piled in the same directory. I also see that there are different cache files per user with the second user getting a .1 extension, third gets a .2 extension, etc. These extensions were appended to the files created after a cache clear, move cache directory, then load each account and fetch inventory. Load account A and data.db2.x.8869 and index.db2.x.8869 is created Load account B and data.db2.x.8869.1 and index.db2.x.8869.1 is created Load account C and data.db2.x.8869.2 and index.db2.x.8869.2 is created This is where it gets ugly. If I cleared cache and loaded clients in order of A, B, and C, then exit all, and load C then the files created by A are in use by the client. Seems to me the files created by account C should be in use when account C is loaded by itself. I see name.cache is shared across all sessions. Is this wise? What are all these names in this file anyway lol. I am beginning to think it is unsafe for anything but one client version and one user account per computer. Well unsafe is too strong. Let's just say you might experience interesting results by trying to run multiple accounts on the same computer. ________________________________ From: Robert Martin To: SLDev Mailing List Sent: Wednesday, August 5, 2009 2:36:50 PM Subject: Re: [sldev] Emerging top crashers in Snowglobe 1.1 Sideways issue to this is How is the profile data folder controlled?? Some of the issue may be from folks running multiple clients with a single profile folder (on my own system i have SL 1.23 , SnowGlobe 1.1.2?? and Emerald all pointed at the main secondlife profile data folder (oh and until vwr-6199 is updated to SG/1.23 i also have 1.20.6 in the mix) some of the crashes may be from a tiny bit of skew in the cache handling so if we could have the profile redirected to say %apdata%/SnowGlobe that may be useful for bug chasing. -- Robert L Martin Please tell me there is some XML file that can be edited and its not baked in the bin _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090805/5847a389/attachment-0001.htm From ralphcampbell at sbcglobal.net Wed Aug 5 20:44:31 2009 From: ralphcampbell at sbcglobal.net (Ralph Campbell) Date: Wed, 05 Aug 2009 20:44:31 -0700 Subject: [sldev] [PATCH] changes I made to run snowglobe on Fedora 11 x86_64 Message-ID: <1249530271.2516.7.camel@host100> I was able to get snowglobe-src-viewer-1.0.2-r2451.tar.gz to compile and run on a Fedora 11 x86_64 system with the following patches. Fixed compiler warnings since I didn't know how to turn off gcc -Werror in cmake. Fixed viewer_manifest.py to copy secondlife-stripped to the right location for x86_64 builds. When I started snowglobe, I was able to log in and it popped up a dialog box to accept the terms of usage. The usage agreement didn't display and I traced this to LLSDXMLParser::Impl::parse() being used on the text which defined "" but didn't skip over it properly. LLSDXMLParser::Impl::parse() doesn't seem like a general purpose XML parser, just for reading saved configuration data. Since the parser returned an error, the "I agree" checkbox was not enabled and I couldn't make progress. I hacked around the problem by temporarily making the checkbox enabled by default. Anyway, a patch is included to skip over unknown elements. I edited tut-2008-11-30.tar.gz to include tut::result_type::skip since it wasn't defined. I guess there must be a newer version of tut somewhere. I also edited the hash_map C++ file to not warn about future incompatibility. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-warnings.patch Type: text/x-patch Size: 12703 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090805/1221766f/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-manifest.patch Type: text/x-patch Size: 940 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090805/1221766f/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-xml-parse.patch Type: text/x-patch Size: 780 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090805/1221766f/attachment-0002.bin From carlo at alinoe.com Thu Aug 6 05:12:36 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 6 Aug 2009 14:12:36 +0200 Subject: [sldev] [PATCH] changes I made to run snowglobe on Fedora 11 x86_64 In-Reply-To: <1249530271.2516.7.camel@host100> References: <1249530271.2516.7.camel@host100> Message-ID: <20090806121236.GA14115@alinoe.com> Hey Ralph, looks good. Can you create a pjira (on https://jira.secondlife.com/secure/CreateIssue!default.jspa) for this and attach your patch? Note that you might need to sign a contribution agreement for this, not sure if it will be considered minor changes. On Wed, Aug 05, 2009 at 08:44:31PM -0700, Ralph Campbell wrote: > I was able to get snowglobe-src-viewer-1.0.2-r2451.tar.gz to compile > and run on a Fedora 11 x86_64 system with the following patches. > > Fixed compiler warnings since I didn't know how to turn off gcc -Werror > in cmake. > > Fixed viewer_manifest.py to copy secondlife-stripped to the right > location for x86_64 builds. > > When I started snowglobe, I was able to log in and it popped up > a dialog box to accept the terms of usage. The usage agreement didn't > display and I traced this to LLSDXMLParser::Impl::parse() being used > on the text which defined "" but didn't skip over it properly. > LLSDXMLParser::Impl::parse() doesn't seem like a general purpose XML > parser, just for reading saved configuration data. Since the parser > returned an error, the "I agree" checkbox was not enabled and I couldn't > make progress. I hacked around the problem by temporarily making > the checkbox enabled by default. > Anyway, a patch is included to skip over unknown elements. > > I edited tut-2008-11-30.tar.gz to include tut::result_type::skip since > it wasn't defined. I guess there must be a newer version of tut > somewhere. > I also edited the hash_map C++ file to not warn about future > incompatibility. > > > Fix compiler warnings on Fedora 11 x86_64. > > --- indra/llcommon/llstring.h.old 2009-08-02 19:52:13.549420229 -0700 > +++ indra/llcommon/llstring.h 2009-08-02 19:55:15.642777031 -0700 > @@ -41,6 +41,7 @@ > #endif > > #include > +#include > > #if LL_SOLARIS > // stricmp and strnicmp do not exist on Solaris: > --- indra/llcommon/llstring.cpp.old 2009-08-02 19:04:52.374419361 -0700 > +++ indra/llcommon/llstring.cpp 2009-08-02 19:05:34.102740108 -0700 > @@ -134,7 +134,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > *outchars++ = 0xF0 | (cur_char >> 18); > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > - *outchars++ = 0x80 | cur_char & 0x3F; > + *outchars++ = 0x80 | (cur_char & 0x3F); > } > else if (cur_char < 0x4000000) > { > @@ -142,7 +142,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > *outchars++ = 0x80 | ((cur_char >> 18) & 0x3F); > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > - *outchars++ = 0x80 | cur_char & 0x3F; > + *outchars++ = 0x80 | (cur_char & 0x3F); > } > else if (cur_char < 0x80000000) > { > @@ -151,7 +151,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > *outchars++ = 0x80 | ((cur_char >> 18) & 0x3F); > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > - *outchars++ = 0x80 | cur_char & 0x3F; > + *outchars++ = 0x80 | (cur_char & 0x3F); > } > else > { > --- indra/newview/llface.cpp.old 2009-08-02 20:08:44.758441558 -0700 > +++ indra/newview/llface.cpp 2009-08-02 20:09:31.333549560 -0700 > @@ -988,7 +988,7 @@ BOOL LLFace::getGeometryVolume(const LLV > 0.75f > }; > > - if (getPoolType() != LLDrawPool::POOL_ALPHA && (LLPipeline::sRenderDeferred || LLPipeline::sRenderBump && tep->getShiny())) > + if (getPoolType() != LLDrawPool::POOL_ALPHA && (LLPipeline::sRenderDeferred || (LLPipeline::sRenderBump && tep->getShiny()))) > { > color.mV[3] = U8 (alpha[tep->getShiny()] * 255); > } > --- indra/newview/llviewerobject.cpp.old 2009-08-02 20:20:01.278799787 -0700 > +++ indra/newview/llviewerobject.cpp 2009-08-02 20:21:03.142651650 -0700 > @@ -624,8 +624,8 @@ BOOL LLViewerObject::setDrawableParent(L > > BOOL ret = mDrawable->mXform.setParent(parentp ? &parentp->mXform : NULL); > gPipeline.markRebuild(mDrawable, LLDrawable::REBUILD_VOLUME, TRUE); > - if( old_parent != parentp && > - old_parent || (parentp && parentp->isActive())) > + if( (old_parent != parentp && old_parent) || > + (parentp && parentp->isActive())) > { > // *TODO we should not be relying on setDrawable parent to call markMoved > gPipeline.markMoved(mDrawable, FALSE); > --- indra/newview/llvoavatar.cpp.old 2009-08-02 20:21:41.036419558 -0700 > +++ indra/newview/llvoavatar.cpp 2009-08-02 20:22:38.648667807 -0700 > @@ -1582,7 +1582,7 @@ BOOL LLVOAvatar::lineSegmentIntersect(co > ) > { > > - if (mIsSelf && !gAgent.needsRenderAvatar() || !LLPipeline::sPickAvatar) > + if ((mIsSelf && !gAgent.needsRenderAvatar()) || !LLPipeline::sPickAvatar) > { > return FALSE; > } > @@ -9070,9 +9070,9 @@ BOOL LLVOAvatar::updateLOD() > > LLFace* facep = mDrawable->getFace(0); > if (facep->mVertexBuffer.isNull() || > - LLVertexBuffer::sEnableVBOs && > + (LLVertexBuffer::sEnableVBOs && > ((facep->mVertexBuffer->getUsage() == GL_STATIC_DRAW ? TRUE : FALSE) != > - (facep->getPool()->getVertexShaderLevel() > 0 ? TRUE : FALSE))) > + (facep->getPool()->getVertexShaderLevel() > 0 ? TRUE : FALSE)))) > { > mDirtyMesh = TRUE; > } > --- indra/newview/llvovolume.cpp.old 2009-08-02 20:25:05.546443870 -0700 > +++ indra/newview/llvovolume.cpp 2009-08-02 20:25:53.161545016 -0700 > @@ -468,8 +468,8 @@ void LLVOVolume::updateTextureVirtualSiz > > if (face->mTextureMatrix != NULL) > { > - if (vsize < MIN_TEX_ANIM_SIZE && old_size > MIN_TEX_ANIM_SIZE || > - vsize > MIN_TEX_ANIM_SIZE && old_size < MIN_TEX_ANIM_SIZE) > + if ((vsize < MIN_TEX_ANIM_SIZE && old_size > MIN_TEX_ANIM_SIZE) || > + (vsize > MIN_TEX_ANIM_SIZE && old_size < MIN_TEX_ANIM_SIZE)) > { > gPipeline.markRebuild(mDrawable, LLDrawable::REBUILD_TCOORD, FALSE); > } > @@ -2333,7 +2333,7 @@ void LLVolumeGeometryManager::rebuildGeo > { //needs normal + binormal > bump_faces.push_back(facep); > } > - else if (te->getShiny() && LLPipeline::sRenderBump || > + else if ((te->getShiny() && LLPipeline::sRenderBump) || > !te->getFullbright()) > { //needs normal > simple_faces.push_back(facep); > --- indra/newview/llvosky.cpp.old 2009-08-02 20:23:21.098419519 -0700 > +++ indra/newview/llvosky.cpp 2009-08-02 20:24:10.443854152 -0700 > @@ -1095,10 +1095,10 @@ BOOL LLVOSky::updateSky() > mLastTotalAmbient.mV[2] - mTotalAmbient.mV[2]); > > if ( mForceUpdate > - || ((dot_lighting < LIGHT_DIRECTION_THRESHOLD) > + || (((dot_lighting < LIGHT_DIRECTION_THRESHOLD) > || (delta_color.length() > COLOR_CHANGE_THRESHOLD) > || !mInitialized) > - && !direction.isExactlyZero()) > + && !direction.isExactlyZero())) > { > mLastLightingDirection = direction; > mLastTotalAmbient = mTotalAmbient; > --- indra/newview/llspatialpartition.cpp.old 2009-08-02 20:14:50.719419513 -0700 > +++ indra/newview/llspatialpartition.cpp 2009-08-02 20:15:22.499425689 -0700 > @@ -1671,9 +1671,9 @@ public: > virtual bool earlyFail(LLSpatialGroup* group) > { > if (mResult || //already found a node, don't check any more > - group->mOctreeNode->getParent() && //never occlusion cull the root node > + (group->mOctreeNode->getParent() && //never occlusion cull the root node > LLPipeline::sUseOcclusion && //ignore occlusion if disabled > - group->isState(LLSpatialGroup::OCCLUDED)) > + group->isState(LLSpatialGroup::OCCLUDED))) > { > return true; > } > --- indra/newview/lldrawpoolbump.cpp.old 2009-08-02 20:04:53.718419420 -0700 > +++ indra/newview/lldrawpoolbump.cpp 2009-08-02 20:08:10.074442399 -0700 > @@ -309,8 +309,8 @@ void LLDrawPoolBump::endRenderPass(S32 p > void LLDrawPoolBump::beginShiny(bool invisible) > { > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > { > return; > } > @@ -384,8 +384,8 @@ void LLDrawPoolBump::beginShiny(bool inv > void LLDrawPoolBump::renderShiny(bool invisible) > { > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > { > return; > } > @@ -411,8 +411,8 @@ void LLDrawPoolBump::renderShiny(bool in > void LLDrawPoolBump::endShiny(bool invisible) > { > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > { > return; > } > --- indra/newview/lltoolpie.cpp.old 2009-08-02 20:16:16.273667975 -0700 > +++ indra/newview/lltoolpie.cpp 2009-08-02 20:16:37.753481495 -0700 > @@ -189,8 +189,8 @@ BOOL LLToolPie::pickAndShowMenu(BOOL alw > } // else nothing (fall through to touch) > > case CLICK_ACTION_PAY: > - if (object && object->flagTakesMoney() > - || parent && parent->flagTakesMoney()) > + if ((object && object->flagTakesMoney()) > + || (parent && parent->flagTakesMoney())) > { > // pay event goes to object actually clicked on > mClickActionObject = object; > --- indra/newview/llviewerkeyboard.cpp.old 2009-08-02 20:18:09.417419363 -0700 > +++ indra/newview/llviewerkeyboard.cpp 2009-08-02 20:19:28.185424042 -0700 > @@ -683,7 +683,7 @@ BOOL LLViewerKeyboard::bindKey(const S32 > if (idx >=2 && idx <= 12) > { > U32 keyidx = ((mask<<16)|key); > - (mRemapKeys[mode])[keyidx] = ((0<<16)|KEY_F1+(idx-1)); > + (mRemapKeys[mode])[keyidx] = ((0<<16)|(KEY_F1+(idx-1))); > return TRUE; > } > } > --- indra/newview/llhudeffectlookat.cpp.old 2009-08-02 20:11:20.196419425 -0700 > +++ indra/newview/llhudeffectlookat.cpp 2009-08-02 20:12:35.818564610 -0700 > @@ -421,8 +421,8 @@ BOOL LLHUDEffectLookAt::setLookAt(ELookA > BOOL lookAtChanged = (target_type != mTargetType) || (object != mTargetObject); > > // lookat position has moved a certain amount and we haven't just sent an update > - lookAtChanged = lookAtChanged || (dist_vec(position, mLastSentOffsetGlobal) > MIN_DELTAPOS_FOR_UPDATE) && > - ((current_time - mLastSendTime) > (1.f / MAX_SENDS_PER_SEC)); > + lookAtChanged = lookAtChanged || ((dist_vec(position, mLastSentOffsetGlobal) > MIN_DELTAPOS_FOR_UPDATE) && > + ((current_time - mLastSendTime) > (1.f / MAX_SENDS_PER_SEC))); > > if (lookAtChanged) > { > --- indra/newview/llvosky.h.old 2009-08-02 19:57:47.632419969 -0700 > +++ indra/newview/llvosky.h 2009-08-02 20:01:46.860842458 -0700 > @@ -147,7 +147,7 @@ protected: > > static S32 getResolution() { return sResolution; } > static S32 getCurrent() { return sCurrent; } > - static S32 stepCurrent() { return (sCurrent = ++sCurrent % 2); } > + static S32 stepCurrent() { return (sCurrent = (sCurrent + 1) % 2); } > static S32 getNext() { return ((sCurrent+1) % 2); } > static S32 getWhich(const BOOL curr) { return curr ? sCurrent : getNext(); } > > --- indra/newview/llviewercamera.cpp.old 2009-08-02 20:17:11.132435433 -0700 > +++ indra/newview/llviewercamera.cpp 2009-08-02 20:17:32.135718440 -0700 > @@ -769,8 +769,8 @@ BOOL LLViewerCamera::areVertsVisible(LLV > > BOOL in_frustum = pointInFrustum(LLVector3(vec)) > 0; > > - if ( !in_frustum && all_verts || > - in_frustum && !all_verts) > + if ((!in_frustum && all_verts) || > + (in_frustum && !all_verts)) > { > return !all_verts; > } > --- indra/llmessage/lliobuffer.cpp.old 2009-08-02 19:28:44.739420260 -0700 > +++ indra/llmessage/lliobuffer.cpp 2009-08-02 19:29:26.290441332 -0700 > @@ -87,7 +87,7 @@ LLIOPipe::EStatus LLIOBuffer::seek(LLIOB > { > case READ: > if(((delta >= 0) && ((mReadHead + delta) <= mWriteHead)) > - || (delta < 0) && ((mReadHead + delta) >= mBuffer)) > + || ((delta < 0) && ((mReadHead + delta) >= mBuffer))) > { > mReadHead += delta; > status = STATUS_OK; > @@ -95,7 +95,7 @@ LLIOPipe::EStatus LLIOBuffer::seek(LLIOB > break; > case WRITE: > if(((delta >= 0) && ((mWriteHead + delta) < (mBuffer + mBufferSize))) > - || (delta < 0) && ((mWriteHead + delta) > mReadHead)) > + || ((delta < 0) && ((mWriteHead + delta) > mReadHead))) > { > mWriteHead += delta; > status = STATUS_OK; > --- indra/llui/llmenugl.cpp.old 2009-08-02 19:32:21.227489696 -0700 > +++ indra/llui/llmenugl.cpp 2009-08-02 19:32:47.332501176 -0700 > @@ -2413,8 +2413,8 @@ void LLMenuGL::createJumpKeys() > { > char jump_key = uppercase_word[i]; > > - if (LLStringOps::isDigit(jump_key) || LLStringOps::isUpper(jump_key) && > - mJumpKeys.find(jump_key) == mJumpKeys.end()) > + if (LLStringOps::isDigit(jump_key) || (LLStringOps::isUpper(jump_key) && > + mJumpKeys.find(jump_key) == mJumpKeys.end())) > { > mJumpKeys.insert(std::pair(jump_key, (*item_it))); > (*item_it)->setJumpKey(jump_key); > --- indra/llmath/v3math.h.old 2009-08-02 19:01:55.634419501 -0700 > +++ indra/llmath/v3math.h 2009-08-02 19:03:39.578426127 -0700 > @@ -411,8 +411,8 @@ inline bool operator<(const LLVector3 &a > return (a.mV[0] < b.mV[0] > || (a.mV[0] == b.mV[0] > && (a.mV[1] < b.mV[1] > - || (a.mV[1] == b.mV[1]) > - && a.mV[2] < b.mV[2]))); > + || ((a.mV[1] == b.mV[1]) > + && a.mV[2] < b.mV[2])))); > } > > inline const LLVector3& operator+=(LLVector3 &a, const LLVector3 &b) > --- indra/llrender/llrendertarget.cpp.old 2009-08-02 19:29:49.945485691 -0700 > +++ indra/llrender/llrendertarget.cpp 2009-08-02 19:30:30.470549575 -0700 > @@ -139,7 +139,7 @@ void LLRenderTarget::addColorAttachment( > > U32 offset = mTex.size(); > if (offset >= 4 || > - offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers)) > + (offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers))) > { > llerrs << "Too many color attachments!" << llendl; > } > @@ -608,7 +608,7 @@ void LLMultisampleBuffer::addColorAttach > > U32 offset = mTex.size(); > if (offset >= 4 || > - offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers)) > + (offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers))) > { > llerrs << "Too many color attachments!" << llendl; > } > --- indra/newview/viewer_manifest.py.old 2009-08-03 19:35:51.223659265 -0700 > +++ indra/newview/viewer_manifest.py 2009-08-04 23:56:25.562523297 -0700 > @@ -763,7 +763,7 @@ class Linux_i686Manifest(LinuxManifest): > class Linux_x86_64Manifest(LinuxManifest): > def construct(self): > super(Linux_x86_64Manifest, self).construct() > - self.path("secondlife-stripped",self.get_linuxbin()) > + self.path("secondlife-stripped","bin/"+self.binary_name()) > self.path("../linux_crash_logger/linux-crash-logger-stripped","linux-crash-logger.bin") > self.path("linux_tools/launch_url.sh","launch_url.sh") > if self.prefix("res-sdl"): > @@ -772,7 +772,7 @@ class Linux_x86_64Manifest(LinuxManifest > self.end_prefix("res-sdl") > > self.path("featuretable_linux.txt") > - self.path("secondlife-i686.supp") > + #self.path("secondlife-i686.supp") > > if __name__ == "__main__": > main() > --- indra/llcommon/llsdserialize_xml.cpp.old 2009-08-04 19:34:36.119613187 -0700 > +++ indra/llcommon/llsdserialize_xml.cpp 2009-08-05 08:23:04.403267737 -0700 > @@ -408,7 +408,9 @@ S32 LLSDXMLParser::Impl::parse(std::istr > { > ((char*) buffer)[count ? count - 1 : 0] = '\0'; > } > - llinfos << "LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:" << (char*) buffer << llendl; > + llinfos << "LLSDXMLParser::Impl::parse: XML_STATUS_ERROR (" << > + XML_GetErrorCode(mParser) << ") parsing :" << > + (char*) buffer << llendl; > data = LLSD(); > return LLSDParser::PARSE_FAILURE; > } > @@ -623,6 +625,9 @@ void LLSDXMLParser::Impl::startElementHa > break; > } > > + case ELEMENT_UNKNOWN: > + return startSkipping(); > + > default: > // all rest are values, fall through > ; > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From aleric.inglewood at gmail.com Thu Aug 6 06:58:35 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 6 Aug 2009 15:58:35 +0200 Subject: [sldev] I finished VWR-14914 patch; any testers? Message-ID: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> Hi, I *finally* finished VWR-14914... this must have been the one that I worked on most time on... weeks. If you want to test the patch, you might want to use the attached (to the jira) VWR-14914-v3-20090806-debug.diff instead of plain VWR-14914.diff because the first adds nice colors to the sound beacon :) After applying this patch do View --> Beacons and only select "sound sources". The colors have the following meaning: * blue: non-playing * cyan: non-playing / muted * red: playing and gain 0 * yellow: playing with 0 < gain < 1 * green: playing and gain 1 Yellow has a width between 1 and the beacon width that you set, proportional to the gain. From ralphcampbell at sbcglobal.net Thu Aug 6 08:22:45 2009 From: ralphcampbell at sbcglobal.net (Ralph Campbell) Date: Thu, 06 Aug 2009 08:22:45 -0700 Subject: [sldev] [PATCH] changes I made to run snowglobe on Fedora 11 x86_64 In-Reply-To: <20090806121236.GA14115@alinoe.com> References: <1249530271.2516.7.camel@host100> <20090806121236.GA14115@alinoe.com> Message-ID: <1249572165.4337.3.camel@host100> OK. I created SNOW-174. BTW, it looks like the Second Life Project Contribution Agreement conflicts with the GPL. I'm just contributing like any other GPL project. I'm not a lawyer though :-) On Thu, 2009-08-06 at 14:12 +0200, Carlo Wood wrote: > Hey Ralph, looks good. > > Can you create a pjira (on https://jira.secondlife.com/secure/CreateIssue!default.jspa) > for this and attach your patch? > > Note that you might need to sign a contribution agreement for this, > not sure if it will be considered minor changes. > > On Wed, Aug 05, 2009 at 08:44:31PM -0700, Ralph Campbell wrote: > > I was able to get snowglobe-src-viewer-1.0.2-r2451.tar.gz to compile > > and run on a Fedora 11 x86_64 system with the following patches. > > > > Fixed compiler warnings since I didn't know how to turn off gcc -Werror > > in cmake. > > > > Fixed viewer_manifest.py to copy secondlife-stripped to the right > > location for x86_64 builds. > > > > When I started snowglobe, I was able to log in and it popped up > > a dialog box to accept the terms of usage. The usage agreement didn't > > display and I traced this to LLSDXMLParser::Impl::parse() being used > > on the text which defined "" but didn't skip over it properly. > > LLSDXMLParser::Impl::parse() doesn't seem like a general purpose XML > > parser, just for reading saved configuration data. Since the parser > > returned an error, the "I agree" checkbox was not enabled and I couldn't > > make progress. I hacked around the problem by temporarily making > > the checkbox enabled by default. > > Anyway, a patch is included to skip over unknown elements. > > > > I edited tut-2008-11-30.tar.gz to include tut::result_type::skip since > > it wasn't defined. I guess there must be a newer version of tut > > somewhere. > > I also edited the hash_map C++ file to not warn about future > > incompatibility. > > > > > > > Fix compiler warnings on Fedora 11 x86_64. > > > > --- indra/llcommon/llstring.h.old 2009-08-02 19:52:13.549420229 -0700 > > +++ indra/llcommon/llstring.h 2009-08-02 19:55:15.642777031 -0700 > > @@ -41,6 +41,7 @@ > > #endif > > > > #include > > +#include > > > > #if LL_SOLARIS > > // stricmp and strnicmp do not exist on Solaris: > > --- indra/llcommon/llstring.cpp.old 2009-08-02 19:04:52.374419361 -0700 > > +++ indra/llcommon/llstring.cpp 2009-08-02 19:05:34.102740108 -0700 > > @@ -134,7 +134,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > > *outchars++ = 0xF0 | (cur_char >> 18); > > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > > - *outchars++ = 0x80 | cur_char & 0x3F; > > + *outchars++ = 0x80 | (cur_char & 0x3F); > > } > > else if (cur_char < 0x4000000) > > { > > @@ -142,7 +142,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > > *outchars++ = 0x80 | ((cur_char >> 18) & 0x3F); > > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > > - *outchars++ = 0x80 | cur_char & 0x3F; > > + *outchars++ = 0x80 | (cur_char & 0x3F); > > } > > else if (cur_char < 0x80000000) > > { > > @@ -151,7 +151,7 @@ S32 wchar_to_utf8chars(llwchar in_char, > > *outchars++ = 0x80 | ((cur_char >> 18) & 0x3F); > > *outchars++ = 0x80 | ((cur_char >> 12) & 0x3F); > > *outchars++ = 0x80 | ((cur_char >> 6) & 0x3F); > > - *outchars++ = 0x80 | cur_char & 0x3F; > > + *outchars++ = 0x80 | (cur_char & 0x3F); > > } > > else > > { > > --- indra/newview/llface.cpp.old 2009-08-02 20:08:44.758441558 -0700 > > +++ indra/newview/llface.cpp 2009-08-02 20:09:31.333549560 -0700 > > @@ -988,7 +988,7 @@ BOOL LLFace::getGeometryVolume(const LLV > > 0.75f > > }; > > > > - if (getPoolType() != LLDrawPool::POOL_ALPHA && (LLPipeline::sRenderDeferred || LLPipeline::sRenderBump && tep->getShiny())) > > + if (getPoolType() != LLDrawPool::POOL_ALPHA && (LLPipeline::sRenderDeferred || (LLPipeline::sRenderBump && tep->getShiny()))) > > { > > color.mV[3] = U8 (alpha[tep->getShiny()] * 255); > > } > > --- indra/newview/llviewerobject.cpp.old 2009-08-02 20:20:01.278799787 -0700 > > +++ indra/newview/llviewerobject.cpp 2009-08-02 20:21:03.142651650 -0700 > > @@ -624,8 +624,8 @@ BOOL LLViewerObject::setDrawableParent(L > > > > BOOL ret = mDrawable->mXform.setParent(parentp ? &parentp->mXform : NULL); > > gPipeline.markRebuild(mDrawable, LLDrawable::REBUILD_VOLUME, TRUE); > > - if( old_parent != parentp && > > - old_parent || (parentp && parentp->isActive())) > > + if( (old_parent != parentp && old_parent) || > > + (parentp && parentp->isActive())) > > { > > // *TODO we should not be relying on setDrawable parent to call markMoved > > gPipeline.markMoved(mDrawable, FALSE); > > --- indra/newview/llvoavatar.cpp.old 2009-08-02 20:21:41.036419558 -0700 > > +++ indra/newview/llvoavatar.cpp 2009-08-02 20:22:38.648667807 -0700 > > @@ -1582,7 +1582,7 @@ BOOL LLVOAvatar::lineSegmentIntersect(co > > ) > > { > > > > - if (mIsSelf && !gAgent.needsRenderAvatar() || !LLPipeline::sPickAvatar) > > + if ((mIsSelf && !gAgent.needsRenderAvatar()) || !LLPipeline::sPickAvatar) > > { > > return FALSE; > > } > > @@ -9070,9 +9070,9 @@ BOOL LLVOAvatar::updateLOD() > > > > LLFace* facep = mDrawable->getFace(0); > > if (facep->mVertexBuffer.isNull() || > > - LLVertexBuffer::sEnableVBOs && > > + (LLVertexBuffer::sEnableVBOs && > > ((facep->mVertexBuffer->getUsage() == GL_STATIC_DRAW ? TRUE : FALSE) != > > - (facep->getPool()->getVertexShaderLevel() > 0 ? TRUE : FALSE))) > > + (facep->getPool()->getVertexShaderLevel() > 0 ? TRUE : FALSE)))) > > { > > mDirtyMesh = TRUE; > > } > > --- indra/newview/llvovolume.cpp.old 2009-08-02 20:25:05.546443870 -0700 > > +++ indra/newview/llvovolume.cpp 2009-08-02 20:25:53.161545016 -0700 > > @@ -468,8 +468,8 @@ void LLVOVolume::updateTextureVirtualSiz > > > > if (face->mTextureMatrix != NULL) > > { > > - if (vsize < MIN_TEX_ANIM_SIZE && old_size > MIN_TEX_ANIM_SIZE || > > - vsize > MIN_TEX_ANIM_SIZE && old_size < MIN_TEX_ANIM_SIZE) > > + if ((vsize < MIN_TEX_ANIM_SIZE && old_size > MIN_TEX_ANIM_SIZE) || > > + (vsize > MIN_TEX_ANIM_SIZE && old_size < MIN_TEX_ANIM_SIZE)) > > { > > gPipeline.markRebuild(mDrawable, LLDrawable::REBUILD_TCOORD, FALSE); > > } > > @@ -2333,7 +2333,7 @@ void LLVolumeGeometryManager::rebuildGeo > > { //needs normal + binormal > > bump_faces.push_back(facep); > > } > > - else if (te->getShiny() && LLPipeline::sRenderBump || > > + else if ((te->getShiny() && LLPipeline::sRenderBump) || > > !te->getFullbright()) > > { //needs normal > > simple_faces.push_back(facep); > > --- indra/newview/llvosky.cpp.old 2009-08-02 20:23:21.098419519 -0700 > > +++ indra/newview/llvosky.cpp 2009-08-02 20:24:10.443854152 -0700 > > @@ -1095,10 +1095,10 @@ BOOL LLVOSky::updateSky() > > mLastTotalAmbient.mV[2] - mTotalAmbient.mV[2]); > > > > if ( mForceUpdate > > - || ((dot_lighting < LIGHT_DIRECTION_THRESHOLD) > > + || (((dot_lighting < LIGHT_DIRECTION_THRESHOLD) > > || (delta_color.length() > COLOR_CHANGE_THRESHOLD) > > || !mInitialized) > > - && !direction.isExactlyZero()) > > + && !direction.isExactlyZero())) > > { > > mLastLightingDirection = direction; > > mLastTotalAmbient = mTotalAmbient; > > --- indra/newview/llspatialpartition.cpp.old 2009-08-02 20:14:50.719419513 -0700 > > +++ indra/newview/llspatialpartition.cpp 2009-08-02 20:15:22.499425689 -0700 > > @@ -1671,9 +1671,9 @@ public: > > virtual bool earlyFail(LLSpatialGroup* group) > > { > > if (mResult || //already found a node, don't check any more > > - group->mOctreeNode->getParent() && //never occlusion cull the root node > > + (group->mOctreeNode->getParent() && //never occlusion cull the root node > > LLPipeline::sUseOcclusion && //ignore occlusion if disabled > > - group->isState(LLSpatialGroup::OCCLUDED)) > > + group->isState(LLSpatialGroup::OCCLUDED))) > > { > > return true; > > } > > --- indra/newview/lldrawpoolbump.cpp.old 2009-08-02 20:04:53.718419420 -0700 > > +++ indra/newview/lldrawpoolbump.cpp 2009-08-02 20:08:10.074442399 -0700 > > @@ -309,8 +309,8 @@ void LLDrawPoolBump::endRenderPass(S32 p > > void LLDrawPoolBump::beginShiny(bool invisible) > > { > > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > > { > > return; > > } > > @@ -384,8 +384,8 @@ void LLDrawPoolBump::beginShiny(bool inv > > void LLDrawPoolBump::renderShiny(bool invisible) > > { > > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > > { > > return; > > } > > @@ -411,8 +411,8 @@ void LLDrawPoolBump::renderShiny(bool in > > void LLDrawPoolBump::endShiny(bool invisible) > > { > > LLFastTimer t(LLFastTimer::FTM_RENDER_SHINY); > > - if (!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)|| > > - invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY)) > > + if ((!invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_SHINY)) || > > + (invisible && !gPipeline.hasRenderBatches(LLRenderPass::PASS_INVISI_SHINY))) > > { > > return; > > } > > --- indra/newview/lltoolpie.cpp.old 2009-08-02 20:16:16.273667975 -0700 > > +++ indra/newview/lltoolpie.cpp 2009-08-02 20:16:37.753481495 -0700 > > @@ -189,8 +189,8 @@ BOOL LLToolPie::pickAndShowMenu(BOOL alw > > } // else nothing (fall through to touch) > > > > case CLICK_ACTION_PAY: > > - if (object && object->flagTakesMoney() > > - || parent && parent->flagTakesMoney()) > > + if ((object && object->flagTakesMoney()) > > + || (parent && parent->flagTakesMoney())) > > { > > // pay event goes to object actually clicked on > > mClickActionObject = object; > > --- indra/newview/llviewerkeyboard.cpp.old 2009-08-02 20:18:09.417419363 -0700 > > +++ indra/newview/llviewerkeyboard.cpp 2009-08-02 20:19:28.185424042 -0700 > > @@ -683,7 +683,7 @@ BOOL LLViewerKeyboard::bindKey(const S32 > > if (idx >=2 && idx <= 12) > > { > > U32 keyidx = ((mask<<16)|key); > > - (mRemapKeys[mode])[keyidx] = ((0<<16)|KEY_F1+(idx-1)); > > + (mRemapKeys[mode])[keyidx] = ((0<<16)|(KEY_F1+(idx-1))); > > return TRUE; > > } > > } > > --- indra/newview/llhudeffectlookat.cpp.old 2009-08-02 20:11:20.196419425 -0700 > > +++ indra/newview/llhudeffectlookat.cpp 2009-08-02 20:12:35.818564610 -0700 > > @@ -421,8 +421,8 @@ BOOL LLHUDEffectLookAt::setLookAt(ELookA > > BOOL lookAtChanged = (target_type != mTargetType) || (object != mTargetObject); > > > > // lookat position has moved a certain amount and we haven't just sent an update > > - lookAtChanged = lookAtChanged || (dist_vec(position, mLastSentOffsetGlobal) > MIN_DELTAPOS_FOR_UPDATE) && > > - ((current_time - mLastSendTime) > (1.f / MAX_SENDS_PER_SEC)); > > + lookAtChanged = lookAtChanged || ((dist_vec(position, mLastSentOffsetGlobal) > MIN_DELTAPOS_FOR_UPDATE) && > > + ((current_time - mLastSendTime) > (1.f / MAX_SENDS_PER_SEC))); > > > > if (lookAtChanged) > > { > > --- indra/newview/llvosky.h.old 2009-08-02 19:57:47.632419969 -0700 > > +++ indra/newview/llvosky.h 2009-08-02 20:01:46.860842458 -0700 > > @@ -147,7 +147,7 @@ protected: > > > > static S32 getResolution() { return sResolution; } > > static S32 getCurrent() { return sCurrent; } > > - static S32 stepCurrent() { return (sCurrent = ++sCurrent % 2); } > > + static S32 stepCurrent() { return (sCurrent = (sCurrent + 1) % 2); } > > static S32 getNext() { return ((sCurrent+1) % 2); } > > static S32 getWhich(const BOOL curr) { return curr ? sCurrent : getNext(); } > > > > --- indra/newview/llviewercamera.cpp.old 2009-08-02 20:17:11.132435433 -0700 > > +++ indra/newview/llviewercamera.cpp 2009-08-02 20:17:32.135718440 -0700 > > @@ -769,8 +769,8 @@ BOOL LLViewerCamera::areVertsVisible(LLV > > > > BOOL in_frustum = pointInFrustum(LLVector3(vec)) > 0; > > > > - if ( !in_frustum && all_verts || > > - in_frustum && !all_verts) > > + if ((!in_frustum && all_verts) || > > + (in_frustum && !all_verts)) > > { > > return !all_verts; > > } > > --- indra/llmessage/lliobuffer.cpp.old 2009-08-02 19:28:44.739420260 -0700 > > +++ indra/llmessage/lliobuffer.cpp 2009-08-02 19:29:26.290441332 -0700 > > @@ -87,7 +87,7 @@ LLIOPipe::EStatus LLIOBuffer::seek(LLIOB > > { > > case READ: > > if(((delta >= 0) && ((mReadHead + delta) <= mWriteHead)) > > - || (delta < 0) && ((mReadHead + delta) >= mBuffer)) > > + || ((delta < 0) && ((mReadHead + delta) >= mBuffer))) > > { > > mReadHead += delta; > > status = STATUS_OK; > > @@ -95,7 +95,7 @@ LLIOPipe::EStatus LLIOBuffer::seek(LLIOB > > break; > > case WRITE: > > if(((delta >= 0) && ((mWriteHead + delta) < (mBuffer + mBufferSize))) > > - || (delta < 0) && ((mWriteHead + delta) > mReadHead)) > > + || ((delta < 0) && ((mWriteHead + delta) > mReadHead))) > > { > > mWriteHead += delta; > > status = STATUS_OK; > > --- indra/llui/llmenugl.cpp.old 2009-08-02 19:32:21.227489696 -0700 > > +++ indra/llui/llmenugl.cpp 2009-08-02 19:32:47.332501176 -0700 > > @@ -2413,8 +2413,8 @@ void LLMenuGL::createJumpKeys() > > { > > char jump_key = uppercase_word[i]; > > > > - if (LLStringOps::isDigit(jump_key) || LLStringOps::isUpper(jump_key) && > > - mJumpKeys.find(jump_key) == mJumpKeys.end()) > > + if (LLStringOps::isDigit(jump_key) || (LLStringOps::isUpper(jump_key) && > > + mJumpKeys.find(jump_key) == mJumpKeys.end())) > > { > > mJumpKeys.insert(std::pair(jump_key, (*item_it))); > > (*item_it)->setJumpKey(jump_key); > > --- indra/llmath/v3math.h.old 2009-08-02 19:01:55.634419501 -0700 > > +++ indra/llmath/v3math.h 2009-08-02 19:03:39.578426127 -0700 > > @@ -411,8 +411,8 @@ inline bool operator<(const LLVector3 &a > > return (a.mV[0] < b.mV[0] > > || (a.mV[0] == b.mV[0] > > && (a.mV[1] < b.mV[1] > > - || (a.mV[1] == b.mV[1]) > > - && a.mV[2] < b.mV[2]))); > > + || ((a.mV[1] == b.mV[1]) > > + && a.mV[2] < b.mV[2])))); > > } > > > > inline const LLVector3& operator+=(LLVector3 &a, const LLVector3 &b) > > --- indra/llrender/llrendertarget.cpp.old 2009-08-02 19:29:49.945485691 -0700 > > +++ indra/llrender/llrendertarget.cpp 2009-08-02 19:30:30.470549575 -0700 > > @@ -139,7 +139,7 @@ void LLRenderTarget::addColorAttachment( > > > > U32 offset = mTex.size(); > > if (offset >= 4 || > > - offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers)) > > + (offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers))) > > { > > llerrs << "Too many color attachments!" << llendl; > > } > > @@ -608,7 +608,7 @@ void LLMultisampleBuffer::addColorAttach > > > > U32 offset = mTex.size(); > > if (offset >= 4 || > > - offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers)) > > + (offset > 0 && (mFBO == 0 || !gGLManager.mHasDrawBuffers))) > > { > > llerrs << "Too many color attachments!" << llendl; > > } > > > --- indra/newview/viewer_manifest.py.old 2009-08-03 19:35:51.223659265 -0700 > > +++ indra/newview/viewer_manifest.py 2009-08-04 23:56:25.562523297 -0700 > > @@ -763,7 +763,7 @@ class Linux_i686Manifest(LinuxManifest): > > class Linux_x86_64Manifest(LinuxManifest): > > def construct(self): > > super(Linux_x86_64Manifest, self).construct() > > - self.path("secondlife-stripped",self.get_linuxbin()) > > + self.path("secondlife-stripped","bin/"+self.binary_name()) > > self.path("../linux_crash_logger/linux-crash-logger-stripped","linux-crash-logger.bin") > > self.path("linux_tools/launch_url.sh","launch_url.sh") > > if self.prefix("res-sdl"): > > @@ -772,7 +772,7 @@ class Linux_x86_64Manifest(LinuxManifest > > self.end_prefix("res-sdl") > > > > self.path("featuretable_linux.txt") > > - self.path("secondlife-i686.supp") > > + #self.path("secondlife-i686.supp") > > > > if __name__ == "__main__": > > main() > > > --- indra/llcommon/llsdserialize_xml.cpp.old 2009-08-04 19:34:36.119613187 -0700 > > +++ indra/llcommon/llsdserialize_xml.cpp 2009-08-05 08:23:04.403267737 -0700 > > @@ -408,7 +408,9 @@ S32 LLSDXMLParser::Impl::parse(std::istr > > { > > ((char*) buffer)[count ? count - 1 : 0] = '\0'; > > } > > - llinfos << "LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:" << (char*) buffer << llendl; > > + llinfos << "LLSDXMLParser::Impl::parse: XML_STATUS_ERROR (" << > > + XML_GetErrorCode(mParser) << ") parsing :" << > > + (char*) buffer << llendl; > > data = LLSD(); > > return LLSDParser::PARSE_FAILURE; > > } > > @@ -623,6 +625,9 @@ void LLSDXMLParser::Impl::startElementHa > > break; > > } > > > > + case ELEMENT_UNKNOWN: > > + return startSkipping(); > > + > > default: > > // all rest are values, fall through > > ; > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > From robla at lindenlab.com Thu Aug 6 09:30:29 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 06 Aug 2009 09:30:29 -0700 Subject: [sldev] Contribution agreement (Re: [PATCH] changes I made to run snowglobe on Fedora11 x86_64) In-Reply-To: <1249572165.4337.3.camel@host100> References: <1249530271.2516.7.camel@host100><20090806121236.GA14115@alinoe.com> <1249572165.4337.3.camel@host100> Message-ID: <4A7B0525.2050408@lindenlab.com> On 08/06/2009 08:22 AM, Ralph Campbell wrote: > OK. I created SNOW-174. > > BTW, it looks like the Second Life Project Contribution Agreement > conflicts with the GPL. I'm just contributing like any other GPL > project. I'm not a lawyer though :-) > Hi Ralph, Thanks for taking the time to send in the fixes! The contributor agreement doesn't conflict with the GPL. In fact, the Free Software Foundation also requires a very similar contribution agreement to contribute to FSF-maintained projects. It looks like this is a series of small bug fixes that may not require us to jump through that hoop, though. We'll evaluate this case when we take a deeper look at SNOW-174 Rob From melinda at superliminal.com Thu Aug 6 11:23:11 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 06 Aug 2009 11:23:11 -0700 Subject: [sldev] I finished VWR-14914 patch; any testers? In-Reply-To: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> References: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> Message-ID: <4A7B1F8F.9020803@superliminal.com> I don't think you should change the line width as long as there is a user control for that. Otherwise I expect that people will report bugs against sound lines that don't respect the width they set. There are plenty of other attributes that you can modify instead. Maybe saturation or the spacings between dashed lines? -Melinda Aleric Inglewood wrote: > Hi, I *finally* finished VWR-14914... this must have been the one that > I worked on > most time on... weeks. > > If you want to test the patch, you might want to use the attached (to the jira) > VWR-14914-v3-20090806-debug.diff instead of plain VWR-14914.diff > because the first adds nice colors to the sound beacon :) > > After applying this patch do View --> Beacons and only select "sound sources". > > The colors have the following meaning: > > * blue: non-playing > * cyan: non-playing / muted > * red: playing and gain 0 > * yellow: playing with 0 < gain < 1 > * green: playing and gain 1 > > Yellow has a width between 1 and the beacon width that you set, > proportional to the gain. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From kelly at lindenlab.com Thu Aug 6 11:34:33 2009 From: kelly at lindenlab.com (Kelly Linden) Date: Thu, 6 Aug 2009 11:34:33 -0700 Subject: [sldev] I finished VWR-14914 patch; any testers? In-Reply-To: <4A7B1F8F.9020803@superliminal.com> References: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> <4A7B1F8F.9020803@superliminal.com> Message-ID: It sounds like the intent is not to commit the debug code. That said, I like the variable width lines concept. Just because we have a setting for adjusting the default width doesn't mean we should ignore width as a possible feedback mechanism. Total side issue though, and not pertinent to the bug fix at hand. Aleric: My comments on the patch are in the jira. - Kelly On Thu, Aug 6, 2009 at 11:23 AM, Melinda Green wrote: > I don't think you should change the line width as long as there is a > user control for that. Otherwise I expect that people will report bugs > against sound lines that don't respect the width they set. There are > plenty of other attributes that you can modify instead. Maybe saturation > or the spacings between dashed lines? > > -Melinda > > Aleric Inglewood wrote: >> Hi, I *finally* finished VWR-14914... this must have been the one that >> I worked on >> most time on... weeks. >> >> If you want to test the patch, you might want to use the attached (to the jira) >> VWR-14914-v3-20090806-debug.diff instead of plain VWR-14914.diff >> because the first adds nice colors to the sound beacon :) >> >> After applying this patch do View --> Beacons and only select "sound sources". >> >> The colors have the following meaning: >> >> ? ? * blue: non-playing >> ? ? * cyan: non-playing / muted >> ? ? * red: playing and gain 0 >> ? ? * yellow: playing with 0 < gain < 1 >> ? ? * green: playing and gain 1 >> >> Yellow has a width between 1 and the beacon width that you set, >> proportional to the gain. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From enterthenamehere at gmail.com Thu Aug 6 11:46:28 2009 From: enterthenamehere at gmail.com (EnterTheNameHere) Date: Thu, 06 Aug 2009 20:46:28 +0200 Subject: [sldev] Detection of who is editing prim Message-ID: <4A7B2504.2080401@gmail.com> Hello, I have a question, if it is possible to get the UUID or name of the avatar, that right clicks / edit a prim? We play a football( soccer ) game, where the ball is scripted to say who clicks the ball, but avatars can still right click the ball and the ball stuck on place that can break an attack on goal etc.. When the avatar( griefer ) do it quickly I don't know a way how to detect who did it. I was able to find out, that the server sends to the client start and end position of the particle beam effect so client is then able to render the line from avatar to the prim, but if I'm right it don't send the UUID / name of the avatar. Have I to look on the start position of the beam to find out if there is avatar and then get his name, or is there an easier way to do it? Thanks in advance, EnterTheNameHere Galicia From melinda at superliminal.com Thu Aug 6 12:02:09 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 06 Aug 2009 12:02:09 -0700 Subject: [sldev] I finished VWR-14914 patch; any testers? In-Reply-To: References: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> <4A7B1F8F.9020803@superliminal.com> Message-ID: <4A7B28B1.70401@superliminal.com> If the intent is not to commit it, then anything goes of course. I definitely like the idea of improving the beacons functionality though and if people come up with useful improvements I'd love to see the attempt made to fold them in. The first step is VWR-9138 which is intended to bring clarity to the UI but using the current 3D graphics. The second step should be to improve the 3D graphics. I believe it was Dave P who suggested that the GL line graphics should be replaced with polygonal treatments, and then there's no end to the fun we can have to distinguish the different beacon types and their various sub-features. At that point the "beacon width" feature should probably become "beacon size" or something which simply makes all beacons more or less prominent. It also occurs to me that we can't change the color for the sound beacons because color is used to indicate beacon type, but again, line style and saturation are still available. -Melinda Kelly Linden wrote: > It sounds like the intent is not to commit the debug code. That said, > I like the variable width lines concept. Just because we have a > setting for adjusting the default width doesn't mean we should ignore > width as a possible feedback mechanism. Total side issue though, and > not pertinent to the bug fix at hand. > > Aleric: My comments on the patch are in the jira. > > - Kelly > > On Thu, Aug 6, 2009 at 11:23 AM, Melinda Green wrote: > >> I don't think you should change the line width as long as there is a >> user control for that. Otherwise I expect that people will report bugs >> against sound lines that don't respect the width they set. There are >> plenty of other attributes that you can modify instead. Maybe saturation >> or the spacings between dashed lines? >> >> -Melinda >> >> Aleric Inglewood wrote: >> >>> Hi, I *finally* finished VWR-14914... this must have been the one that >>> I worked on >>> most time on... weeks. >>> >>> If you want to test the patch, you might want to use the attached (to the jira) >>> VWR-14914-v3-20090806-debug.diff instead of plain VWR-14914.diff >>> because the first adds nice colors to the sound beacon :) >>> >>> After applying this patch do View --> Beacons and only select "sound sources". >>> >>> The colors have the following meaning: >>> >>> * blue: non-playing >>> * cyan: non-playing / muted >>> * red: playing and gain 0 >>> * yellow: playing with 0 < gain < 1 >>> * green: playing and gain 1 >>> >>> Yellow has a width between 1 and the beacon width that you set, >>> proportional to the gain. >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From carlo at alinoe.com Thu Aug 6 15:53:25 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 7 Aug 2009 00:53:25 +0200 Subject: [sldev] I finished VWR-14914 patch; any testers? In-Reply-To: References: <1e01733d0908060658n7e5df026k6ccaeb9f9ad42dce@mail.gmail.com> <4A7B1F8F.9020803@superliminal.com> Message-ID: <20090806225325.GA15236@alinoe.com> On Thu, Aug 06, 2009 at 11:34:33AM -0700, Kelly Linden wrote: > It sounds like the intent is not to commit the debug code. Yes, sorry - the current VWR-14914.diff is the SAME as VWR-14914-v3-20090806-debug.diff because I forgot to do a 'quilt refresh' after removing the debug code :(. It's not always easy to work with quilt, as opposed to SVN. Unfortunately, the current way SVN is being used does not allow me to work on a patch-in-progress. Perhaps I could get my own branch(es) for work in progress, that way I could just really use SVN the way it is intended. Anyway, I'll upload a new, corrected patch. > That said, I like the variable width lines concept. Just because we have a > setting for adjusting the default width doesn't mean we should ignore > width as a possible feedback mechanism. Total side issue though, and > not pertinent to the bug fix at hand. I am not proposing to include this in this patch, and not even in general, because those colors are (assume) used for other markers. Nevertheless, one could definitely argue that using the different colors when ONLY "Sound Sources" is check as beacons is definitely an improvement when debugging sound sources. Then, if more than one type of beacon is turned on, one could just show the current yellow. I wouldn't change the width however. Instead it should be fixed that one can add text to beacons. From kck325 at gmail.com Thu Aug 6 17:13:05 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Thu, 6 Aug 2009 20:13:05 -0400 Subject: [sldev] Debug problem second life on kdevelop Message-ID: Whenever I press start debug, I get the following error message. Second Life found an error parsing the command line. Please see: http://wiki.secondlife.com/wiki/Client_parameters Error: unknown option -i I am starting debugger with GDB output, which is showing following error message. /home/****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/packaged/secondlife /home/*****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/packaged/secondlife --interpreter=mi2 -quiet (gdb) set print static-members off (gdb) Process exited Did anybody had success with kdevelop debugging? Looking for help. -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090806/7a197519/attachment.htm From carlo at alinoe.com Fri Aug 7 03:53:10 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 7 Aug 2009 12:53:10 +0200 Subject: [sldev] Debug problem second life on kdevelop In-Reply-To: References: Message-ID: <20090807105310.GA1676@alinoe.com> Why are you starting secondlife with the commandline options --interpreter=mi2 -quiet ? On Thu, Aug 06, 2009 at 08:13:05PM -0400, chandra kiran kuchi wrote: > Whenever I press start debug, I get the following error message. > > Second Life found an error parsing the command line. > Please see: http://wiki.secondlife.com/wiki/Client_parameters > Error: unknown option -i > > I am starting debugger with GDB output, which is showing following error > message. > > /home/****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/packaged/ > secondlife /home/*****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/ > packaged/secondlife --interpreter=mi2 -quiet > (gdb) set print static-members off > (gdb) Process exited > > > Did anybody had success with kdevelop debugging? Looking for help. > > -- > Regards, > Chandra K Kuchi > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From kck325 at gmail.com Fri Aug 7 06:27:27 2009 From: kck325 at gmail.com (chandra kiran kuchi) Date: Fri, 7 Aug 2009 09:27:27 -0400 Subject: [sldev] Debug problem second life on kdevelop In-Reply-To: <20090807105310.GA1676@alinoe.com> References: <20090807105310.GA1676@alinoe.com> Message-ID: I didnt mention them explicitly, I followed the instructions given in second life wiki and it is bringing up debugger with that options by default. On Fri, Aug 7, 2009 at 6:53 AM, Carlo Wood wrote: > Why are you starting secondlife with the commandline options > --interpreter=mi2 -quiet ? > > On Thu, Aug 06, 2009 at 08:13:05PM -0400, chandra kiran kuchi wrote: > > Whenever I press start debug, I get the following error message. > > > > Second Life found an error parsing the command line. > > Please see: http://wiki.secondlife.com/wiki/Client_parameters > > Error: unknown option -i > > > > I am starting debugger with GDB output, which is showing following error > > message. > > > > > /home/****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/packaged/ > > secondlife > /home/*****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/ > > packaged/secondlife --interpreter=mi2 -quiet > > (gdb) set print static-members off > > (gdb) Process exited > > > > > > Did anybody had success with kdevelop debugging? Looking for help. > > > > -- > > Regards, > > Chandra K Kuchi > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > -- > Carlo Wood > -- Regards, Chandra K Kuchi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090807/d2c974e8/attachment.htm From nyx at lindenlab.com Fri Aug 7 07:31:37 2009 From: nyx at lindenlab.com (Nyx) Date: Fri, 07 Aug 2009 10:31:37 -0400 Subject: [sldev] Debug problem second life on kdevelop In-Reply-To: References: <20090807105310.GA1676@alinoe.com> Message-ID: <4A7C3AC9.3050808@lindenlab.com> When trying to debug on linux with an IDE, you need to be careful of a few things. 1) the binary in the packaged folder is stripped of debugging info by default. If you want to debug, be sure to copy secondlife-bin to the packaged directory and run that. 2) secondlife on linux is generally run from a script which sets up a number of environment issues before calling the binary. It appears you're trying to debug the launcher script which lives in newview/packaged, instead of the binary in newview/packaged/bin 3) If you want to skip over the launcher script, you need to make sure your IDE sets up the environment in its place. At minimum you need to add a few directories to LD_LIBRARY_PATH as shown below. Set LD_LIBRARY_PATH=/home/.../viewer-linux-i686-relwithdebinfo/newview/packaged/lib:/home/.../indra/viewer-linux-i686-relwithdebinfo/newview/packaged/app_settings/mozilla-runtime-linux-i686:${LD_LIBRARY_PATH} I personally use slickedit for my IDE, so I don't know the details on where in the UI you'll have to change these settings, but this should help you get started. Let us know if you run into any more roadblocks! -Nyx chandra kiran kuchi wrote: > I didnt mention them explicitly, I followed the instructions given in > second life wiki and it is bringing up debugger with that options by > default. > > On Fri, Aug 7, 2009 at 6:53 AM, Carlo Wood > wrote: > > Why are you starting secondlife with the commandline options > --interpreter=mi2 -quiet ? > > On Thu, Aug 06, 2009 at 08:13:05PM -0400, chandra kiran kuchi wrote: > > Whenever I press start debug, I get the following error message. > > > > Second Life found an error parsing the command line. > > Please see: http://wiki.secondlife.com/wiki/Client_parameters > > Error: unknown option -i > > > > I am starting debugger with GDB output, which is showing > following error > > message. > > > > > /home/****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/packaged/ > > secondlife > /home/*****/linden/indra/viewer-linux-i686-relwithdebinfo/newview/ > > packaged/secondlife --interpreter=mi2 -quiet > > (gdb) set print static-members off > > (gdb) Process exited > > > > > > Did anybody had success with kdevelop debugging? Looking for help. > > > > -- > > Regards, > > Chandra K Kuchi > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated > posting privileges > > -- > Carlo Wood > > > > > > -- > Regards, > Chandra K Kuchi > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tillie at xp2.de Fri Aug 7 09:57:42 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Fri, 07 Aug 2009 18:57:42 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A79D4A9.4090101@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> Message-ID: <4A7C5D06.7010608@xp2.de> Rob Lanphier wrote: > The graph is obviously more visually appealing, but the problem is that > it shows the crash rate of the viewer is that it currently shows all > "Snowglobe Test Build" lumped together in a way that's not going to be > entirely indicative of the problems. Unfortunately, the tools we use to > update the graph may not be flexible enough to keep rotating version > numbers. May I throw in that a low crashrate of a software is not a sign of a "good working product" all by itself? SL currently might have only a few crashes, but ... - chat/groups broken greatly - pretty bad texture rezzing issues - and snapshots almost unusable (- add more evil bugs here from JIRA) ... SL is at least for some people NOT working that well at all. *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead. I am not sure what you all are working on over there at Linden Labs, as you refuse to tell anything, but at least it is not the bugs that trouble us. Thank your for reading this! Tillie From melinda at superliminal.com Fri Aug 7 15:13:19 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 07 Aug 2009 15:13:19 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7C5D06.7010608@xp2.de> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> Message-ID: <4A7CA6FF.1060904@superliminal.com> Tillie Ariantho wrote: > Rob Lanphier wrote: > > >> The graph is obviously more visually appealing, but the problem is that >> it shows the crash rate of the viewer is that it currently shows all >> "Snowglobe Test Build" lumped together in a way that's not going to be >> entirely indicative of the problems. Unfortunately, the tools we use to >> update the graph may not be flexible enough to keep rotating version >> numbers. >> > > May I throw in that a low crashrate of a software is not a sign of a "good working product" all by itself? > > SL currently might have only a few crashes, but ... > > - chat/groups broken greatly > - pretty bad texture rezzing issues > - and snapshots almost unusable > (- add more evil bugs here from JIRA) > > ... SL is at least for some people NOT working that well at all. > > *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead. > > I am not sure what you all are working on over there at Linden Labs, as you refuse to tell anything, but at least it is not the bugs that trouble us. > > Thank your for reading this! > > Tillie Tillie, Snapshots work. I have noticed that they've gotten *much* slower for me but just about everything works. Maybe you're talking about its usability? It's not helpful to just say that something is bad without saying what's bad about it and if possible, offering constructive suggestions to improve it. Otherwise you're just venting, which might make you feel better but is not terribly helpful or attractive. -Melinda From alex at lindenlab.com Fri Aug 7 15:53:51 2009 From: alex at lindenlab.com (Alex Dailey (Xan Linden)) Date: Fri, 07 Aug 2009 15:53:51 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CA6FF.1060904@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> Message-ID: <4A7CB07F.9070800@lindenlab.com> Melinda Green wrote: > Tillie Ariantho wrote: > >> Rob Lanphier wrote: >> >> >> >>> The graph is obviously more visually appealing, but the problem is that >>> it shows the crash rate of the viewer is that it currently shows all >>> "Snowglobe Test Build" lumped together in a way that's not going to be >>> entirely indicative of the problems. Unfortunately, the tools we use to >>> update the graph may not be flexible enough to keep rotating version >>> numbers. >>> >>> >> May I throw in that a low crashrate of a software is not a sign of a "good working product" all by itself? >> >> SL currently might have only a few crashes, but ... >> >> - chat/groups broken greatly >> - pretty bad texture rezzing issues >> - and snapshots almost unusable >> (- add more evil bugs here from JIRA) >> >> ... SL is at least for some people NOT working that well at all. >> >> *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead. >> >> I am not sure what you all are working on over there at Linden Labs, as you refuse to tell anything, but at least it is not the bugs that trouble us. >> >> Thank your for reading this! >> >> Tillie >> > > Tillie, > > Snapshots work. I have noticed that they've gotten *much* slower for me > but just about everything works. Maybe you're talking about its > usability? It's not helpful to just say that something is bad without > saying what's bad about it and if possible, offering constructive > suggestions to improve it. Otherwise you're just venting, which might > make you feel better but is not terribly helpful or attractive. > > -Melinda > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > As someone who has helped design both server and viewer crash reporting systems, I understand the frustration around a poor SL experience. I can also attest that monitoring crashes the way we do has led to radical improvements to simulator and viewer stability over the past few releases. Here's a challenge to sldev. Viewer performance is complex, dependent on bandwidth, hardware, the content on the region, other avatars, and so on. What do you think a) is the one variable viewer performance should ultimately be measured by and b) what are, say, three predictive variables that influence the dependent variable. E.g. if you think viewer fps is the one variable we should care about, what three factors would you consider most important that influence that value? I realize this is simplistic, but I'm curious to know from your experience, how would you quantify viewer performance. -Xan Linden From tillie at xp2.de Fri Aug 7 15:57:04 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 08 Aug 2009 00:57:04 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CA6FF.1060904@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> Message-ID: <4A7CB140.6090200@xp2.de> Melinda Green wrote: > Snapshots work. I have noticed that they've gotten *much* slower for me > but just about everything works. Maybe you're talking about its > usability? It's not helpful to just say that something is bad without > saying what's bad about it and if possible, offering constructive > suggestions to improve it. Otherwise you're just venting, which might > make you feel better but is not terribly helpful or attractive. Only to mention those that annoy me most: - Screensize is 2560x1600, Snapshot does 2560x1599 when selecting "current window", so 1 line of pixels missing. - Preview window shows anything but the scene you try to snap. - Mirrored glow on highres snapshots. - Freeze doesnt freeze particles, clouds etc. - Highres snapshots show weird lines in clouds and water at the center of the saved snapshot not direcly snapshots but related to my photography work: - textures not rezzing very often, on all versions of 1.23.x and Snowglobe 1.x. - I crash a lot when doing snapshots at crowded places, like fashion shows, SL probably spamming memory with textures and stuff and crashing due to memory issues at some point. and lots more. And my hardware isnt that bad... Intel Quad 9300, 8GB Ram (Vista 64bit SP1), Geforce 260 GTX (896 MB), latest patches an drivers, 1.23.x and Snowglobe are worse that the 1.22.x and 1.21.x versions. Don't tell me it's Vista 64bit, doesnt work any better on XP SP3 32bit, same bugs, same crashing during shows. Here you have a list off almost all the stuff: http://jira.secondlife.com/browse/VWR-7709 (Snapshot Meta Issue) I have the bad feeling that no one is working on snapshots anymore. Someone did till 1.23 and broke something with each subrelease, I saw no improvement, only more bugs. Tillie From melinda at superliminal.com Fri Aug 7 17:24:02 2009 From: melinda at superliminal.com (Melinda Green) Date: Fri, 07 Aug 2009 17:24:02 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CB140.6090200@xp2.de> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB140.6090200@xp2.de> Message-ID: <4A7CC5A2.4000109@superliminal.com> Tillie Ariantho wrote: > Melinda Green wrote: > > >> Snapshots work. I have noticed that they've gotten *much* slower for me >> but just about everything works. Maybe you're talking about its >> usability? It's not helpful to just say that something is bad without >> saying what's bad about it and if possible, offering constructive >> suggestions to improve it. Otherwise you're just venting, which might >> make you feel better but is not terribly helpful or attractive. >> > > Only to mention those that annoy me most: > > - Screensize is 2560x1600, Snapshot does 2560x1599 when selecting "current window", so 1 line of pixels missing. > - Preview window shows anything but the scene you try to snap. > I don't know what you mean by preview not working. When you hit "Save" you should definitely get a big version of what ever you seen in the preview window. It's possible that you can change a snapshot setting after getting a preview (refresh) and before saving it, which should have invalidated the Save button but didn't. Those are nearly trivial problems and easily worked around. (Hit "refresh"). Or maybe you expect File->Snapshot To Disk to do the same thing as the Save button. (It doesn't). > - Mirrored glow on highres snapshots. > - Freeze doesnt freeze particles, clouds etc. > - Highres snapshots show weird lines in clouds and water at the center of the saved snapshot > These are all Windlight bugs. The problem with particles, clouds, etc. not honoring Freeze Frame is one of my biggest annoyances too, BTW, but from a pure user's perspective, it's valid to call them Snapshot bugs. > not direcly snapshots but related to my photography work: > > - textures not rezzing very often, on all versions of 1.23.x and Snowglobe 1.x. > - I crash a lot when doing snapshots at crowded places, like fashion shows, SL probably spamming memory with textures and stuff and crashing due to memory issues at some point. > > and lots more. > > And my hardware isnt that bad... Intel Quad 9300, 8GB Ram (Vista 64bit SP1), Geforce 260 GTX (896 MB), latest patches an drivers, 1.23.x and Snowglobe are worse that the 1.22.x and 1.21.x versions. > Don't tell me it's Vista 64bit, doesnt work any better on XP SP3 32bit, same bugs, same crashing during shows. > > Here you have a list off almost all the stuff: http://jira.secondlife.com/browse/VWR-7709 (Snapshot Meta Issue) > Yes, I'm aware of the meta task, but notice that about half of the issues are already closed. I expect many more are invalid. I'm not saying there aren't problems with this or any other major feature. I just wouldn't suggest that it's "broken" or otherwise unusable. > I have the bad feeling that no one is working on snapshots anymore. Someone did till 1.23 and broke something with each subrelease, I saw no improvement, only more bugs. > That would me me who made most of the recent changes to Snapshots through 1.23 when I left the Lab. Perhaps you don't consider the ability to save in JPG and PNG formats to be an improvement but I and a lot of other people feel that was huge. I'm also particularly proud about clarifying the top "Snapshot destination" choices, adding the "Save As" drop-down option as well as a ton of code clean-up under the hood. I also removed a stupid 1 second delay between when you hit Refresh or File->Snapshot To Disk which action photographers should love. Another developer added a lot of new support for cropping and other controls regarding aspect ratios. It's certainly possible that in the process of doing all the above and more that I broke some things, and for all of those, I apologize. It certainly wasn't for lack of care, effort, or testing. So while one set of bugs might have been replaced by some others, you certainly can't say that there's been no improvement. -Melinda From stickman at gmail.com Fri Aug 7 17:40:08 2009 From: stickman at gmail.com (Stickman) Date: Fri, 7 Aug 2009 17:40:08 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CB07F.9070800@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: > Here's a challenge to sldev. What do you think a) is the one variable > viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. What a fun challenge! It has been mentioned before in sldev that the developers/content creators are not your "average" SL users. So the metrics they choose may not be the best ones for the populace at large. But ask the populace at large what they want, and even using statistical analysis on their answers you may not get the heart of the matter. It's like asking someone to self-diagnose what the issue is when only a trained doctor knows the bodypart with the problem exists. Anyway, for me personally... ... ...what a difficult challenge. D: This isn't fun anymore. The main thing that's important to me is productivity. Being able to properly create things inworld. Kinda hard to fit into a metric. Not crashing, naturally, is important to productivity. But there's a lot of other factors, too, which seem like more of a problem than crashing is, or ever was. The metric to measure performance I would use is: Communication and response from viewer to server. The top three predictive variables are: -Functional Inventory (never really had a problem with it, though) -Rezzing working and timely (including textures, sculpts, etc) -Attachments working (No "attachment already pending" getting stuck, etc) There's a few other issues, like uploads, IMs, FPS, crashing, and whatever else, but at this moment I'm not having a problem with them, so they don't seem as important. Also, a thank you to whoever fixed the double-upload notice in 1.27.2. That's been bugging me a lot. But -- that's me. For the average user, I would guess they care about the same communication element the most. But I am going to guess that their top three predictive variables would be: -Functional teleports -Functional attachments -Functional rezzing/displaying of existing prims This is based on what I can visibly see others doing a lot and having trouble with. So they may not be long-term predictive elements if they become rock solid, but the core issue of communication would remain the same. Also: > *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead. The same amount of crashes as a viewer or so ago and having fully rezzing textures instead? Yes, I can live with that, too. I had to stop using Snowglobe because of the texture issues. I couldn't even open them from inventory. I am really looking forward to full http-texture support, as I expect a lot of speed out of it. -Stickman From missannotoole at yahoo.com Fri Aug 7 18:36:06 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 7 Aug 2009 18:36:06 -0700 (PDT) Subject: [sldev] More crash rate statistics In-Reply-To: References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: <27278.92619.qm@web59107.mail.re1.yahoo.com> You will know it if you see it is the only universal measure. ktris/fr efficiency is tied to GPU right? How fast can the data be dumped to the client? How fast can the textures come down. All that has a lot of ISP factor involved. Is windlight enabled? that automatically adds 130,000 triangles to the rendering whether you are outside or inside an enclosed space with no alpha texture views out. Too many factors so I go with "if it feels good it is good". That said the performance measures that matter are all related to the number of avatars in a region and how many scripts they brought with them. (and phantom script sludge buildup) If time dilation is unstable or low then your fiber connection, viewer, and super computer isn't going to matter anyway. Currently the max number of avatars that can be in a Linden Lab region before it starts going bad is around 15. This number has been decreasing with every region code update. Only 5 to 10 more updates before the grid is dead at the current rate of degradation. I went to a concert today., The sim peaked at 82 avatars. Nothing would rez and nobody could escape so the sim had to be restarted just to release the avatars so they could go somewhere else.. Compare to early 2007 when 100 avatars in a sim was still acceptable. User experience is tied more to the sim performance than viewer performance. A lot more engineering time needs to be applied to the simulator code base IMHO. Perhaps it is. I would have no idea. But it is getting real bad out there. $300 a month for a 20 avatar region is pretty steep and the social networking aspects of SL are dying off since it is getting harder to have social events of any serious size. That is my input. ________________________________ From: Stickman To: Alex Dailey (Xan Linden) Cc: Second Life Developer Mailing List Sent: Friday, August 7, 2009 8:40:08 PM Subject: Re: [sldev] More crash rate statistics > Here's a challenge to sldev. What do you think a) is the one variable > viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. What a fun challenge! It has been mentioned before in sldev that the developers/content creators are not your "average" SL users. So the metrics they choose may not be the best ones for the populace at large. But ask the populace at large what they want, and even using statistical analysis on their answers you may not get the heart of the matter. It's like asking someone to self-diagnose what the issue is when only a trained doctor knows the bodypart with the problem exists. Anyway, for me personally... ... ...what a difficult challenge. D: This isn't fun anymore. The main thing that's important to me is productivity. Being able to properly create things inworld. Kinda hard to fit into a metric. Not crashing, naturally, is important to productivity. But there's a lot of other factors, too, which seem like more of a problem than crashing is, or ever was. The metric to measure performance I would use is: Communication and response from viewer to server. The top three predictive variables are: -Functional Inventory (never really had a problem with it, though) -Rezzing working and timely (including textures, sculpts, etc) -Attachments working (No "attachment already pending" getting stuck, etc) There's a few other issues, like uploads, IMs, FPS, crashing, and whatever else, but at this moment I'm not having a problem with them, so they don't seem as important. Also, a thank you to whoever fixed the double-upload notice in 1.27.2. That's been bugging me a lot. But -- that's me. For the average user, I would guess they care about the same communication element the most. But I am going to guess that their top three predictive variables would be: -Functional teleports -Functional attachments -Functional rezzing/displaying of existing prims This is based on what I can visibly see others doing a lot and having trouble with. So they may not be long-term predictive elements if they become rock solid, but the core issue of communication would remain the same. Also: > *I* personally could live with more crashes if I would get working snapshots and fully rezzing textures instead. The same amount of crashes as a viewer or so ago and having fully rezzing textures instead? Yes, I can live with that, too. I had to stop using Snowglobe because of the texture issues. I couldn't even open them from inventory. I am really looking forward to full http-texture support, as I expect a lot of speed out of it. -Stickman _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090807/18c8de5a/attachment-0001.htm From mwhite at leporidae.net Fri Aug 7 18:56:48 2009 From: mwhite at leporidae.net (Matt White) Date: Fri, 7 Aug 2009 21:56:48 -0400 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CB07F.9070800@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: On Fri, Aug 7, 2009 at 6:53 PM, Alex Dailey (Xan Linden) wrote: > Here's a challenge to sldev. Viewer performance is complex, dependent on > bandwidth, hardware, the content on the region, other avatars, and so > on. What do you think a) is the one variable viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. E.g. if you think > viewer fps is the one variable we should care about, what three factors > would you consider most important that influence that value? I realize > this is simplistic, but I'm curious to know from your experience, how > would you quantify viewer performance. Ohh, hard question. The biggest "pain point" I have right now is all server-side. The stability of the viewer has come a LONG way since LL shifted effort into viewer stability and I am extremely thankful. Yes, there are some feature issues, but viewer crashes are (for me at least) very rare. It's gotten to the point where we have to restart sims about once a week, if not more often. The performance will just slowly drag down over time, but a restart clears it up. When the sim gets into a "slow" state and I look at the script times (since scripts seems to be the cause according to the stats bar), it's never one script that's doing it. You'll see handfuls of scripts with extremely high times... but the thing is, it's not consistent. If you refresh the window, you'll see a different set of scripts. As a system administrator myself, it "feels" like a server that's being driven into the swap. This is just speculation from what I can see on this side of the firewall, but that's how it feels to me. The whole system will drag down - and a restart fixes it, as it frees up whatever memory is available... for a few days anyhow. - Matt White / Bunny Halberd From tillie at xp2.de Sat Aug 8 03:02:39 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 08 Aug 2009 12:02:39 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CC5A2.4000109@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB140.6090200@xp2.de> <4A7CC5A2.4000109@superliminal.com> Message-ID: <4A7D4D3F.3060602@xp2.de> Melinda Green wrote: > I don't know what you mean by preview not working. When you hit "Save" > you should definitely get a big version of what ever you seen in the > preview window. No, whatever you see in the preview, it's not what you really shoot. It's a part of it, often missing objects and stuff and totally not the correct part of the screen you snap. > It's possible that you can change a snapshot setting > after getting a preview (refresh) and before saving it, which should > have invalidated the Save button but didn't. Those are nearly trivial > problems and easily worked around. (Hit "refresh"). Or maybe you expect > File->Snapshot To Disk to do the same thing as the Save button. (It > doesn't). Hey, you dont need to teach me how to use it. :) I've 20,000 snapshots up on flickr. ,) >> - Mirrored glow on highres snapshots. >> - Freeze doesnt freeze particles, clouds etc. >> - Highres snapshots show weird lines in clouds and water at the center >> of the saved snapshot > These are all Windlight bugs. The problem with particles, clouds, etc. > not honoring Freeze Frame is one of my biggest annoyances too, BTW, but > from a pure user's perspective, it's valid to call them Snapshot bugs. Yes. As this doesn't occur anywhere else than in snapshot, it is a snapshot bug. Where to fix it (windlight code) I dont mind, as long as it GETS fixed. > Yes, I'm aware of the meta task, but notice that about half of the > issues are already closed. Closed doesnt mean fixed. "Cannot reproduce" and "need more info" are not fixes. > That would me me who made most of the recent changes to Snapshots > through 1.23 when I left the Lab. Perhaps you don't consider the ability > to save in JPG and PNG formats to be an improvement but I and a lot of > other people feel that was huge. Sure that was good. I filled Gigabytes of space before. :P > I'm also particularly proud about > clarifying the top "Snapshot destination" choices, adding the "Save As" > drop-down option Where I still can complain: why does it ask me? When I chose a path last session, why does it ask me again after an SL restart? That's pretty annoying, especially as I am running SL in fullscreen and the file dialog doesnt appear ... I have to switch to desktop, click SL in the process bar and before Vista switches back to the SL fullscreen, I get the file dialog. > as well as a ton of code clean-up under the hood. Which is not seen to the photographer, so no chance to praise it. ^^ > It's certainly possible that in the process of doing all the above and > more that I broke some things, and for all of those, I apologize. It > certainly wasn't for lack of care, effort, or testing. So while one set > of bugs might have been replaced by some others, you certainly can't say > that there's been no improvement. Ok, sure. There was improvement. But with the bugs I listed for ME it's still greatly broken. Especially highres snashots cant be done with the glow and water/particle/fog bugs. There is lots of glow around and all photos with water/particle/fog in it you have to fix in photoshop, if that is even possible. Tillie From aleric.inglewood at gmail.com Sat Aug 8 03:13:26 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sat, 8 Aug 2009 12:13:26 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CA6FF.1060904@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> Message-ID: <1e01733d0908080313i2c47f828w86483a58086dc7f5@mail.gmail.com> On Sat, Aug 8, 2009 at 12:13 AM, Melinda Green wrote: > Tillie, > > Snapshots work. I have noticed that they've gotten *much* slower for me They don't work for me. If someone makes a snapshot and offers it to me, I NEVER get to see it. It stays at 0x0 until I relog. The reason is (I believe) that it's almost immediately marked as missing when it's being offered and therefore no attempt to download it is made. Imho, we need a better review of patches that are being merged from internal (maint-xxx), it's those merges that introduce heaps of bugs in snowglobe. The more snowglobe is going to deviate from the "official" viewer, the more that will happen. What is wrong here is this: If some change that is written for a DIFFERENT branch / version is merged, then this patch should be merged on it's own by someone who knows the changes in snowglobe (in that area) very well, as well as understands the changes that are being implemented. But what happens is that a LOT of changes/patches are being bulk-merged with ONLY regard for "does it comple or not?". There is no real QA here, and certainly no review. From carlo at alinoe.com Sat Aug 8 03:28:54 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 8 Aug 2009 12:28:54 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <27278.92619.qm@web59107.mail.re1.yahoo.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> Message-ID: <20090808102854.GA10782@alinoe.com> On Fri, Aug 07, 2009 at 06:36:06PM -0700, Ann Otoole wrote: > $300 a month for a 20 avatar region is pretty steep and the social networking > aspects of SL are dying off since it is getting harder to have social events of > any serious size. Hear, hear! 20 avatars is indeed not enough. It should be possible to have 100 avatars in a region without lag (simulatorwise). That being said, I'm VERY against adding all kinds of artificial limits. Last I cammed over the sim (while dancing) and when I returned to my avie, only 3 of the 300 prims that I was wearing as attachments we still visible! Same of the other avies. Sorry, but that is unacceptable: my machine can EASILY show all those attachments (it did BEFORE I started to cam around!). Even if those prims had to be temporarily be "dropped" while I scanned an area of 512m, when the cam returned to my avatar it should have been restored to normal; and not let me be stuck with horrible looking attachments on everyone. The idea of LL to increase speed is to limit all kinds of things then PLEASE DO NOT DO THAT! What we want is increase of speed without paying in terms of less prims/tris. I'm sure that is possible, since most of the code (of the viewer) is really badly written concerning performance; I'm sure the same holds for the server, so there will be a lot of room for performance without sacrificing visible content. -- Carlo Wood From sllists at boroon.dasgupta.ch Sat Aug 8 08:07:43 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 08 Aug 2009 17:07:43 +0200 Subject: [sldev] Performance measurement variable: possible immersion (was: More crash rate statistics) In-Reply-To: <4A7CB07F.9070800@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: <4A7D94BF.7080607@boroon.dasgupta.ch> Alex Dailey (Xan Linden) wrote: > Here's a challenge to sldev. Viewer performance is complex, dependent on > bandwidth, hardware, the content on the region, other avatars, and so > on. What do you think a) is the one variable viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. Define "performance" and I'll tell you how to measure it. Or vice versa. ;-) Using Allen's the non-technical definition cited on wikipedia /The word/ performance /in computer performance means the same thing that performance means in other contexts, that is, it means "How well is the computer doing the work it is supposed to do?" / the question remains what the viewer is supposed to do, which varies wildly from use case to use case. I have the theory that most variables that affect at least one of the use cases also affect the use case where the user wants to maximize immersion. (By which I mean the type of immersion one also has when reading a book, not the one achieved by HMDs and cyber gloves. Note that the prior is still affected by technical issues: If you read a book with missing pages, hard to read font or a cover that smells funny (and the smell isn't related to the story at all) your ability to immerse will undoubtedly suffer.) Of course, potential immersion has the problem of being poorly defined, too, and not directly measurable. You'd have to do surveys or something, and if you did that you could just directly ask about user experience instead. However I think it's an interesting variable for theoretic considerations: Note that the influence of most variables on immersion (and user experiance in general) is highly nonlinear. Let's take update rates (FPS if we look at graphics). Whether FPS are at 0.5 or 2, I don't mind. In both cases I see single frames instead of continuous motion.Whether they're at 100 or 1000 is also irrelevant, you can't tell the difference with a 60Hz TFT. Though, for the interval between 3 and maybe 30, even slight differences are noticeable enough to matter. This goes for server issues, too: Whether 1% or 10% of group IMs get delivered ... who cares, group IM wouldn't be a reliable medium in either case. The difference between 81% and 90% or even between 90.9% and 99.9%, although nominally also 9%, would be a big one, though. Also, the influence of different variables is often interdependent. Some problems might mask other problems, for example. Ann Otoole wrote: > User experience is tied more to the sim performance than viewer > performance. As someone using SL from a low end system I often hardly notice poor Sim performance, because my viewer is struggling in crowded areas anyway. Both, the masking effect and the nonlinearity of the influences, could probably be used to optimize the experience by automatically balancing them. The most simple variant would be to automatically decrease graphics settings when the FPS hits a lower threshold (say, 5) and to increase them again when hitting a higher threshold (say, the monitor's refresh rate). (Having to manually counteract immersion breaking effects is something that itself hurts immersion.) This already got rather lengthy, so I'll stop for now. cheers Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090808/dea75d09/attachment.htm From tillie at xp2.de Sat Aug 8 12:37:13 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Sat, 08 Aug 2009 21:37:13 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7DC3FD.5080907@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB140.6090200@xp2.de> <4A7CC5A2.4000109@superliminal.com> <4A7D4D3F.3060602@xp2.de> <4A7DC3FD.5080907@superliminal.com> Message-ID: <4A7DD3E9.90506@xp2.de> Melinda Green wrote: > I've seen what you mention about missing objects (attachments, it seems > to me) but I've not seen problems with framing. It's only a part of the snapshot, always! Maybe the snapshot preview has a problem with my large resolution? At least for saving it has... as it drops one line of pixels. >> Hey, you dont need to teach me how to use it. :) I've 20,000 snapshots >> up on flickr. ,) > Well then *something* must be going right here! :-D Many of them I did BEFORE all the "fixes" that came in 1.23+ And I have quite a work to do during fashion show photo shoots. With the old Nicholaz client based on SL 1.18 I NEVER crashed during a show. Nowadays I do up to 2 times. And for the photographer crashing is pretty bad. - maybe sim is full and you cant get back in - you miss items shown - stuff isn't rezzing anymore, quite often, especially shapes... I see lots of clouds after a crash and often they dont get loaded at all, anymore > I'd never thought of that, I guess because I always choose > image/sequence names that relate to the subject matter. That's why I > love that I can now change my mind in the middle of session. I like your > feature suggestion to save the last location, if not the final file name. Sure the "Save as" should open the file dialog. But even using the default "save" opens the file dialog first time after starting SL. And that's bad. > And this is my main point: This is the sort of feedback that has a > chance of getting a positive response. Just saying "it's all broken" > doesn't help at all, while acknowledging improvements that you > appreciate helps to motivate the developers. I visited several Office Hours now, listing several of those bugs. But the feedback is like "Ah ha, interesting!", "Oh really?" or "Sounds nasty." What I want is someone do some work there, not useless comments. :P What I only can hope for is that someone breaks Snapshots REALLY BAD so that Torley can't do any photos anymore. Then maybe, with HIS complains, someone will look into the snapshot code again. > Users often forget that > devs are human beings who care deeply about their work. It hurts to have > our work slammed all the time, and when that happens, most devs will > stop reading those sources. I am not only a user, I am a developer too, using PCs since '85, writing programs in Basic, Assembler, Modula-2, Pascal, PHP, Perl, Python, Java, Shellscript, REXX (OS/2!) some C and C++ and maybe some more. So I know how programming feels like. I never had someone complain bad about my code, though. :P Tillie From missannotoole at yahoo.com Sat Aug 8 13:03:00 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Sat, 8 Aug 2009 13:03:00 -0700 (PDT) Subject: [sldev] More crash rate statistics In-Reply-To: <4A7DD3E9.90506@xp2.de> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB140.6090200@xp2.de> <4A7CC5A2.4000109@superliminal.com> <4A7D4D3F.3060602@xp2.de> <4A7DC3FD.5080907@superliminal.com> <4A7DD3E9.90506@xp2.de> Message-ID: <23592.45704.qm@web59103.mail.re1.yahoo.com> RE: - maybe sim is full and you cant get back in - you miss items shown - stuff isn't rezzing anymore, quite often, especially shapes... I see lots of clouds after a crash and often they dont get loaded at all, anymore This isn't the client. It is a problem with the regions. If you crash in an empty region then stuff loads just fine when you come back. So how do we deal with he fact the regions are dying with more than 15 avatars in them? Once you cross over 40 avatars you can hang it up. If you get to 80 then nobody is going anywhere until the region is restarted. Something is wrong with the simulator system. What do we do about it? That code is not open source nor should it be. Will the people in charge of that area listen to the customers or will the grid be dead in a few months?. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090808/d3a7f118/attachment.htm From mrfrans at gmail.com Sun Aug 9 15:52:55 2009 From: mrfrans at gmail.com (Frans) Date: Sun, 9 Aug 2009 18:52:55 -0400 Subject: [sldev] How to solve this bug? In-Reply-To: References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> <4A780994.8030309@lindenlab.com> <93015DC698D045EEB6E0C3073C85B148@kenb> Message-ID: <7765f2c60908091552g668f1d65q62f9c7b92470bae0@mail.gmail.com> > > two somewhat goofy ways to fix this > > 1 instead of dropping the gain to full zero drop it down to minimum to > prevent triggering the Zero Gain Bug (play the sound at like 0.01% or > whatever the lowest possible gain is)* Either that or we should find out why the zero gain takes more processing and try to get that fixed in OpenAL. > > > 2 have a timeout so that if you run back into range within say 20 > seconds it will continue to play but if you are out of range at 21 > seconds then the stream is cut I believe the maximum length of scripted sound is 10 seconds, so it could basically drop of after that if you are out of range. Is there some way I can check if I am experiencing this same issue, I have also have regularly sudden FPS large drops without any obvious reason. Going from like ~30 to >10 fps. But it always recovers after some time (minutes), it keeps happen in intervals the entire time. -- Jeroen Frans Virtual World Technology Specialist. TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090809/ac585a42/attachment.htm From carlo at alinoe.com Sun Aug 9 19:19:00 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 10 Aug 2009 04:19:00 +0200 Subject: [sldev] How to solve this bug? In-Reply-To: <7765f2c60908091552g668f1d65q62f9c7b92470bae0@mail.gmail.com> References: <1e01733d0907310419y6f84a225g2ffdfddd24534291@mail.gmail.com> <4A72E8E7.6090406@lindenlab.com> <1e01733d0908031757y5dab6093hab6e42527b883593@mail.gmail.com> <4A780994.8030309@lindenlab.com> <93015DC698D045EEB6E0C3073C85B148@kenb> <7765f2c60908091552g668f1d65q62f9c7b92470bae0@mail.gmail.com> Message-ID: <20090810021900.GA4122@alinoe.com> On Sun, Aug 09, 2009 at 06:52:55PM -0400, Frans wrote: > Is there some way I can check if I am experiencing this same issue, I have also > have regularly sudden FPS large drops without any obvious reason. Going from > like ~30 to >10 fps. But it always recovers after some time (minutes), it keeps > happen in intervals the entire time. Look in fast timers, whether or not "Audio Update" is large. -- Carlo Wood From aleric.inglewood at gmail.com Mon Aug 10 04:44:50 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Mon, 10 Aug 2009 13:44:50 +0200 Subject: [sldev] Intend to commit VWR-14914 Message-ID: <1e01733d0908100444o5f7ffa0cs13838abf6547456a@mail.gmail.com> After testing/using this patch for a few days, and with a review by Kelly (feedback via IRC), I feel confident that the patch does exactly what it is intended to do without any drawback. Also thanks to Techwolf for testing and reporting that the patch fixes all cases of high Audio Update times that he ran into. Hence, pending any serious objections, I'll commit http://jira.secondlife.com/browse/VWR-14914 somewhere tomorrow. Aleric From robla at lindenlab.com Mon Aug 10 11:47:44 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 10 Aug 2009 11:47:44 -0700 Subject: [sldev] Snowglobe logo contest Message-ID: Hi folks, We've just posted a design contest for a new logo for Snowglobe: http://99designs.com/contests/26519/brief If you'd like to comment/discuss, please do so here: http://jira.secondlife.com/browse/SNOW-153 Contest runs until August 17. Thanks Rob From billwindwalker at rocketmail.com Tue Aug 11 04:24:43 2009 From: billwindwalker at rocketmail.com (Bill Windwalker) Date: Tue, 11 Aug 2009 04:24:43 -0700 (PDT) Subject: [sldev] More crash rate statistics In-Reply-To: <20090808102854.GA10782@alinoe.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> Message-ID: <499932.52508.qm@web111203.mail.gq1.yahoo.com> seems every one is over looking the real problem of this all. it is the people on the free accounts that can come in and build and sale there items on xstreet and keep there xstreet box on a friends plot or a sky box that no one looks at the owner of the prims at. this is why so many will not rent or even pay for a account. the free basic account every one thinks they rent well that is not true in many cases. we are looking at a lot of poor people coming in from librarys with computers to try and make real money. and is more about money making jobs then it is doing any thing good to support a falling SL at this time. so with all the testing we need new pathways to take and steps we must start taking now. a large number of people now say why bother with a prem. account any more. what will we do to fix this ? ? ________________________________ From: Carlo Wood To: Ann Otoole Cc: sldev at lists.secondlife.com Sent: Saturday, August 8, 2009 6:28:54 AM Subject: Re: [sldev] More crash rate statistics On Fri, Aug 07, 2009 at 06:36:06PM -0700, Ann Otoole wrote: > $300 a month for a 20 avatar region is pretty steep and the social networking > aspects of SL are dying off since it is getting harder to have social events of > any serious size. Hear, hear! 20 avatars is indeed not enough. It should be possible to have 100 avatars in a region without lag (simulatorwise). That being said, I'm VERY against adding all kinds of artificial limits. Last I cammed over the sim (while dancing) and when I returned to my avie, only 3 of the 300 prims that I was wearing as attachments we still visible! Same of the other avies. Sorry, but that is unacceptable: my machine can EASILY show all those attachments (it did BEFORE I started to cam around!). Even if those prims had to be temporarily be "dropped" while I scanned an area of 512m, when the cam returned to my avatar it should have been restored to normal; and not let me be stuck with horrible looking attachments on everyone. The idea of LL to increase speed is to limit all kinds of things then PLEASE DO NOT DO THAT! What we want is increase of speed without paying in terms of less prims/tris. I'm sure that is possible, since most of the code (of the viewer) is really badly written concerning performance; I'm sure the same holds for the server, so there will be a lot of room for performance without sacrificing visible content. -- Carlo Wood _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090811/98f789c8/attachment.htm From tateru.nino at gmail.com Tue Aug 11 05:37:33 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 11 Aug 2009 22:37:33 +1000 Subject: [sldev] More crash rate statistics In-Reply-To: <499932.52508.qm@web111203.mail.gq1.yahoo.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> <499932.52508.qm@web111203.mail.gq1.yahoo.com> Message-ID: <4A81660D.90803@weblogsinc.com> I feel we've wandered off the topic a bit, which is (last I looked) viewer development. However, Bill, if you've got some solid statistics to back that up, feel free to email me, and we'll talk. I'd be interested. Bill Windwalker wrote: > seems every one is over looking the real problem of this all. > it is the people on the free accounts that can come in and build and > sale there items on xstreet and keep there xstreet box on a friends > plot or a sky box that no one looks at the owner of the prims at. > this is why so many will not rent or even pay for a account. > the free basic account every one thinks they rent well that is not > true in many cases. > we are looking at a lot of poor people coming in from librarys with > computers to try and make real money. > and is more about money making jobs then it is doing any thing good to > support a falling SL at this time. > so with all the testing we need new pathways to take and steps we must > start taking now. > a large number of people now say why bother with a prem. account any more. > what will we do to fix this ? > > > ------------------------------------------------------------------------ > *From:* Carlo Wood > *To:* Ann Otoole > *Cc:* sldev at lists.secondlife.com > *Sent:* Saturday, August 8, 2009 6:28:54 AM > *Subject:* Re: [sldev] More crash rate statistics > > On Fri, Aug 07, 2009 at 06:36:06PM -0700, Ann Otoole wrote: > > $300 a month for a 20 avatar region is pretty steep and the social > networking > > aspects of SL are dying off since it is getting harder to have > social events of > > any serious size. > > Hear, hear! 20 avatars is indeed not enough. > It should be possible to have 100 avatars in a region without lag > (simulatorwise). > > That being said, I'm VERY against adding all kinds of artificial limits. > Last I cammed over the sim (while dancing) and when I returned to my > avie, only 3 of the 300 prims that I was wearing as attachments we > still visible! Same of the other avies. Sorry, but that is unacceptable: > my machine can EASILY show all those attachments (it did BEFORE I > started to cam around!). Even if those prims had to be temporarily > be "dropped" while I scanned an area of 512m, when the cam returned > to my avatar it should have been restored to normal; and not let me > be stuck with horrible looking attachments on everyone. > > The idea of LL to increase speed is to limit all kinds of things > then PLEASE DO NOT DO THAT! What we want is increase of speed > without paying in terms of less prims/tris. I'm sure that is possible, > since most of the code (of the viewer) is really badly written > concerning performance; I'm sure the same holds for the server, so > there will be a lot of room for performance without sacrificing > visible content. > > -- > Carlo Wood > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090811/8f0938ed/attachment.htm From carlo at alinoe.com Tue Aug 11 06:34:14 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 11 Aug 2009 15:34:14 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <499932.52508.qm@web111203.mail.gq1.yahoo.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> <499932.52508.qm@web111203.mail.gq1.yahoo.com> Message-ID: <20090811133414.GA1900@alinoe.com> On Tue, Aug 11, 2009 at 04:24:43AM -0700, Bill Windwalker wrote: > seems every one is over looking the real problem of this all. > it is the people on the free accounts that can come in and build and sale there > items on xstreet and keep there xstreet box on a friends plot or a sky box that > no one looks at the owner of the prims at. > this is why so many will not rent or even pay for a account. Almost everyone that I know is renting a place somewhere. They just don't pay LL directly, they pay the owner of the ground/sim (in L$). I pay also USD$ 20 per month for the land that I live on, and I do not have a basic account. 90% of that money goes to Linden Lab. If they want the other 10% too, they have to make it possible to rent a homestead WITHOUT the need to have a full sim. I cannot afford a full sim, so I have to rent homesteads from people with money (and lots of sims), the so called "land lords". -- Carlo Wood From tillie at xp2.de Tue Aug 11 09:23:04 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 11 Aug 2009 18:23:04 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <499932.52508.qm@web111203.mail.gq1.yahoo.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> <499932.52508.qm@web111203.mail.gq1.yahoo.com> Message-ID: <4A819AE8.5090500@xp2.de> Hello, > a large number of people now say why bother with a prem. account any more. > what will we do to fix this ? With the ugly behaviour of deleting premium accounts including the avatar and all the stuff more people will drop from premium to free if they get into about this fact. 300L/week cash back from what you paid is no compensation for the iminent thread of loosing everything you are/have! Stuff like that needs to get fixed first. Tillie From tillie at xp2.de Tue Aug 11 10:17:17 2009 From: tillie at xp2.de (Tillie Ariantho) Date: Tue, 11 Aug 2009 19:17:17 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A819AE8.5090500@xp2.de> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> <499932.52508.qm@web111203.mail.gq1.yahoo.com> <4A819AE8.5090500@xp2.de> Message-ID: <4A81A79D.6060800@xp2.de> Tillie Ariantho wrote: > With the ugly behaviour of deleting premium accounts including the avatar and all the stuff more people will drop from premium to free if they get into about this fact. There is missing a part. "... when the credit card expired and/or the account has no money in anymore ..." I have heard some horrid stories about that. Tillie From q at lindenlab.com Tue Aug 11 10:27:59 2009 From: q at lindenlab.com (Q Linden) Date: Tue, 11 Aug 2009 13:27:59 -0400 Subject: [sldev] More crash rate statistics In-Reply-To: <4A81A79D.6060800@xp2.de> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <27278.92619.qm@web59107.mail.re1.yahoo.com> <20090808102854.GA10782@alinoe.com> <499932.52508.qm@web111203.mail.gq1.yahoo.com> <4A819AE8.5090500@xp2.de> <4A81A79D.6060800@xp2.de> Message-ID: <6d4870b50908111027l432fbcf7u529f3413cfc51769@mail.gmail.com> Wow, this thread has really kind of gone out there with what appear to be rumors not based in fact. a) I'm not in billing, but I know from talking with billing people that we give customers all sorts of chances to make good on financial obligations. b) I went and asked some senior grid people about performance. One of our data specialists did some extra data analysis across the grid in response to my query. There is, as one would expect, a weak correlation between number of avatars and time dilation. But it's actually rather weak. We have many examples of 80-100 avatars in a region with > .9 time dilation. There are also some regions with .2 time dilation and just a few avatars. We have people who do statistical analysis. We have people working on automated simulator performance analysis. Grid performance is pretty critical, as you might imagine, so we do watch it. We are busy working on tools that will allow people to get a clearer view of what's causing performance issues, and we'll be sharing them with residents. Meanwhile, can we get back to talking about open source development, please? Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090811/05d4f581/attachment-0001.htm From sanketmdesai at gmail.com Tue Aug 11 23:25:11 2009 From: sanketmdesai at gmail.com (Sanket Desai) Date: Wed, 12 Aug 2009 11:55:11 +0530 Subject: [sldev] Building viewer on MSVC2008 express edition Message-ID: Hello Every one, I am having errors while building the "ALL_BUILD" in solution explorer of MSVC2008 express edition , i also have updated the libboost library files from vc80 to vc90 as suggested on jodiah jensen's page http://wiki.secondlife.com/wiki/User:Jodiah_Jensen#HOW_I_COMPILED_SL_SOURCE_w.2F_VC.2B.2B_2008_Express_Edition . Even after doingthe things instructed ,i am stuck up with these errors, can any one help me with this ..... the output that i was getting while building the ALL_BUILD is as follows : 1>------ Build started: Project: secondlife-bin, Configuration: RelWithDebInfo Win32 ------ 1>Setting the secondlife-bin working directory for debugging. 1>Editing solution: D:/linden/indra/build-VC90/SecondLife.sln 1>Looking for existing VisualStudio instance... 1> Didn't find open solution, starting new background VisualStudio instance... 1> Reading .sln file version... 1> Using version: VC90... 1>Value cannot be null. 1>Parameter name: type 1>Quitting do to error opening: D:\linden\indra\build-VC90\SecondLife.sln 1>Verifying message template 1>master: http://secondlife.com/app/message_template/master_message_template.msg 1>current: D:\linden\scripts\messages\message_template.msg 1>--- PASS --- 1>Older 1> in message DirPopularReply: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message DirPopularQueryBackend: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message ViewerStats: is less deprecated: NotDeprecated vs. UDPDeprecated in base 1> in message ChildAgentUpdate: missing 1 extra blocks 1> in message DirPopularQuery: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message RequestParcelTransfer: missing 1 extra blocks 1> 1>D:\linden\indra\lib\python\indra\ipc\llmessage.py:29: DeprecationWarning: the sets module is deprecated 1> from sets import Set, ImmutableSet 1>Linking... 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(void)" (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(char const *)" (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "class std::basic_ostream > & __cdecl std::operator<<,class std::allocator >(class std::basic_ostream > &,class std::basic_string,class std::allocator > const &)" (??$?6DU?$char_traits at D@std@@V?$allocator at D@1@@std@@YAAAV?$basic_ostream at DU ?$char_traits at D@std@@@0 at AAV10@ABV?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@0@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > const &)" (??0?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAE at ABV01@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(class std::basic_string,class std::allocator > const &)" (??4?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAEAAV01 at ABV01@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator==,class std::allocator >(class std::basic_string,class std::allocator > const &,char const *)" (??$?8DU?$char_traits at D@std@@V?$allocator at D@1@@std@@YA_NABV?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@0 at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: bool __thiscall std::basic_string,class std::allocator >::empty(void)const " (?empty@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QBE_NXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator+=(class std::basic_string,class std::allocator > const &)" (??Y?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAEAAV01 at ABV01@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::erase(unsigned int,unsigned int)" (?erase@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAEAAV12 at II@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::length(void)const " (?length@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEIXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator+=(char)" (??Y?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV01 at D@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(cmdline.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: char const * __thiscall std::basic_string,class std::allocator >::c_str(void)const " (?c_str@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEPBDXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "class std::basic_string,class std::allocator > __cdecl std::operator+,class std::allocator >(class std::basic_string,class std::allocator > const &,class std::basic_string,class std::allocator > const &)" (??$?HDU?$char_traits at D@std@@V?$allocator at D@1@@std@@YA?AV?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@0 at ABV10@0 at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "class std::basic_string,class std::allocator > __cdecl std::operator+,class std::allocator >(class std::basic_string,class std::allocator > const &,char const *)" (??$?HDU?$char_traits at D@std@ @V?$allocator at D@1@@std@@YA?AV?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@0 at ABV10@PBD at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_ios >::setstate(int,bool)" (?setstate@?$basic_ios at DU?$char_traits at D@std@@@std@@QAEXH_N at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::ios_base::width(int)" (?width at ios_base@std@@QAEHH at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::basic_streambuf >::sputn(char const *,int)" (?sputn@?$basic_streambuf at DU?$char_traits at D@std@@@std@@QAEHPBDH at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: static bool __cdecl std::char_traits::eq_int_type(int const &,int const &)" (?eq_int_type@ ?$char_traits at D@std@@SA_NABH0 at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: static int __cdecl std::char_traits::eof(void)" (?eof@?$char_traits at D@std@@SAHXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::basic_streambuf >::sputc(char)" (?sputc@?$basic_streambuf at DU?$char_traits at D@std@@@std@@QAEHD at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_streambuf > * __thiscall std::basic_ios >::rdbuf(void)const " (?rdbuf@?$basic_ios at DU?$char_traits at D@std@@@std@@QBEPAV?$basic_streambuf at DU ?$char_traits at D@std@@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: char __thiscall std::basic_ios >::fill(void)const " (?fill@?$basic_ios at DU?$char_traits at D@std@@@std@@QBEDXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::ios_base::flags(void)const " (?flags at ios_base@std@@QBEHXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::ios_base::width(void)const " (?width at ios_base@std@@QBEHXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: static unsigned int __cdecl std::char_traits::length(char const *)" (?length@ ?$char_traits at D@std@@SAIPBD at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_ostream > & __thiscall std::basic_ostream >::flush(void)" (?flush@?$basic_ostream at DU?$char_traits at D@std@@@std@@QAEAAV12 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_ostream > * __thiscall std::basic_ios >::tie(void)const " (?tie@ ?$basic_ios at DU?$char_traits at D@std@@@std@@QBEPAV?$basic_ostream at DU ?$char_traits at D@std@@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: bool __thiscall std::ios_base::good(void)const " (?good at ios_base@std@@QBE_NXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_ostream >::_Osfx(void)" (?_Osfx@?$basic_ostream at DU?$char_traits at D@std@@@std@@QAEXXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_streambuf >::_Lock(void)" (?_Lock@?$basic_streambuf at DU?$char_traits at D@std@@@std@@QAEXXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_streambuf >::_Unlock(void)" (?_Unlock@?$basic_streambuf at DU?$char_traits at D@std@@@std@@QAEXXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(class std::basic_string,class std::allocator > const &)" (?append@?$basic_string at DU?$char_traits at D @std@@V?$allocator at D@2@@std@@QAEAAV12 at ABV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(char const *)" (?append@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAEAAV12 at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator<,class std::allocator >(class std::basic_string,class std::allocator > const &,class std::basic_string,class std::allocator > const &)" (??$?MDU?$char_traits at D@std@@V?$allocator at D@1@@std@@YA_NABV?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@0 at 0@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(variables_map.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEIXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: virtual __thiscall std::basic_ios >::~basic_ios >(void)" (??1?$basic_ios at DU?$char_traits at D@std@@@std@ @UAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: __thiscall std::basic_ios >::basic_ios >(void)" (??0?$basic_ios at DU?$char_traits at D@std@@@std@ @IAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_stringstream,class std::allocator >::`vbase destructor'(void)" (??_D?$basic_stringstream at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEXXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator+=(char const *)" (??Y?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAEAAV01 at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::operator=(char const *)" (??4?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAEAAV01 at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > __thiscall std::basic_string,class std::allocator >::substr(unsigned int,unsigned int)const " (?substr@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QBE?AV12 at II@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::~basic_string,class std::allocator >(void)" (??1?$basic_string at GU?$char_traits at G@std@@V?$allocator at G@2@ @std@@QAE at XZ) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(unsigned short const *)" (??0?$basic_string at GU?$char_traits at G@std@ @V?$allocator at G@2@@std@@QAE at PBG@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::find(class std::basic_string,class std::allocator > const &,unsigned int)const " (?find@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@ @std@@QBEIABV12 at I@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "class std::basic_string,class std::allocator > __cdecl std::operator+,class std::allocator >(char const *,class std::basic_string,class std::allocator > const &)" (??$?HDU?$char_traits at D@std@@V?$allocator at D @1@@std@@YA?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@ @0 at PBDABV10@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::find(char,unsigned int)const " (?find@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEIDI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(class std::basic_string,class std::allocator > const &)" (?assign@?$basic_string at DU?$char_traits at D @std@@V?$allocator at D@2@@std@@QAEAAV12 at ABV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_istream >::basic_istream >(class std::basic_streambuf > *,bool)" (??0?$basic_istream at DU?$char_traits at D@std@@@std@@QAE at PAV?$basic_streambuf at DU ?$char_traits at D@std@@@1 at _N@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::_String_const_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::end(void)const " (?end@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QBE?AV?$_String_const_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@ @2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::_String_const_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::begin(void)const " (?begin@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QBE?AV?$_String_const_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@ @2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::begin(void)" (?begin@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAE?AV?$_String_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::end(void)" (?end@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAE?AV?$_String_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: static bool __cdecl std::char_traits::eq(char const &,char const &)" (?eq@?$char_traits at D @std@@SA_NABD0 at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::swap(class std::basic_string,class std::allocator > &)" (?swap@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEXAAV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::allocator::deallocate(char *,unsigned int)" (?deallocate@ ?$allocator at D@std@@QAEXPADI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(char const *)" (?assign@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAEAAV12 at PBD@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator==,class std::allocator >(class std::basic_string,class std::allocator > const &,class std::basic_string,class std::allocator > const &)" (??$?8DU?$char_traits at D@std@@V?$allocator at D @1@@std@@YA_NABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@0 at 0@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(class std::_String_const_iterator,class std::allocator >,class std::_String_const_iterator,class std::allocator >)" (?assign@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at V ?$_String_const_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@@2 at 0@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::basic_string,class std::allocator >::compare(class std::basic_string,class std::allocator > const &)const " (?compare@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QBEHABV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > __thiscall std::basic_stringstream,class std::allocator >::str(void)const " (?str@ ?$basic_stringstream at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QBE?AV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_stringstream,class std::allocator >::basic_stringstream,class std::allocator >(int)" (??0?$basic_stringstream at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE at H@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: char const * __thiscall std::basic_string,class std::allocator >::data(void)const " (?data@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEPBDXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(convert.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(unsigned int,char)" (?append@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@ @std@@QAEAAV12 at ID@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator==,class std::allocator >(char const *,class std::basic_string,class std::allocator > const &)" (??$?8DU?$char_traits at D@std@@V?$allocator at D@1@@std@ @YA_NPBDABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@0@@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(regex_traits_defaults.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_string,class std::allocator >::reserve(unsigned int)" (?reserve@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEXI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(convert.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator<=,class std::allocator >(class std::basic_string,class std::allocator > const &,class std::basic_string,class std::allocator > const &)" (??$?NDU?$char_traits at D@std@@V?$allocator at D @1@@std@@YA_NABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@0 at 0@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(instances.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "bool __cdecl std::operator>,class std::allocator >(class std::basic_string,class std::allocator > const &,class std::basic_string,class std::allocator > const &)" (??$?ODU?$char_traits at D@std@@V?$allocator at D@1@@std@@YA_NABV?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@0 at 0@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(instances.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::basic_string,class std::allocator >::compare(char const *)const " (?compare@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QBEHPBD at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::ios_base::operator void *(void)const " (??Bios_base at std@@QBEPAXXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::replace(unsigned int,unsigned int,class std::basic_string,class std::allocator > const &)" (?replace@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAEAAV12 at IIABV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(convert.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::ios_base::precision(int)" (?precision at ios_base@std@@QAEHH at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::ios_base::unsetf(int)" (?unsetf at ios_base@std@@QAEXH at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: bool __thiscall std::ios_base::fail(void)const " (?fail at ios_base@std@@QBE_NXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "class std::basic_string,class std::allocator > __cdecl std::operator+,class std::allocator >(class std::basic_string,class std::allocator > const &,char)" (??$?HDU?$char_traits at D@std@ @V?$allocator at D@1@@std@@YA?AV?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@0 at ABV10@D at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(cmdline.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::reverse_iterator,class std::allocator > > __thiscall std::basic_string,class std::allocator >::rbegin(void)" (?rbegin@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE?AV?$reverse_iterator at V ?$_String_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@2 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_ostream > & __thiscall std::basic_ostream >::operator<<(bool)" (??6?$basic_ostream at DU?$char_traits at D@std@@@std@@QAEAAV01 at _N@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(value_semantic.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(char const *,unsigned int)" (?assign@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAEAAV12 at PBDI@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::append(char const *,unsigned int)" (?append@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QAEAAV12 at PBDI@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::assign(class std::basic_string,class std::allocator > const &,unsigned int,unsigned int)" (?assign@ ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at ABV12 @II at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::basic_ios >::clear(int,bool)" (?clear@?$basic_ios at DU?$char_traits at D@std@@@std@@QAEXH_N at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(char const *,unsigned int)" (??0?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@ @QAE at PBDI@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: virtual __thiscall std::basic_streambuf >::~basic_streambuf >(void)" (??1?$basic_streambuf at DU?$char_traits at D@std@@@std@@UAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: __thiscall std::basic_streambuf >::basic_streambuf >(void)" (??0?$basic_streambuf at DU?$char_traits at D@std@@@std@@IAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: void __thiscall std::basic_streambuf >::setg(char *,char *,char *)" (?setg@?$basic_streambuf at DU?$char_traits at D@std@@@std@@IAEXPAD00 at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: char * __thiscall std::basic_streambuf >::gptr(void)const " (?gptr@?$basic_streambuf at DU?$char_traits at D@std@@@std@@IBEPADXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: void __thiscall std::basic_streambuf >::setp(char *,char *)" (?setp@?$basic_streambuf at DU?$char_traits at D@std@@@std@@IAEXPAD0 at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: char * __thiscall std::basic_streambuf >::pptr(void)const " (?pptr@?$basic_streambuf at DU?$char_traits at D@std@@@std@@IBEPADXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: virtual __thiscall std::basic_iostream >::~basic_iostream >(void)" (??1?$basic_iostream at DU?$char_traits at D@std@@@std@@UAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_iostream >::basic_iostream >(class std::basic_streambuf > *)" (??0?$basic_iostream at DU?$char_traits at D@std@@@std@@QAE at PAV ?$basic_streambuf at DU?$char_traits at D@std@@@1@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: void __thiscall std::basic_string,class std::allocator >::_Tidy(bool,unsigned int)" (?_Tidy@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@IAEX_NI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: __thiscall std::_String_val >::_String_val >(class std::allocator)" (??0?$_String_val at DV ?$allocator at D@std@@@std@@IAE at V?$allocator at D@1@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::allocator::allocator(void)" (??0?$allocator at D@std@@QAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: int __thiscall std::basic_string,class std::allocator >::compare(unsigned int,unsigned int,char const *,unsigned int)const " (?compare@?$basic_string at DU?$char_traits at D@std@ @V?$allocator at D@2@@std@@QBEHIIPBDI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::replace(unsigned int,unsigned int,char const *,unsigned int)" (?replace@?$basic_string at DU ?$char_traits at D@std@@V?$allocator at D@2@@std@@QAEAAV12 at IIPBDI@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(void)" (??0?$basic_string at GU?$char_traits at G@std@@V?$allocator at G@2@ @std@@QAE at XZ) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::basic_string,class std::allocator >::basic_string,class std::allocator >(class std::basic_string,class std::allocator > const &)" (??0?$basic_string at GU?$char_traits at G@std@@V?$allocator at G@2@@std@ @QAE at ABV01@@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::allocator::allocator(void)" (??0?$allocator at G@std@@QAE at XZ) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned short * __thiscall std::allocator::allocate(unsigned int)" (?allocate@?$allocator at G@std@@QAEPAGI at Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: void __thiscall std::allocator::deallocate(unsigned short *,unsigned int)" (?deallocate@?$allocator at G@std@@QAEXPAGI at Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::allocator::allocator(class std::allocator const &)" (??0?$allocator at G@std@@QAE at ABV01@@Z) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::allocator::max_size(void)const " (?max_size@ ?$allocator at G@std@@QBEIXZ) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::basic_string,class std::allocator >::size(void)const " (?size@ ?$basic_string at GU?$char_traits at G@std@@V?$allocator at G@2@@std@@QBEIXZ) already defined in libboost_regex-vc90-mt-s-1_34_1.lib(w32_regex_traits.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: void __thiscall std::basic_ios >::init(class std::basic_streambuf > *,bool)" (?init@ ?$basic_ios at DU?$char_traits at D@std@@@std@@IAEXPAV?$basic_streambuf at DU ?$char_traits at D@std@@@2 at _N@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: virtual __thiscall std::basic_istream >::~basic_istream >(void)" (??1?$basic_istream at DU?$char_traits at D@std@@@std@@UAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: virtual __thiscall std::basic_ostream >::~basic_ostream >(void)" (??1?$basic_ostream at DU?$char_traits at D@std@@@std@@UAE at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_ostream > & __thiscall std::basic_ostream >::put(char)" (?put@ ?$basic_ostream at DU?$char_traits at D@std@@@std@@QAEAAV12 at D@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: char * __thiscall std::allocator::allocate(unsigned int)" (?allocate@?$allocator at D@std@ @QAEPADI at Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: __thiscall std::allocator::allocator(class std::allocator const &)" (??0?$allocator at D@std@@QAE at ABV01@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: unsigned int __thiscall std::allocator::max_size(void)const " (?max_size@?$allocator at D@std@@QBEIXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(positional_options.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::basic_string,class std::allocator > & __thiscall std::basic_string,class std::allocator >::replace(class std::_String_const_iterator,class std::allocator >,class std::_String_const_iterator,class std::allocator >,class std::basic_string,class std::allocator > const &)" (?replace@?$basic_string at DU?$char_traits at D @std@@V?$allocator at D@2@@std@@QAEAAV12 at V?$_String_const_iterator at DU ?$char_traits at D@std@@V?$allocator at D@2@@2 at 0ABV12@@Z) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(convert.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "protected: char * __thiscall std::basic_streambuf >::egptr(void)const " (?egptr@?$basic_streambuf at DU?$char_traits at D@std@@@std@@IBEPADXZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>msvcprt.lib(MSVCP90.dll) : error LNK2005: "public: class std::locale::facet * __thiscall std::locale::facet::_Decref(void)" (?_Decref at facet@locale at std@@QAEPAV123 at XZ) already defined in libboost_program_options-vc90-mt-s-1_34_1.lib(options_description.obj) 1>libcpmt.lib(locale0.obj) : error LNK2005: "void __cdecl _AtModuleExit(void (__cdecl*)(void))" (?_AtModuleExit@@YAXP6AXXZ at Z) already defined in msvcprt.lib(locale0_implib.obj) 1>libcpmt.lib(locale0.obj) : error LNK2005: "private: static class std::locale::_Locimp * __cdecl std::locale::_Getgloballocale(void)" (?_Getgloballocale at locale@std@@CAPAV_Locimp at 12@XZ) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(locale0.obj) : error LNK2005: __Fac_tidy already defined in msvcprt.lib(locale0_implib.obj) 1>libcpmt.lib(locale0.obj) : error LNK2005: "private: static void __cdecl std::locale::facet::facet_Register(class std::locale::facet *)" (?facet_Register at facet@locale at std@@CAXPAV123@@Z) already defined in msvcprt.lib(locale0_implib.obj) 1>libcpmt.lib(locale0.obj) : error LNK2005: "public: static void __cdecl std::_Locinfo::_Locinfo_dtor(class std::_Locinfo *)" (?_Locinfo_dtor@ _Locinfo at std@@SAXPAV12@@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(locale0.obj) : error LNK2005: "private: static class std::locale::_Locimp * __cdecl std::locale::_Init(void)" (?_Init at locale@std@ @CAPAV_Locimp at 12@XZ) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(locale0.obj) : error LNK2005: "public: static void __cdecl std::_Locinfo::_Locinfo_ctor(class std::_Locinfo *,char const *)" (?_Locinfo_ctor at _Locinfo@std@@SAXPAV12 at PBD@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(locale0.obj) : error LNK2005: "public: static void __cdecl std::_Locinfo::_Locinfo_ctor(class std::_Locinfo *,class std::basic_string,class std::allocator > const &)" (?_Locinfo_ctor at _Locinfo@std@@SAXPAV12 at ABV ?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@2@@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(ios.obj) : error LNK2005: "public: static void __cdecl std::ios_base::_Addstd(class std::ios_base *)" (?_Addstd at ios_base@std@ @SAXPAV12@@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(ios.obj) : error LNK2005: "private: static void __cdecl std::ios_base::_Ios_base_dtor(class std::ios_base *)" (?_Ios_base_dtor at ios_base@std@@CAXPAV12@@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::_Lockit(int)" (??0_Lockit at std@@QAE at H@Z) already defined in msvcprt.lib(MSVCP90.dll) 1>libcpmt.lib(xlock.obj) : error LNK2005: "public: __thiscall std::_Lockit::~_Lockit(void)" (??1_Lockit at std@@QAE at XZ) already defined in msvcprt.lib(MSVCP90.dll) 1> Creating library D:\linden\indra\build-VC90\newview\RelWithDebInfo\secondlife-bin.lib and object D:\linden\indra\build-VC90\newview\RelWithDebInfo\secondlife-bin.exp 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ParserFree imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ErrorString imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentByteCount imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentByteIndex imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentColumnNumber imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetCurrentLineNumber imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_GetErrorCode imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_Parse imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetUserData imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetCharacterDataHandler imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_SetElementHandler imported in function _xml_elem_parse_buf 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: locally defined symbol _XML_ParserCreate imported in function _xml_elem_parse_buf 1>D:\linden\indra\build-VC90\newview\RelWithDebInfo\secondlife-bin.exe : fatal error LNK1169: one or more multiply defined symbols found 1>Build log was saved at "file://d:\linden\indra\build-VC90\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" 1>secondlife-bin - 126 error(s), 12 warning(s) 2>------ Skipped Build: Project: ALL_BUILD, Configuration: RelWithDebInfo Win32 ------ 2>Project not selected to build for this solution configuration ========== Build: 0 succeeded, 1 failed, 24 up-to-date, 1 skipped ========== Can any one help me with this .... sorry for the inconvenience caused .. sanket -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/cc3e9b54/attachment-0001.htm From monkowsk at watson.ibm.com Wed Aug 12 08:22:43 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 12 Aug 2009 11:22:43 -0400 Subject: [sldev] Building viewer on MSVC2008 express edition In-Reply-To: References: Message-ID: <4A82DE43.8050303@watson.ibm.com> Dear Linden Lab, I've seen this question many times, and the answer is usually "Oh, that's the boost problem with VS2008. You have to use a compiler version that's no longer available." Why are we putting so much effort into getting the next incremental release of Snowglobe out, and completely ignoring the problem that new developers who choose to use MS Windows simply cannot get started? I'm lucky. I managed to follow hacks to get VS2005 working when the only supported version what the then-no-longer-available VS2003, so now that VS2005 is outdated, it works. This should not be the standard operating procedure. Yes, I know Linden doesn't use VS2008, but if you want to encourage open source development, help those who do. They might even be able to help with the next incremental release of Snowglobe then. Mike Sanket Desai wrote: > Hello Every one, > > I am having errors while building the "ALL_BUILD" in > solution explorer of MSVC2008 express edition , i also have updated the > libboost library files from vc80 to vc90 as suggested on jodiah jensen's > page http://wiki.secondlife.com/wiki/User:Jodiah_Jensen#HOW_I_COMPILED_SL_SOURCE_w.2F_VC.2B.2B_2008_Express_Edition . > Even after doingthe things instructed ,i am stuck up with these errors, > can any one help me with this ..... From monkowsk at watson.ibm.com Wed Aug 12 08:50:15 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 12 Aug 2009 11:50:15 -0400 Subject: [sldev] The challenge; Was: More crash rate statistics In-Reply-To: <4A7CB07F.9070800@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: <4A82E4B7.6010607@watson.ibm.com> That's easy. On the public JIRA, compute the ratio of the number of comments by Lindens to the number of comments by residents. As that number increases, so will quality, performance, reliability, usability, and any other metric that anybody can conceive. It is disingenuous to ask basically, "How do we figure out what the problem is?" when the PJIRA is full of answers. Mike Alex Dailey (Xan Linden) wrote: > Here's a challenge to sldev. Viewer performance is complex, dependent on > bandwidth, hardware, the content on the region, other avatars, and so > on. What do you think a) is the one variable viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. E.g. if you think > viewer fps is the one variable we should care about, what three factors > would you consider most important that influence that value? I realize > this is simplistic, but I'm curious to know from your experience, how > would you quantify viewer performance. > > -Xan Linden From jodiah at my-webhome.com Wed Aug 12 08:59:16 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Wed, 12 Aug 2009 08:59:16 -0700 Subject: [sldev] Building viewer on MSVC2008 express edition Message-ID: <20090812085916.8b0823960ceb6a56f7ddf638f99b00cb.f554899f7c.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/667cd94d/attachment.htm From Kindragon at comcast.net Wed Aug 12 12:45:07 2009 From: Kindragon at comcast.net (Obsidian Kindragon) Date: Wed, 12 Aug 2009 13:45:07 -0600 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. Message-ID: <4A831BC3.1010607@comcast.net> Hey everyone, I noticed this Feature Enhancement requesting the ability to add multiple attachments to the same attachment point, and someone even provided a small mod to the Avatar_lad.xml file that allows one to have 3 attachments per point on the body, and even adds a few new (and long requested) points as well. My question is why hasn't LL added the support for these additional attachments into any of the official clients? It only requires adding the additional points to the one xml file and the sooner LL opts to support an extended standard the better or people will start assigning random numbers to various attachment points when they edit the file themselves. Here's a link to the site with the mod file and instructions: http://crystalserver.freehostia.com/slattachments.php Here are different cons and pros regarding this addition to the client that I've been able to see. 1. Only users with the mod / extended Avatar_lad.xml file will be able to see the attachments on the extended points. This is why I feel that LL needs to add support for these extended attachment points now rather than later. The longer LL waits, the more this user-defined mod will pass around and the harder it will be for LL to steer users to their own extension of the attachment system. 2. Having multiple attachments to the same point allows users to further customize their avatars with "additions" worn on top of other attachments. The current situation for builders is that they may want to make an item that uses an attachment point (e.g. "furry paw on a hand attachment point") but don't want to prevent their buyers from wearing a "glove" attachment, so the builder has to set their item to "modable" so the buyer can link the glove to the paw. Adding the ability to wear two attachments on the hand allows the builder to set the paw to "no mod" if desired because the buyer can just wear the glove on top of the paw using the second attachment point on the same hand. This effectively would replace the need to detach, link two items together, and then wear the new "composite" item which requires that both items be modable, and preferably copiable as well. 3. Additional attachments allow griefers / abusers of attachments wear more heavy lag attachments. This is already an abusable situation we have with the number of attachment points that currently exist. We also already have means of reducing this form of abuse in muting the griefer with an excessive number of prims/attachments and preventing the client from rendering their attachments. Adding more attachment points will not increase in the number of issues with griefing avatars wearing excessive attachments, it just gives more freedom for builders and users to more easily customize their avatars. 4. The "Attach To" option in the menus are large and overflowing with the mod. This could be corrected with a future addition by adding a more logical and dynamic menu for choosing where to attach an object. I feel that the benefits adding the additional functionality before the additional UI improvement far outweighs the clutter. 5. The mod adds a "neck" attachment point for objects that need to move with the neck and not the head or torso. This is an attachment point that was long requested by builders. Some avs use attachments that need to bend and move with the neck, but only having the torso or head to use. This resulted in either using the torso for neck attachments (stiff-necked avs) or the head attachment points which results in the neck attachment moving far off the actual neck. 6. The mod adds "script" attachment points for unseen obejcts that are attached just to run scripts. This is useful for objects that have no need to be seen, but provide a useful function through its scripts. Translators, some AOs, typing overrides, hug/kiss control, etc, would all benefit from being able to attach to these points where they are only used for the scripts inside and not take up a body attachment point. If anyone can see other pros and cons to having these additional attachment points, I think we'd all love to hear. And if LL is already working on attachment extensions, then I'm sure we'd all like to know what's being done in that regard. VWR-489 hasn't had any Linden interaction for a long time now. - Obsidian Stormwind From marinekelley at gmail.com Wed Aug 12 13:02:13 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Wed, 12 Aug 2009 22:02:13 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <4A831BC3.1010607@comcast.net> References: <4A831BC3.1010607@comcast.net> Message-ID: <9e52a8c10908121302g4978ae30y991a843c86fb805b@mail.gmail.com> Hi, I would very much love to see this hit the official client... I have adapted the RestrainedLife viewer to handle this with its shared outfits, and it works wonders. No bug spotted except that those who don't have the same XML file won't see the attachments worn correctly. So what are we waiting for ? :) Marine Ps : Sorry Obsidian for the double reply, the first time I replied only to you. Thanks Gmail 2009/8/12 Obsidian Kindragon > Hey everyone, > > I noticed this Feature Enhancement requesting the ability to add > multiple attachments to the same attachment point, and someone even > provided a small mod to the Avatar_lad.xml file that allows one to have > 3 attachments per point on the body, and even adds a few new (and long > requested) points as well. My question is why hasn't LL added the > support for these additional attachments into any of the official > clients? It only requires adding the additional points to the one xml > file and the sooner LL opts to support an extended standard the better > or people will start assigning random numbers to various attachment > points when they edit the file themselves. > > Here's a link to the site with the mod file and instructions: > http://crystalserver.freehostia.com/slattachments.php > > Here are different cons and pros regarding this addition to the client > that I've been able to see. > > 1. Only users with the mod / extended Avatar_lad.xml file will be able > to see the attachments on the extended points. > > This is why I feel that LL needs to add support for these extended > attachment points now rather than later. The longer LL waits, the more > this user-defined mod will pass around and the harder it will be for LL > to steer users to their own extension of the attachment system. > > 2. Having multiple attachments to the same point allows users to further > customize their avatars with "additions" worn on top of other attachments. > > The current situation for builders is that they may want to make an item > that uses an attachment point (e.g. "furry paw on a hand attachment > point") but don't want to prevent their buyers from wearing a "glove" > attachment, so the builder has to set their item to "modable" so the > buyer can link the glove to the paw. Adding the ability to wear two > attachments on the hand allows the builder to set the paw to "no mod" if > desired because the buyer can just wear the glove on top of the paw > using the second attachment point on the same hand. > > This effectively would replace the need to detach, link two items > together, and then wear the new "composite" item which requires that > both items be modable, and preferably copiable as well. > > 3. Additional attachments allow griefers / abusers of attachments wear > more heavy lag attachments. > > This is already an abusable situation we have with the number of > attachment points that currently exist. We also already have means of > reducing this form of abuse in muting the griefer with an excessive > number of prims/attachments and preventing the client from rendering > their attachments. Adding more attachment points will not increase in > the number of issues with griefing avatars wearing excessive > attachments, it just gives more freedom for builders and users to more > easily customize their avatars. > > 4. The "Attach To" option in the menus are large and overflowing with > the mod. > > This could be corrected with a future addition by adding a more logical > and dynamic menu for choosing where to attach an object. I feel that the > benefits adding the additional functionality before the additional UI > improvement far outweighs the clutter. > > 5. The mod adds a "neck" attachment point for objects that need to move > with the neck and not the head or torso. > > This is an attachment point that was long requested by builders. Some > avs use attachments that need to bend and move with the neck, but only > having the torso or head to use. This resulted in either using the torso > for neck attachments (stiff-necked avs) or the head attachment points > which results in the neck attachment moving far off the actual neck. > > 6. The mod adds "script" attachment points for unseen obejcts that are > attached just to run scripts. > > This is useful for objects that have no need to be seen, but provide a > useful function through its scripts. Translators, some AOs, typing > overrides, hug/kiss control, etc, would all benefit from being able to > attach to these points where they are only used for the scripts inside > and not take up a body attachment point. > > If anyone can see other pros and cons to having these additional > attachment points, I think we'd all love to hear. And if LL is already > working on attachment extensions, then I'm sure we'd all like to know > what's being done in that regard. VWR-489 hasn't had any Linden > interaction for a long time now. > > - Obsidian Stormwind > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/03fcc379/attachment.htm From aleric.inglewood at gmail.com Wed Aug 12 14:03:28 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 12 Aug 2009 23:03:28 +0200 Subject: [sldev] More crash rate statistics In-Reply-To: <4A7CB07F.9070800@lindenlab.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> Message-ID: <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> With the risk to alienate myself, I thought I'd take up the challenge and give my view of the problem... There are two measures: the FPS (F) and the quality (Q) of the image per frame. We want both to be high, but the higher the quality the lower the FPS. You could draw a 2D graph of "image quality" against FPS, which would give you a line. Let F be the FPS and Q the perceived quality (for which one might be able to construct a complex mathematical model, but in general it's unclear), then F = C / f(Q) where f is monotonic in Q (df/dQ > 0 everywhere). Depending on the "environment" (E), hardware, avatars, region and so on, this line will be different, roughly: F = C(E) / f(Q) where C is some function of E. The viewer has no influence on the environment (E), but it has influence on C : better viewer code means larger C for the same E. Aside from that, the viewer has influence on Q: where on the line we are. Each individual user will have a different point on any given curve that he or she perceives as the best balance between quality and FPS; in theory we allow them to choose this in the 'Graphics' tab of the preferences. However, in theory the optimal point (per user) is ALSO a function of the environment. Thus, imagine the curve F_E(Q) (F suffix E, function of Q as above) with one optimal point P, then vary E, constantly choosing again the optimal point P, this gives a different curve: P(E). It is this curve that the user should be able to choose. Imho, even though the curve might be different for different users, what the viewer current does is something TOTALLY different from the ideal curve. For example, a user might choose the following simplistic demand: * If the FPS is higher than 20, I don't care about FPS anymore, I just want the highest possible quality. * If the FPS drops below 5, I don't care about the quality anymore, do whatever is needed to give me at LEAST a FPS of 5. For every viewer variable 'k' that determines Quality (for example, the LOD as function of distance: LOD ~ k / d, where d is the distance) you could allow the user to choose two {k, FPS} pairs: the minimum point and the maximum point. Then interpolate between those, as long as the FPS is between those limits and really make k subordinate to FPS when it goes too low or too high. Of course, you need some not-so-simple mathematical model to determine the k-vector (all the values of different k) when the FPS goes too high or too low, but essentially that is the same as solving some differential equation where you can literally measure the effect of small changes, and that way find the optimal point where you weight each k value by their average derivative of FPS inside the interval. For example... User chooses for parameter k1 : {0.5, 5} and {2.0, 20} Then we say: apparently a change of a factor in k (from 0.5 to 2.0, is worth a change of a factor of 4 in the FPS (from 5 to 20) and thus FPS can be weighted with k1. For parameter k2: {1.0, 10} and {2.0, 50}, then weight factor is k2^(ln(50/10) / ln(2.0/1.0)) = k2^2.32. So, if in a given environment the FPS drops below 5 (just below 10 would dictate k1 and we'd only have to change k2) we know that we want keep k1 / k2^2.32 constant, and thus only have a single variable left to decrease in order to get a FPS of 5 again. > Here's a challenge to sldev. Viewer performance is complex, dependent on > bandwidth, hardware, the content on the region, other avatars, and so > on. What do you think a) is the one variable viewer performance should > ultimately be measured by and b) what are, say, three predictive > variables that influence the dependent variable. E.g. if you think > viewer fps is the one variable we should care about, what three factors > would you consider most important that influence that value? I realize > this is simplistic, but I'm curious to know from your experience, how > would you quantify viewer performance. > > -Xan Linden From aleric.inglewood at gmail.com Wed Aug 12 14:15:51 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Wed, 12 Aug 2009 23:15:51 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <9e52a8c10908121302g4978ae30y991a843c86fb805b@mail.gmail.com> References: <4A831BC3.1010607@comcast.net> <9e52a8c10908121302g4978ae30y991a843c86fb805b@mail.gmail.com> Message-ID: <1e01733d0908121415ta5a13a6o79664eaacfa7a493@mail.gmail.com> On Wed, Aug 12, 2009 at 10:02 PM, Marine Kelley wrote: > So what are we waiting for ? :) If this is done, then it should be done Correctly(tm). Not just allow more more attachments, that is not really that easy to maintain by the user. I think that each attachment should have a bit mask for community assignable categories (though nothing more than hinting my LL is needed, by picking the right names for each bit, and leaving a few open for arbitrary use). An existing attachment, then, should be automatically removed if it has any bit set in it's mask that is also set in the mask of the new attachment. Backwards compatibility is than easily achieved by setting all bits in the mask for existing content attachments. The user should be able to change the bits in the mask of ANY attachment even no mod attachments. This is very important. I'm not sure of the current way SL works will allow a variable part for no mod objects. From joel.foner at gmail.com Wed Aug 12 14:18:04 2009 From: joel.foner at gmail.com (Joel Foner) Date: Wed, 12 Aug 2009 17:18:04 -0400 Subject: [sldev] More crash rate statistics In-Reply-To: <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> Message-ID: <7c58f6610908121418l2196767bu94e3d49b419c335b@mail.gmail.com> If there were a way to make the rendering of name and group tags more efficient it would go a long way to improved viewer performance in crowds. In several cases in busy crowds (looking at an area with 40+ avatars) I have seen FPS jump by as much as 40% merely by disabling name and group tag display. This seems like it ought to be low hanging fruit for someone who can figure out a better algorithm :) I hope this helps, Joel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/6f85282d/attachment-0001.htm From jodiah at my-webhome.com Wed Aug 12 16:30:00 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Wed, 12 Aug 2009 16:30:00 -0700 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. Message-ID: <20090812163000.8b0823960ceb6a56f7ddf638f99b00cb.eff9c730ca.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/8e0be73f/attachment.htm From Kindragon at comcast.net Wed Aug 12 16:42:23 2009 From: Kindragon at comcast.net (Obsidian Kindragon) Date: Wed, 12 Aug 2009 17:42:23 -0600 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <20090812163000.8b0823960ceb6a56f7ddf638f99b00cb.eff9c730ca.wbe@email.secureserver.net> References: <20090812163000.8b0823960ceb6a56f7ddf638f99b00cb.eff9c730ca.wbe@email.secureserver.net> Message-ID: <4A83535F.70108@comcast.net> "1) LSL Scripting allows manipulation of attachments, and for attachments to continue to work properly, changes would need to be made to server code to handle the multiple attachments." Actually, this is one of the neat parts you can see from the link. The only code that needed to be changed was in the one file. There are new constants declared that can be called from the client, as it's jsut a reference number for attachment point. "2) More attachments will impact the 'silicon footprint' of avatars (it could be that LL is still pondering the impact of this change to performance of both server code and client)." Well I guess the question is, is having a "furry paw", a "glove", and then a "sword" attached to the same spot more expensive than having those three items linked together and then worn on the attachment point? Possibly, because it'd require three calls to the asset server to recover the attachments. But does that outweight the usefulness and simplification of allowing a user to be able to just take off the "sword", "glove", or "furry paw" independent of the other objects? We did see mention that this is already included in the RestrainedLife viewer and no averse issues have been encountered so far, and I've yet to see any averse issues after installing the mod on my end. - Obsidian Stormwind jodiah at my-webhome.com wrote: > Hi all, > > I would love to see more atachment points, or multiple attachments per > point, but I have a couple of thoughts on the matter. > > Some things that haven't been mentioned here that I think should be > mentioned... > > Implementing multiple attachments per attachment point has > implications beyond the client. > > 1) LSL Scripting allows manipulation of attachments, and for > attachments to continue to work properly, changes would need to be > made to server code to handle the multiple attachments. > > 2) More attachments will impact the 'silicon footprint' of avatars > (it could be that LL is still pondering the impact of this change to > performance of both server code and client). > > 3) probably a lot of other stuff I haven't thought of or mentioned here :) > > I believe these points may be (contributing to) why we have not seen > the multiple attachment change rolled into an official viewer yet. > > Great idea, just a bit more complex than it looks at first glance, I > think. > > Regards, > Jodiah > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From jodiah at my-webhome.com Wed Aug 12 16:53:24 2009 From: jodiah at my-webhome.com (jodiah at my-webhome.com) Date: Wed, 12 Aug 2009 16:53:24 -0700 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. Message-ID: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090812/73e45b6e/attachment.htm From stickman at gmail.com Thu Aug 13 04:16:54 2009 From: stickman at gmail.com (Stickman) Date: Thu, 13 Aug 2009 04:16:54 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> Message-ID: > For example, a user might choose the following simplistic demand: > > * If the FPS is higher than 20, I don't care about FPS anymore, > ?I just want the highest possible quality. > > * If the FPS drops below 5, I don't care about the quality anymore, > ?do whatever is needed to give me at LEAST a FPS of 5. Yay, fancy math! You even got some layman in there for the rest of us. I remember seeing a train traveling earlier, and it disappeared into the distance. I'm not sure where it will end up, but this is what I saw, and where I saw it headed. 1) LL is worried about viewer performance involving very high polycount items. In an effort improve the overall viewer experience, they take the ISP route of cutting off those people that use 100% of the connection bandwidth 100% of the time by imposing some ridiculously high limit that no one will ever hit. In theory. This fix goes into viewer 1.23. 2) http://jira.secondlife.com/browse/VWR-13868 happens. I'm sure everyone remembers the magic 172 sculpty prim necklace that consists of over a quarter-million tris at full resolution. (I've got an old rant about the acceptability of such an item, so I won't restate if it's "right" or "wrong" to create an item like this.) 3) Somehow, LL manages to remain calm in the face of some of the ... er... "bug confirmations" and admits that there was probably a better way to do this. One Linden or another mention how it would be possible to get in a rendering system to give priority detail to things closer to the center of the camera, based on distance, movement speed, etc. And how it actually wouldn't be that hard to put in. (Q? Qarl? Nyx? I totally can't remember. Maybe it was Melinda?) Thus, they would get their goal of a better, safer render, without breaking such "high end" content as said necklace. 4) The train has moved over the horizon. This bug is now marked "Fix Pending" but I remember hearing an argument that a new 1.23 will not be released with the fix. I'm not sure if the fix is just taking it out while they work on a different solution, or the other solution already being in place -- and if it is, whether or not it's some fancy system involving changing object detail based on location, distance, and speed, and perhaps even current FPS. I tend to be a bit more optimistic than I should be sometimes, so don't take any of this as indicative of anything. I'd be interested to hear the real resolution to that Jira if someone has it, though I'd be a little sad if it wasn't what Mr. Inglewood already said. Since that solution seems to make so much sense to me. -Stickman From stickman at gmail.com Thu Aug 13 04:42:22 2009 From: stickman at gmail.com (Stickman) Date: Thu, 13 Aug 2009 04:42:22 -0700 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> Message-ID: More attachment points has been brought up before. The solution, as I see Lindens leaning towards and as makes the most sense to me, is this: *Able to attach as many attachments as desired to any given slot. *Able to attach a maximum of 30 attachments total (which is the current maximum) Me? I just want my missing neck attachment slot. Out of all the parts of the avatar you can animate, the neck is the only one that's actually missing an attachment slot. Everything else has at least one. Also, as I've mentioned a few times already, the pectoral attachment slots actually line up to the "abdomen" when considered for animation. Everything I'd read in the past called the pectoral attachments useless. That's just because they're misleadingly named. One of the many things I'm looking forward to is improvement on the attachment system. But like you said, it's really the Linden's call. -Stickman From marinekelley at gmail.com Thu Aug 13 05:40:38 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Thu, 13 Aug 2009 14:40:38 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> Message-ID: <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> Actually many people need more objects on more attach points, so a limit of 30 objects would be a bit low. And as the viewers are able to throttle the polygon count when the rendering gets heavy, a limit would not make much sense. Or let the user set it instead of imposing it, in case of visual griefing. I'm all against arbitrary limits anyway. And yes, the two pectoral attachments make no sense... Marine On 13 ao?t 2009, at 13:42, Stickman wrote: > More attachment points has been brought up before. The solution, as I > see Lindens leaning towards and as makes the most sense to me, is > this: > > *Able to attach as many attachments as desired to any given slot. > *Able to attach a maximum of 30 attachments total (which is the > current maximum) > > Me? I just want my missing neck attachment slot. Out of all the parts > of the avatar you can animate, the neck is the only one that's > actually missing an attachment slot. Everything else has at least one. > > Also, as I've mentioned a few times already, the pectoral attachment > slots actually line up to the "abdomen" when considered for animation. > Everything I'd read in the past called the pectoral attachments > useless. That's just because they're misleadingly named. > > One of the many things I'm looking forward to is improvement on the > attachment system. But like you said, it's really the Linden's call. > > -Stickman > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From stickman at gmail.com Thu Aug 13 06:03:23 2009 From: stickman at gmail.com (Stickman) Date: Thu, 13 Aug 2009 06:03:23 -0700 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> Message-ID: > And as the viewers are able to throttle the > polygon count when the rendering gets heavy Wait, when did that happen? I was just blabbering about how it was a "hopeful long term fix pending" to http://jira.secondlife.com/browse/VWR-13868 in another thread. I wasn't aware anything like that existed in the client yet. -Stickman From sllists at boroon.dasgupta.ch Thu Aug 13 06:19:00 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu, 13 Aug 2009 15:19:00 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <1e01733d0908121415ta5a13a6o79664eaacfa7a493@mail.gmail.com> References: <4A831BC3.1010607@comcast.net> <9e52a8c10908121302g4978ae30y991a843c86fb805b@mail.gmail.com> <1e01733d0908121415ta5a13a6o79664eaacfa7a493@mail.gmail.com> Message-ID: <4A8412C4.7080002@boroon.dasgupta.ch> Aleric Inglewood schrieb: > I think that each attachment should have a bit mask for > community assignable categories > If I'm not mistaken, the modified XML is equivalent to the bit mask solution. You don't have multiple attachments per attachment points but rather more attachment points, some of which happen to have the same position* as already existing ones. So there's a bijective mapping from (attachment position, set mask bit)-pairs to attachment point IDs from the modified XML. What's missing is only the naming of the categories and a GUI that represents the bit mask rather than giving different names to different IDs. * by 'position' I mean the origin of the attachment points' local coordinate system, not the attachments' position within that coordinate system. Of course, implementing it in the bit mask way would make it easy to add fancy extensions, like e.g. attachments that have more then one bit set. (A cyber armor glove with integrated ray gun might replace both other gloves and swords when worn.) Then again, when the bit mask implementation is chosen, the attachment-manipulating LSL functions should probably reflect that too, by a different function signature. Boroondas From marinekelley at gmail.com Thu Aug 13 06:42:25 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Thu, 13 Aug 2009 15:42:25 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> Message-ID: I don't really know... My MacBook Pro is a very good machine and runs SL very well on Windows, but it runs twice as slow on Leopard, often running at lower complexity all by itself, so I assume something throttles the LoD. Take this with a grain of salt though, it may be just me. On 13 ao?t 2009, at 15:03, Stickman wrote: >> And as the viewers are able to throttle the >> polygon count when the rendering gets heavy > > Wait, when did that happen? > > I was just blabbering about how it was a "hopeful long term fix > pending" to http://jira.secondlife.com/browse/VWR-13868 in another > thread. I wasn't aware anything like that existed in the client yet. > > -Stickman From carlo at alinoe.com Thu Aug 13 08:11:44 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 13 Aug 2009 17:11:44 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> Message-ID: <20090813151144.GA30666@alinoe.com> On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: > Actually many people need more objects on more attach points, so a > limit of 30 objects would be a bit low. And as the viewers are able to > throttle the polygon count when the rendering gets heavy, a limit > would not make much sense. Or let the user set it instead of imposing > it, in case of visual griefing. I'm all against arbitrary limits anyway. This is indeed a perfect example of a BAD way to limit things. The number of attachments has nothing whatsoever to do with how much performance is affected. Instead of limitting the number of attachments (or points), the limit should be set on the total number of prims attached, and that limit should be set *high*, so that under no circumstances users will run into it until they try to abuse it for griefing. Separately from that, each individual might be given the choice to make this performance number (the number of total attached prims) a function of their FPS. From aleric.inglewood at gmail.com Thu Aug 13 08:36:52 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Thu, 13 Aug 2009 17:36:52 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <4A8412C4.7080002@boroon.dasgupta.ch> References: <4A831BC3.1010607@comcast.net> <9e52a8c10908121302g4978ae30y991a843c86fb805b@mail.gmail.com> <1e01733d0908121415ta5a13a6o79664eaacfa7a493@mail.gmail.com> <4A8412C4.7080002@boroon.dasgupta.ch> Message-ID: <1e01733d0908130836v1767f9f6oa9b3773e33e6ea59@mail.gmail.com> Hey Boroondas, indeed-- to an extend it would allow for equivalent manipulations of attachments if you'd have: Chest1 Chest2 Chest3 Chest4 Chest5 Chest6 Chest7 Chest8 etc attachment points, instead of Chest + 32bit mask. But indeed, the former would be equivalent only with the latter if the latter was restricted to having a single bit set in the mask; which would void the need of a mask altogether (you could just use a number). What I want to make possible is "automatic" removal of attachments when the user wants that. You cannot in advance think of when a user wants that because the possibilities are endless. Hence, we need a system that allows as much as possible. An example would be: I can have the following attachments on my 'chest': * A tickler (invisible object that makes me laugh when clicked) * A colar (extension of my coat). * A necklace * A hoodie (extension of my shirt) * A titler (displays a text above my head) * A hugger (could be attached elsewhere, of course) * A second necklace (really, a 'military nametag' type of thing). Most of those should NOT remove any of the others, but now I find that the colar 'sticks' through the hoodie, so I (the user) decides that if the hoodie is attached, the colar has to go. However, I have another shirt with a different colar, and that colar is not sticking through the hoodie, so I don't want to replace that colar when the hoodie is attached. However, if I change shirts than I want one colar to replace the other. This would be possible when using a bitmask, not when using just a heap of attachment points. On Thu, Aug 13, 2009 at 3:19 PM, Boroondas Gupte wrote: > Aleric Inglewood schrieb: >> I think that each attachment should have a bit mask for >> community assignable categories >> > If I'm not mistaken, the modified XML is equivalent to the bit mask > solution. You don't have multiple attachments per attachment points but > rather more attachment points, some of which happen to have the same > position* as already existing ones. So there's a bijective mapping from > (attachment position, set mask bit)-pairs to attachment point IDs from > the modified XML. What's missing is only the naming of the categories > and a GUI that represents the bit mask rather than giving different > names to different IDs. > > * by 'position' I mean the origin of the attachment points' local > coordinate system, not the attachments' position within that coordinate > system. > > > Of course, implementing it in the bit mask way would make it easy to add > fancy extensions, like e.g. attachments that have more then one bit set. > (A cyber armor glove with integrated ray gun might replace both other > gloves and swords when worn.) Then again, when the bit mask > implementation is chosen, the attachment-manipulating LSL functions > should probably reflect that too, by a different function signature. > > Boroondas > From tayra.dagostino at gmail.com Thu Aug 13 11:09:09 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Thu, 13 Aug 2009 20:09:09 +0200 Subject: [sldev] [sldev-commits] Successful Build for trunk (2598) In-Reply-To: <20090813162211.E8F203DBC447@tammy.lindenlab.com> References: <20090813162211.E8F203DBC447@tammy.lindenlab.com> Message-ID: <20090813200909.af227423.tayra.dagostino@gmail.com> On Thu, 13 Aug 2009 09:22:11 -0700 (PDT) buildadmin at lindenlab.com wrote: > > > Linux: > http://secondlife.com/developers/opensource/downloads/2009/trunk/2598/Snowglobe-i686-1.1.0.2598.tar.bz2 still: 2009-08-13T18:02:06Z WARNING: LLViewerImage::setIsMissingAsset: 7138d410-a0cb-09a1-c4db-9d633282f38b: Marking image as missing with texture opened from inventory....... (both with "old" cache or just cleaned) From robla at lindenlab.com Thu Aug 13 12:22:24 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 13 Aug 2009 12:22:24 -0700 Subject: [sldev] adult_compliant flag (SVC-4644) Message-ID: Hi folks, If you have a viewer, and want to make sure adult regions show up as "adult", make sure you implement the new "adult_compliant" flag documented here: http://wiki.secondlife.com/wiki/Current_login_protocols There are other much hackier ways to make this work, but as of today, this is the most reliable way to do it. The viewer code is here: http://svn.secondlife.com/trac/linden/changeset/2573 ...and the issue in JIRA discussing this further is here: http://jira.secondlife.com/browse/SVC-4644 Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090813/8ce8c242/attachment.htm From melinda at superliminal.com Thu Aug 13 12:41:57 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 13 Aug 2009 12:41:57 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> Message-ID: <4A846C85.3060004@superliminal.com> Stickman wrote: >> For example, a user might choose the following simplistic demand: >> >> * If the FPS is higher than 20, I don't care about FPS anymore, >> I just want the highest possible quality. >> >> * If the FPS drops below 5, I don't care about the quality anymore, >> do whatever is needed to give me at LEAST a FPS of 5. >> > > ...] One Linden or another mention how it would be possible > to get in a rendering system to give priority detail to things closer > to the center of the camera, based on distance, movement speed, etc. > And how it actually wouldn't be that hard to put in. (Q? Qarl? Nyx? I > totally can't remember. Maybe it was Melinda?) Thus, they would get > their goal of a better, safer render, without breaking such "high end" > content as said necklace. Yes, that was me. I couldn't find the original paper at that time but I tried a second search just now and this time I found it. It was presented at SIGGRAPH '93 titled "Adaptive Display Algorithm for Interactive Frame Rates During Visualization of Complex Virtual Environments" by Thomas Funkhouser and Carlo S?quin (two of my favorite researchers, BTW). The algorithm is extremely elegant if a little tricky to code but it works quite well. Here is their paper: http://www.cs.princeton.edu/~funk/sig93.pdf -Melinda From dmahalko at gmail.com Fri Aug 14 00:10:31 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Fri, 14 Aug 2009 02:10:31 -0500 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <20090813151144.GA30666@alinoe.com> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: >> Actually many people need more objects on more attach points, so a >> limit of 30 objects would be a bit low. And as the viewers are able to > > Instead of limitting the number of attachments (or points), > the limit should be set on the total number of prims attached, > and that limit should be set *high*, so that under no circumstances > users will run into it until they try to abuse it for griefing. Actually the attachment limit should probably be more granular than the number of prims, going all the way down to the number of triangles per face of the prims being attached. So set the limit at (random example) 40,000 triangles per avatar at any one time. You may wear any number of attachments and prim linksets up to 40,000 triangles, but once you hit that limit, the server prevents any further attachments. This would also provide defense against "griefer attachments" such that sure, you can wear one ultra-detail attachment if you like, but that is going to limit what else you can attach to your avatar, and you certainly can't wear 30 ultra-detail attachments at once. If this were implemented, on login to the world, the sim would check the attachments on avatars and force detachment of objects until the avatar is under the set 40,000 triangle limit, and inform the user what has occurred. This could become a server adjustable limit that estate owners can specify. "To attend this concert you may only have 5,000 triangles across all attachments to assure good sim speed for everyone, or you will be denied teleport access." And there would need to be a "triangle readout" somewhere, to help people manage triangles in use, such as an info item in the avatar profile. Doing this would generally help people to become more directly aware of the "weight" of various types of prims and how it affects simulator and rendering performance. - Dale From carlo at alinoe.com Fri Aug 14 02:28:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 14 Aug 2009 11:28:55 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <20090814092855.GA8161@alinoe.com> On Fri, Aug 14, 2009 at 02:10:31AM -0500, Dale Mahalko wrote: > Actually the attachment limit should probably be more granular than > the number of prims, going all the way down to the number of triangles > per face of the prims being attached. Agreed > So set the limit at (random example) 40,000 triangles per avatar at > any one time. You may wear any number of attachments and prim linksets > up to 40,000 triangles, but once you hit that limit, the server > prevents any further attachments. The limit should really be user definable and be a function of the FPS. But, a very important number would be the *default* that is set (by LL), because that will determine who most people will perceive a given scene. The default should be pretty high, to avoid that noobs won't see content like jewelery wrongly. If a user *wants* to see missing prims then that should be conscious choice of that user. Implementing this limit serverside would be a mistake, since it is a client problem: a large number of triangles are hard to render. Different clients will have problems at a different number of triangles. If a minority of the users has an old, slow PC from the 90's then that doesn't mean that someone with a state of the art gaming PC should have the same limit! -- Carlo Wood From missannotoole at yahoo.com Fri Aug 14 02:30:13 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 14 Aug 2009 02:30:13 -0700 (PDT) Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <759091.57293.qm@web59106.mail.re1.yahoo.com> This is going political. The discussion needs to move to pjira. Or be canceled if LL is not going to implement this feature anyway. ________________________________ From: Dale Mahalko To: Carlo Wood Cc: SLDev Mailing List Sent: Friday, August 14, 2009 3:10:31 AM Subject: Re: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: >> Actually many people need more objects on more attach points, so a >> limit of 30 objects would be a bit low. And as the viewers are able to > > Instead of limitting the number of attachments (or points), > the limit should be set on the total number of prims attached, > and that limit should be set *high*, so that under no circumstances > users will run into it until they try to abuse it for griefing. Actually the attachment limit should probably be more granular than the number of prims, going all the way down to the number of triangles per face of the prims being attached. So set the limit at (random example) 40,000 triangles per avatar at any one time. You may wear any number of attachments and prim linksets up to 40,000 triangles, but once you hit that limit, the server prevents any further attachments. This would also provide defense against "griefer attachments" such that sure, you can wear one ultra-detail attachment if you like, but that is going to limit what else you can attach to your avatar, and you certainly can't wear 30 ultra-detail attachments at once. If this were implemented, on login to the world, the sim would check the attachments on avatars and force detachment of objects until the avatar is under the set 40,000 triangle limit, and inform the user what has occurred. This could become a server adjustable limit that estate owners can specify. "To attend this concert you may only have 5,000 triangles across all attachments to assure good sim speed for everyone, or you will be denied teleport access." And there would need to be a "triangle readout" somewhere, to help people manage triangles in use, such as an info item in the avatar profile. Doing this would generally help people to become more directly aware of the "weight" of various types of prims and how it affects simulator and rendering performance. - Dale _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090814/da8be27a/attachment.htm From missannotoole at yahoo.com Fri Aug 14 02:30:13 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 14 Aug 2009 02:30:13 -0700 (PDT) Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <759091.57293.qm@web59106.mail.re1.yahoo.com> This is going political. The discussion needs to move to pjira. Or be canceled if LL is not going to implement this feature anyway. ________________________________ From: Dale Mahalko To: Carlo Wood Cc: SLDev Mailing List Sent: Friday, August 14, 2009 3:10:31 AM Subject: Re: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: >> Actually many people need more objects on more attach points, so a >> limit of 30 objects would be a bit low. And as the viewers are able to > > Instead of limitting the number of attachments (or points), > the limit should be set on the total number of prims attached, > and that limit should be set *high*, so that under no circumstances > users will run into it until they try to abuse it for griefing. Actually the attachment limit should probably be more granular than the number of prims, going all the way down to the number of triangles per face of the prims being attached. So set the limit at (random example) 40,000 triangles per avatar at any one time. You may wear any number of attachments and prim linksets up to 40,000 triangles, but once you hit that limit, the server prevents any further attachments. This would also provide defense against "griefer attachments" such that sure, you can wear one ultra-detail attachment if you like, but that is going to limit what else you can attach to your avatar, and you certainly can't wear 30 ultra-detail attachments at once. If this were implemented, on login to the world, the sim would check the attachments on avatars and force detachment of objects until the avatar is under the set 40,000 triangle limit, and inform the user what has occurred. This could become a server adjustable limit that estate owners can specify. "To attend this concert you may only have 5,000 triangles across all attachments to assure good sim speed for everyone, or you will be denied teleport access." And there would need to be a "triangle readout" somewhere, to help people manage triangles in use, such as an info item in the avatar profile. Doing this would generally help people to become more directly aware of the "weight" of various types of prims and how it affects simulator and rendering performance. - Dale _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090814/da8be27a/attachment-0003.htm From missannotoole at yahoo.com Fri Aug 14 02:30:13 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri, 14 Aug 2009 02:30:13 -0700 (PDT) Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <759091.57293.qm@web59106.mail.re1.yahoo.com> This is going political. The discussion needs to move to pjira. Or be canceled if LL is not going to implement this feature anyway. ________________________________ From: Dale Mahalko To: Carlo Wood Cc: SLDev Mailing List Sent: Friday, August 14, 2009 3:10:31 AM Subject: Re: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: >> Actually many people need more objects on more attach points, so a >> limit of 30 objects would be a bit low. And as the viewers are able to > > Instead of limitting the number of attachments (or points), > the limit should be set on the total number of prims attached, > and that limit should be set *high*, so that under no circumstances > users will run into it until they try to abuse it for griefing. Actually the attachment limit should probably be more granular than the number of prims, going all the way down to the number of triangles per face of the prims being attached. So set the limit at (random example) 40,000 triangles per avatar at any one time. You may wear any number of attachments and prim linksets up to 40,000 triangles, but once you hit that limit, the server prevents any further attachments. This would also provide defense against "griefer attachments" such that sure, you can wear one ultra-detail attachment if you like, but that is going to limit what else you can attach to your avatar, and you certainly can't wear 30 ultra-detail attachments at once. If this were implemented, on login to the world, the sim would check the attachments on avatars and force detachment of objects until the avatar is under the set 40,000 triangle limit, and inform the user what has occurred. This could become a server adjustable limit that estate owners can specify. "To attend this concert you may only have 5,000 triangles across all attachments to assure good sim speed for everyone, or you will be denied teleport access." And there would need to be a "triangle readout" somewhere, to help people manage triangles in use, such as an info item in the avatar profile. Doing this would generally help people to become more directly aware of the "weight" of various types of prims and how it affects simulator and rendering performance. - Dale _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090814/da8be27a/attachment-0004.htm From secret.argent at gmail.com Fri Aug 14 05:19:28 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri, 14 Aug 2009 07:19:28 -0500 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <3E97DDA0-2D10-4255-B7B9-49FF728E08E9@gmail.com> On 2009-08-14, at 02:10, Dale Mahalko wrote: > So set the limit at (random example) 40,000 triangles per avatar at > any one time. You may wear any number of attachments and prim linksets > up to 40,000 triangles, but once you hit that limit, the server > prevents any further attachments. The server would need to generate the mesh for your attachments to see how many triangles there are. I suspect that might cause some lag. From marinekelley at gmail.com Fri Aug 14 05:49:41 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Fri, 14 Aug 2009 14:49:41 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <759091.57293.qm@web59106.mail.re1.yahoo.com> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> <759091.57293.qm@web59106.mail.re1.yahoo.com> Message-ID: <199AB798-BEA2-48C6-9167-DDC8FAF0F4A4@gmail.com> I would like to hear about that too... Are the Lindens going to consider adding points to the avatar_lad.xml file in the standard SL viewer and in snowglobe any time soon ? I'd like to deploy it with the RLV but if only the RLV users see the additional attachments positioned correctly on other avatars that would not make much sense... It is a file that everybody should have on the same version. Marine On 14 ao?t 2009, at 11:30, Ann Otoole wrote: > This is going political. The discussion needs to move to pjira. Or > be canceled if LL is not going to implement this feature anyway. > > From: Dale Mahalko > To: Carlo Wood > Cc: SLDev Mailing List > Sent: Friday, August 14, 2009 3:10:31 AM > Subject: Re: [sldev] [VWR] VWR-489 Multiple Attachments per > Attachment Point. > > On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: > >> Actually many people need more objects on more attach points, so a > >> limit of 30 objects would be a bit low. And as the viewers are > able to > > > > Instead of limitting the number of attachments (or points), > > the limit should be set on the total number of prims attached, > > and that limit should be set *high*, so that under no circumstances > > users will run into it until they try to abuse it for griefing. > > > Actually the attachment limit should probably be more granular than > the number of prims, going all the way down to the number of triangles > per face of the prims being attached. > > So set the limit at (random example) 40,000 triangles per avatar at > any one time. You may wear any number of attachments and prim linksets > up to 40,000 triangles, but once you hit that limit, the server > prevents any further attachments. > > This would also provide defense against "griefer attachments" such > that sure, you can wear one ultra-detail attachment if you like, but > that is going to limit what else you can attach to your avatar, and > you certainly can't wear 30 ultra-detail attachments at once. > > If this were implemented, on login to the world, the sim would check > the attachments on avatars and force detachment of objects until the > avatar is under the set 40,000 triangle limit, and inform the user > what has occurred. > > This could become a server adjustable limit that estate owners can > specify. "To attend this concert you may only have 5,000 triangles > across all attachments to assure good sim speed for everyone, or you > will be denied teleport access." > > And there would need to be a "triangle readout" somewhere, to help > people manage triangles in use, such as an info item in the avatar > profile. > > Doing this would generally help people to become more directly aware > of the "weight" of various types of prims and how it affects simulator > and rendering performance. > > - Dale > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090814/028a15a6/attachment.htm From tayra.dagostino at gmail.com Fri Aug 14 06:27:17 2009 From: tayra.dagostino at gmail.com (Tayra Dagostino) Date: Fri, 14 Aug 2009 15:27:17 +0200 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: <199AB798-BEA2-48C6-9167-DDC8FAF0F4A4@gmail.com> References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> <759091.57293.qm@web59106.mail.re1.yahoo.com> <199AB798-BEA2-48C6-9167-DDC8FAF0F4A4@gmail.com> Message-ID: <20090814152717.74253018.tayra.dagostino@gmail.com> On Fri, 14 Aug 2009 14:49:41 +0200 Marine Kelley wrote: > I would like to hear about that too... Are the Lindens going to > consider adding points to the avatar_lad.xml file in the standard SL > viewer and in snowglobe any time soon ? I'd like to deploy it with > the RLV but if only the RLV users see the additional attachments > positioned correctly on other avatars that would not make much > sense... It is a file that everybody should have on the same version. Before talk about attachment limit i think is better wait some kind of implementation of patch to aid teleport (see Rob Lanphier email of 8 Jul 2009 18:40:27 -0700), actually is already troublematic teleport with a "simple" prim made dress with a simple resize script inside.... number of vertex or triangle in an attachment is a load for viewer, i think (but i don't read deeply viewer code about this) a server should only logoff a agent from a sim and log in another one, and the agent is the parent of all item, so for a server teleport a agent with 3 prims attached and each prim is a cube or teleport sdame agent with 3 toroids attached is same load. maybe the simpliest workaround (but it isn't a solution) is to bind in some way to quality slider in graphic the number of vertex or nodes, i manually raised it (i've some jewells with some problem) and i haven't problem or lag (but i'0ve a quad core with a GTX275 overclocked, i use ULTRA graphic + fsaa4x and anisotropic ever turned on), some "old"[*1] pc may suffer while render about 200 sculpet prims texturized as diamond with partial alpha and more... instead a lot of time i fail a tp and the cause is a dress or hud or attachemtn: i remove it, so i tp in few seconds and re-attach it, as Rob said in email indicated over here maybe is a nice patch take a status of all script inside attachment and hud, froze them (or set norun) and restore the previous script status after tp... i think only after all teleport problem and automatic rendering algo will be the right time to talk about number and kind of attachments... [*1] an old pc may be one bought last christmas... not only a '90s pc; and depend what the user want too, i know a lot of people with historycal pc with "low" graphic quality, they stay on the grid with poligon, no bump, no shadow, nothing, and "live" happy in this way, if i want the top of state of the art in graphic quality my pc is forever "old" starting from next day i bought. From emily at charmageddon.org Fri Aug 14 07:13:27 2009 From: emily at charmageddon.org (Emily) Date: Fri, 14 Aug 2009 09:13:27 -0500 Subject: [sldev] [VWR] VWR-489 Multiple Attachments per Attachment Point. In-Reply-To: References: <20090812165324.8b0823960ceb6a56f7ddf638f99b00cb.549d0edb5d.wbe@email.secureserver.net> <5EADCF12-D1B9-4098-8E37-1081F5ACF843@gmail.com> <20090813151144.GA30666@alinoe.com> Message-ID: <4bc9b48f0908140713l6a18f0e5odee442c62bfd0ddf@mail.gmail.com> On Fri, Aug 14, 2009 at 2:10 AM, Dale Mahalko wrote: > > On Thu, Aug 13, 2009 at 10:11 AM, Carlo Wood wrote: > > On Thu, Aug 13, 2009 at 02:40:38PM +0200, Marine Kelley wrote: > >> Actually many people need more objects on more attach points, so a > >> limit of 30 objects would be a bit low. And as the viewers are able to > > > > Instead of limitting the number of attachments (or points), > > the limit should be set on the total number of prims attached, > > and that limit should be set *high*, so that under no circumstances > > users will run into it until they try to abuse it for griefing. > > > Actually the attachment limit should probably be more granular than > the number of prims, going all the way down to the number of triangles > per face of the prims being attached. > > So set the limit at (random example) 40,000 triangles per avatar at > any one time. You may wear any number of attachments and prim linksets > up to 40,000 triangles, but once you hit that limit, the server > prevents any further attachments. > > This would also provide defense against "griefer attachments" such > that sure, you can wear one ultra-detail attachment if you like, but > that is going to limit what else you can attach to your avatar, and > you certainly can't wear 30 ultra-detail attachments at once. > > If this were implemented, on login to the world, the sim would check > the attachments on avatars and force detachment of objects until the > avatar is under the set 40,000 triangle limit, and inform the user > what has occurred. > > This could become a server adjustable limit that estate owners can > specify. "To attend this concert you may only have 5,000 triangles > across all attachments to assure good sim speed for everyone, or you > will be denied teleport access." > > And there would need to be a "triangle readout" somewhere, to help > people manage triangles in use, such as an info item in the avatar > profile. > > Doing this would generally help people to become more directly aware > of the "weight" of various types of prims and how it affects simulator > and rendering performance. This request for a 1 day change is only up to 2-3 months of work. Wearing both collar and a scarf is easily worth a multi year investment. Surely we aren't trying hard enough. Script count and duty load? Embedded asset counts? Texture sizes and cache hit probability? Triangle batchability? Occlusion ratio from same foot plane? From mwhite at leporidae.net Sat Aug 15 07:38:02 2009 From: mwhite at leporidae.net (Matt White) Date: Sat, 15 Aug 2009 10:38:02 -0400 Subject: [sldev] Snowglobe Crash Logger on Windows Message-ID: Hello! Is the crashlogger working on Windows? Here's why I ask - the most recent Snowglobe builds have been extremely unstable for me. (Win64) I can't make the current one go more than a few minutes without hanging. (Snowglobe doesn't actually crash, but the video freezes, the wind noise doesn't change... it just hangs to the point that I have to kill the Snowglobe process in the process manager to get control back.) Not to mention the texture loading issues, but at least those aren't a crash. I had been putting up with it and still using it thinking that all of these crashes must be generating crash reports that could be useful for trying to figure out what's happening... hoping that my pain could help others. Last night I finally got fed up and downloaded the release client instead, and the first thing that I saw when I ran 1.23.4 was the crash logger telling me that SL had crashed on a previous run... even if it was the first time I had run 1.23.4. It occurred to me right then that I hadn't seen the crash logger on Snowglobe in a long time; I was assuming it was just reporting the crashes back to LL somehow... that might have been a mistake to assume that. Soo... how does this work? Is Snowglobe suppose to be sending crash reports the same way that 1.23.4 does? -- Matt White / Bunny Halberd From stickman at gmail.com Sat Aug 15 12:34:54 2009 From: stickman at gmail.com (Stickman) Date: Sat, 15 Aug 2009 12:34:54 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: <4A846C85.3060004@superliminal.com> References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> <4A846C85.3060004@superliminal.com> Message-ID: > Yes, that was me. I couldn't find the original paper at that time but I > tried a second search just now and this time I found it. It was presented at > SIGGRAPH '93 titled "Adaptive Display Algorithm for Interactive Frame Rates > During Visualization of Complex Virtual Environments" by Thomas Funkhouser > and Carlo S?quin (two of my favorite researchers, BTW). The algorithm is > extremely elegant if a little tricky to code but it works quite well. Here > is their paper: http://www.cs.princeton.edu/~funk/sig93.pdf So which Linden or open source developer do we forward this thread to so they can file it away until such time they work on it? -Stickman From melinda at superliminal.com Sat Aug 15 12:54:22 2009 From: melinda at superliminal.com (Melinda Green) Date: Sat, 15 Aug 2009 12:54:22 -0700 Subject: [sldev] More crash rate statistics In-Reply-To: References: <4A79D4A9.4090101@lindenlab.com> <4A7C5D06.7010608@xp2.de> <4A7CA6FF.1060904@superliminal.com> <4A7CB07F.9070800@lindenlab.com> <1e01733d0908121403n6ebae5b1w402fac4fe2790801@mail.gmail.com> <4A846C85.3060004@superliminal.com> Message-ID: <4A87126E.9060706@superliminal.com> Stickman wrote: >> Yes, that was me. I couldn't find the original paper at that time but I >> tried a second search just now and this time I found it. It was presented at >> SIGGRAPH '93 titled "Adaptive Display Algorithm for Interactive Frame Rates >> During Visualization of Complex Virtual Environments" by Thomas Funkhouser >> and Carlo S?quin (two of my favorite researchers, BTW). The algorithm is >> extremely elegant if a little tricky to code but it works quite well. Here >> is their paper: http://www.cs.princeton.edu/~funk/sig93.pdf >> > > So which Linden or open source developer do we forward this thread to > so they can file it away until such time they work on it? > I think that enough Linden developers monitor this list that it's now known about by enough of the right people. The problem is that all of them are already overworked on higher priority projects. I think the best we can hope for is that one of them decides they really want to do this and then begins to fool with it in their spare time while working to finish or otherwise divest from other projects in the hopes of getting the green light to take this one to completion. -Melinda From lists.secondlife.com at trap.wereanimal.net Sun Aug 16 12:09:38 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Sun, 16 Aug 2009 15:09:38 -0400 Subject: [sldev] GCC 4.x warning patches. Message-ID: <200908161509.39493.lists.secondlife.com@trap.wereanimal.net> I've created snow-193 through 195 with patches that fixes the warnings. I did this when I discover there was a cmake hack that checked for GCC 4.3 and disabled some warnings instead of fixing the code. So I removed the check and started to fix the code. I've split the patch into three parts for easy review and hopefully they will get added. -- Techwolf Lupindo From dahliatrimble at gmail.com Mon Aug 17 13:06:55 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon, 17 Aug 2009 13:06:55 -0700 Subject: [sldev] Licensing of SL avatars and animations Message-ID: The meshes, skeletons, and animations for the SL avatars have been available for download at http://secondlife.com/community/avatar.php however there is no licensing terms listed for these content. I've heard it stated by several people that these are available under Creative Commons, but I cannot find anything which explicitly states this. Also, apparently the morph targets for these meshes have been extracted and formatted for use in 3D applications and are available here: http://www.ccccybernetics.com/avatar_databank/ Where might I look to find explicit licensing terms for these content? Apologies if this is not the proper forum for these questions. Best regards, Dahlia Trimble -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090817/35b2d000/attachment.htm From robertltux at gmail.com Mon Aug 17 17:30:30 2009 From: robertltux at gmail.com (Robert Martin) Date: Mon, 17 Aug 2009 20:30:30 -0400 Subject: [sldev] last couple builds not running on winxp?? Message-ID: Does anybody know why the last couple builds (marked as 1.2 builds 2600 and 2603) would not run on windows xp "configuration not correct"?? have already tried a clean install -- Robert L Martin From jacek.antonelli at gmail.com Mon Aug 17 23:15:33 2009 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Tue, 18 Aug 2009 01:15:33 -0500 Subject: [sldev] Licensing of SL avatars and animations In-Reply-To: References: Message-ID: <105c09f0908172315q529f6e00u4ad7ab44978fc72e@mail.gmail.com> On Mon, Aug 17, 2009 at 3:06 PM, Dahlia Trimble wrote: > > The meshes, skeletons, and animations for the SL avatars have been available > for download at?http://secondlife.com/community/avatar.php however there is > no licensing terms listed for these content. I've heard it stated by several > people that these are available under Creative Commons, but I cannot find > anything which explicitly states this. Also, apparently the morph targets > for these meshes have been extracted and formatted for use in 3D > applications and are available here: >?http://www.ccccybernetics.com/avatar_databank/ > > Where might I look to find explicit licensing terms for these content? I don't know the licensing terms for the content at http://secondlife.com/community/avatar.php . Like you, I don't see any indication of licensing terms. If the Avatar Databank meshes are extracted from the actual SL mesh files (as the site says they are), then those are licensed under the Creative Commons Attribution-Share Alike 3.0 License: http://creativecommons.org/licenses/by-sa/3.0/ The SL avatar meshes (in "LLM" format, LL's custom mesh format) are included in the viewer artwork packages, which you can find at: http://wiki.secondlife.com/wiki/Source_downloads The licensing information for all the viewer artwork is described in the misleadingly-named "LICENSE-logos.txt" file in the "linden" directory of the artwork zip files. The mesh files are in the "linden/indra/newview/character/" directory. As for the animations -- at first glance, the artwork package does not seem to contain them. But, they could be embedded in "linden/indra/newview/app_settings/static_data.db2". They are referenced by asset UUID in "linden/.../app_settings/viewerart.xml" in the source package (see http://tinyurl.com/q8oegb ). So, the licensing status of the animations still seems ambiguous. I'd assume they are "All rights reserved" until/unless there's evidence otherwise. - Jacek From marinekelley at gmail.com Mon Aug 17 23:24:00 2009 From: marinekelley at gmail.com (Marine Kelley) Date: Tue, 18 Aug 2009 08:24:00 +0200 Subject: [sldev] last couple builds not running on winxp?? In-Reply-To: References: Message-ID: <4C220ADF-7CD1-4CFC-A26E-E2E965B0D043@gmail.com> Hi, you're not alone, it seems that since 1.23 the viewer needs some C+ + libraries to run, and some systems do not provide out of the box. I have posted an article about it there : http://realrestraint.blogspot.com/2009/07/having-troubles-running-rlv-119-on.html Marine On 18 ao?t 2009, at 02:30, Robert Martin wrote: > Does anybody know why the last couple builds (marked as 1.2 builds > 2600 and 2603) would not run on windows xp > "configuration not correct"?? > have already tried a clean install > > -- > Robert L Martin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From robla at lindenlab.com Tue Aug 18 00:45:26 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 18 Aug 2009 00:45:26 -0700 Subject: [sldev] last couple builds not running on winxp?? In-Reply-To: References: Message-ID: On Mon, Aug 17, 2009 at 5:30 PM, Robert Martin wrote: > Does anybody know why the last couple builds (marked as 1.2 builds > 2600 and 2603) would not run on windows xp > "configuration not correct"?? > have already tried a clean install Yup, known problem. I believe 2604 should finally fix the problem. As a workaround for an existing build without a full reinstall, make sure the version number of msvcrt.dll matches the newVersion property in the SnowglobeTestBuild.exe.config file, and that the oldVersion property has a valid range of versions. The 2600 build and earlier had a mismatch, while the 2603 build had a mangled oldVersion range. Rob From robin.cornelius at gmail.com Tue Aug 18 00:45:44 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 18 Aug 2009 08:45:44 +0100 Subject: [sldev] last couple builds not running on winxp?? In-Reply-To: <4C220ADF-7CD1-4CFC-A26E-E2E965B0D043@gmail.com> References: <4C220ADF-7CD1-4CFC-A26E-E2E965B0D043@gmail.com> Message-ID: On Tue, Aug 18, 2009 at 7:24 AM, Marine Kelley wrote: > Hi, you're not alone, it seems that since 1.23 the viewer needs some C+ > + libraries to run, and some systems do not provide out of the box. I > have posted an article about it there : > > http://realrestraint.blogspot.com/2009/07/having-troubles-running-rlv-119-on.html > Its not as simple as that, the critical files that are included in the package Marine links to on the blog are provided with the viewer, but the issues have been caused by an incorrect configuration on the windows build server that LL use. The last couple of snowglobe builds would not run for me at all, and i have all the redistributable installed (and most non redistributable as i have Visual Studio 2003/2005 and 2008 installed) and even attempting to install the redistributable did not help. Basically the manifest that is embedded to the exe file says which files it depends on, but also with the Microsoft winSxS stuff the exact version of the file required as well. As i understand Rob had something done to the windows build server and kicked off a new build last night (my time) so if the snowglobe builds are still an issue please ping back here. Robin From robertltux at gmail.com Tue Aug 18 04:57:43 2009 From: robertltux at gmail.com (Robert Martin) Date: Tue, 18 Aug 2009 07:57:43 -0400 Subject: [sldev] Licensing of SL avatars and animations In-Reply-To: <105c09f0908172315q529f6e00u4ad7ab44978fc72e@mail.gmail.com> References: <105c09f0908172315q529f6e00u4ad7ab44978fc72e@mail.gmail.com> Message-ID: On Tue, Aug 18, 2009 at 2:15 AM, Jacek Antonelli wrote: > So, the licensing status of the animations still seems ambiguous. I'd > assume they are "All rights reserved" until/unless there's evidence > otherwise. one odd bit is you can download the set of animations (in bvh format) from the secondlife website -- Robert L Martin From lenglish5 at cox.net Tue Aug 18 10:02:51 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 18 Aug 2009 10:02:51 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance Message-ID: <4A8ADEBB.7030309@cox.net> I can imagine many cases where a media plugin served from localhost might be useful. It should be possible to pecify localhost as a valid url for media-on-a-prim (HUD at least) that is settable separately from, or as an alternative to, the parcel media URL. IOW, if I install a custom HUD with a localhost url as the parcel media url, I should be able to interact with a private plugin running on my own comp. Lawson From anthonyrbundy at gmail.com Tue Aug 18 12:21:25 2009 From: anthonyrbundy at gmail.com (Anthony Bundy) Date: Tue, 18 Aug 2009 12:21:25 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <4A8ADEBB.7030309@cox.net> References: <4A8ADEBB.7030309@cox.net> Message-ID: <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> Does this work:http://en.wikipedia.org/wiki/File_URI_scheme e.g. file:///C:/ Or is it blocked by Quicktime? Tony On Tue, Aug 18, 2009 at 10:02 AM, Lawson English wrote: > I can imagine many cases where a media plugin served from localhost > might be useful. It should be possible to pecify localhost as a valid > url for media-on-a-prim (HUD at least) that is settable separately from, > or as an alternative to, the parcel media URL. > > > IOW, if I install a custom HUD with a localhost url as the parcel media > url, I should be able to interact with a private plugin running on my > own comp. > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090818/2c72c13d/attachment.htm From lenglish5 at cox.net Tue Aug 18 15:09:24 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 18 Aug 2009 15:09:24 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> Message-ID: <4A8B2694.4050309@cox.net> I think the problem is that there's no way for a non-land-owner to SET the url in the first place. Lawson Anthony Bundy wrote: > Does this work: > http://en.wikipedia.org/wiki/File_URI_scheme > e.g. file:///C:/ > Or is it blocked by Quicktime? > Tony > > On Tue, Aug 18, 2009 at 10:02 AM, Lawson English > wrote: > > I can imagine many cases where a media plugin served from localhost > might be useful. It should be possible to pecify localhost as a valid > url for media-on-a-prim (HUD at least) that is settable separately > from, > or as an alternative to, the parcel media URL. > > > IOW, if I install a custom HUD with a localhost url as the parcel > media > url, I should be able to interact with a private plugin running on my > own comp. > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From lenglish5 at cox.net Tue Aug 18 15:46:23 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 18 Aug 2009 15:46:23 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <4A8B2694.4050309@cox.net> References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> <4A8B2694.4050309@cox.net> Message-ID: <4A8B2F3F.6040208@cox.net> Lawson English wrote: > I think the problem is that there's no way for a non-land-owner to SET > the url in the first place. > > Just to clarify: right now, you need to have the ability to set the parcel media URL. When people start producing custom plugins for the media plugin API, that limitation will still exist, as far as I can tell. What is needed is a way for someone to be able to set a media URL or plugin equivalent that is independent of the parcel media URL. The private URL could be directed to a localhost server, or to a private server, or whatever. With a bit of clever hacking, it MAY be possible to integrate existing/future collaboration tools into SL that work independently of the parcel media. FOr example, if a group of people want to play multi-person tic-tac-toe in a HUD, there should be a way for them to privately arrange a URL or other connection to a central server or to each other, independently of there ability to set the parcel media URL. ALong those lines, it would be valuable for businesses to individually set a URL for each person interacting with a prim. That way, several different webpages, plugins, etc could be used, each directed to a specific avatar. Personalized tech support would be possible this way, for example. Of course, the ultimate implementation of this idea would be Croquet-on-a-HUD, which might actually be doable with the new media plugin: http://www.youtube.com/watch?v=NLMkc7sI2-w Lawson From lenglish5 at cox.net Tue Aug 18 16:00:25 2009 From: lenglish5 at cox.net (Lawson English) Date: Tue, 18 Aug 2009 16:00:25 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <4A8B2F3F.6040208@cox.net> References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> <4A8B2694.4050309@cox.net> <4A8B2F3F.6040208@cox.net> Message-ID: <4A8B3289.50803@cox.net> La[...]wson English wrote: > > > Of course, the ultimate implementation of this idea would be > Croquet-on-a-HUD, which might actually be doable with the new media plugin: > > http://www.youtube.com/watch?v=NLMkc7sI2-w > > > Actually, and I'm sure people have thought about this already, since the new plugin API allows for shared memory so that arbitrary streaming video plugins can work with it, the same technique should allow ANY (*ANY*) interactive media, including "excel on a prim" or whatever else can use a private rendering space. One could use localhost servers and/or private webservers and/or p2p servers to do ANYTHING that can be done in a regular application window. Good Show, Linden Lab. Lawson From mitch at mckenzie.ws Tue Aug 18 16:05:46 2009 From: mitch at mckenzie.ws (mitch at mckenzie.ws) Date: Tue, 18 Aug 2009 18:05:46 -0500 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <4A8B2F3F.6040208@cox.net> References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> <4A8B2694.4050309@cox.net> <4A8B2F3F.6040208@cox.net> Message-ID: <4A8B33CA.5030203@mckenzie.ws> Hi Lawson, I had a hud that does alot of what you are talking about, even had a way to implement it that avoided silly parcel limitations by using a single antenna in the sim to make the media call to the agent, not the parcel, but then Soft Linden decided to kill it off and call it a "Bug" after several years in active use on the main grid with out a single compliant. You can see the nasty history here: http://jira.secondlife.com/browse/SVC-4133 ... They decided it could be used to harvest I.P.s even though the current parcel system allows for simple I.P. harvesting just as it sits today. I still have some levels of functionality available, but not near the simplicity for users as it was before they killed it off.Hollar and I will show you my examples in world.. Media Hax Lawson English wrote: > Lawson English wrote: > >> I think the problem is that there's no way for a non-land-owner to SET >> the url in the first place. >> >> >> > > Just to clarify: right now, you need to have the ability to set the > parcel media URL. When people start producing custom plugins for the > media plugin API, that limitation will still exist, as far as I can tell. > > What is needed is a way for someone to be able to set a media URL or > plugin equivalent that is independent of the parcel media URL. > > The private URL could be directed to a localhost server, or to a private > server, or whatever. With a bit of clever hacking, it MAY be possible > to integrate existing/future collaboration tools into SL that work > independently of the parcel media. FOr example, if a group of people > want to play multi-person tic-tac-toe in a HUD, there should be a way > for them to privately arrange a URL or other connection to a central > server or to each other, independently of there ability to set the > parcel media URL. > > ALong those lines, it would be valuable for businesses to individually > set a URL for each person interacting with a prim. That way, several > different webpages, plugins, etc could be used, each directed to a > specific avatar. Personalized tech support would be possible this way, > for example. > > > Of course, the ultimate implementation of this idea would be > Croquet-on-a-HUD, which might actually be doable with the new media plugin: > > http://www.youtube.com/watch?v=NLMkc7sI2-w > > > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > > From Celierra at gmail.com Tue Aug 18 21:24:35 2009 From: Celierra at gmail.com (Celierra Darling) Date: Wed, 19 Aug 2009 00:24:35 -0400 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: <4A8B33CA.5030203@mckenzie.ws> References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> <4A8B2694.4050309@cox.net> <4A8B2F3F.6040208@cox.net> <4A8B33CA.5030203@mckenzie.ws> Message-ID: To support being able to pass media URLs to agents without an associated parcel, I'd direct attention to the spin-off issues (SVC-4272, -4273, or -4274; I think *SVC-4273 * is most relevant here). That did look useful, but it was a bit of a hack, and it probably would have been only a matter of time before the lack of that parcel check would have caused trouble or at least annoyance (ex. something scanner-based radiating into adjacent parcels accidentally, perhaps). But I hope they do turn around and provide one of those better suggestions in its place. Celi On Tue, Aug 18, 2009 at 7:05 PM, mitch at mckenzie.ws wrote: > Hi Lawson, > > I had a hud that does alot of what you are talking about, even had a way > to implement it that avoided silly parcel limitations by using a single > antenna in the sim to make the media call to the agent, not the parcel, > but then Soft Linden decided to kill it off and call it a "Bug" after > several years in active use on the main grid with out a single > compliant. You can see the nasty history here: > http://jira.secondlife.com/browse/SVC-4133 ... They decided it could be > used to harvest I.P.s even though the current parcel system allows for > simple I.P. harvesting just as it sits today. > > I still have some levels of functionality available, but not near the > simplicity for users as it was before they killed it off.Hollar and I > will show you my examples in world.. > > Media Hax > > > > Lawson English wrote: > > Lawson English wrote: > > > >> I think the problem is that there's no way for a non-land-owner to SET > >> the url in the first place. > >> > >> > >> > > > > Just to clarify: right now, you need to have the ability to set the > > parcel media URL. When people start producing custom plugins for the > > media plugin API, that limitation will still exist, as far as I can tell. > > > > What is needed is a way for someone to be able to set a media URL or > > plugin equivalent that is independent of the parcel media URL. > > > > The private URL could be directed to a localhost server, or to a private > > server, or whatever. With a bit of clever hacking, it MAY be possible > > to integrate existing/future collaboration tools into SL that work > > independently of the parcel media. FOr example, if a group of people > > want to play multi-person tic-tac-toe in a HUD, there should be a way > > for them to privately arrange a URL or other connection to a central > > server or to each other, independently of there ability to set the > > parcel media URL. > > > > ALong those lines, it would be valuable for businesses to individually > > set a URL for each person interacting with a prim. That way, several > > different webpages, plugins, etc could be used, each directed to a > > specific avatar. Personalized tech support would be possible this way, > > for example. > > > > > > Of course, the ultimate implementation of this idea would be > > Croquet-on-a-HUD, which might actually be doable with the new media > plugin: > > > > http://www.youtube.com/watch?v=NLMkc7sI2-w > > > > > > > > Lawson > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090819/172c73d9/attachment.htm From lenglish5 at cox.net Thu Aug 20 04:47:03 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 20 Aug 2009 04:47:03 -0700 Subject: [sldev] "parcel" media should include the ability to set local host, at least in a HUD instance In-Reply-To: References: <4A8ADEBB.7030309@cox.net> <277a41080908181221x59f53bafg899e3ccf85809c3b@mail.gmail.com> <4A8B2694.4050309@cox.net> <4A8B2F3F.6040208@cox.net> <4A8B33CA.5030203@mckenzie.ws> Message-ID: <4A8D37B7.70507@cox.net> As usual... I'm not making myself clear... The point is NOT to allow access from a HUD to any arbitrary parcel media, regardless of who owns the land the avatar stands on (that's a separate issue), but to enable the avatar to enable localhost media to interact with the HUD without requiring ANY land/parcel relationship whatsoever. A secondary concern would be to allow enabling of the media URL for any URL that the user deliberately selects from their HUD (not an arbitrary object found somewhere on some bit of land). Example usecases for the first instance: A user has downloaded a special plugin that interacts with the client in order to provide better manipulation of inventory or estate management. Rather than require a separate browser page, as is the case now, a user could simply point the browser to a localhost page that controls the plugin. The media plugin HUD is merely acting as a more immersive version of what already can (and is being done) by pages served by libomv Gridproxy plugins. If the user choses to have a separate webpage for such a control panel, they can already do so, but if one allows the HUD's media URL to point to the local webpage this would provide a nicer-feeling interface to whatever client enhancements someone has obtained. THIS CAPABILITY ALREADY EXISTS but only if you direct a browser (SL or external) to the localhost page served by the gridproxy plugin. There are also usecases where having the ability to set a HUD's media URL to localhost without a genuine plugin (gridproxy or otherwise) would be useful. E.G., if a user downloads the seaside webserver ( http://www.seaside.st ), they get built-in, a reasonably robust blog they can personalize for their own private use, to allow storing notes and so on. Additionally, localhost webapplications can be used to provide other useful Second Life enhancements, regardless of their relationship with the media URL plugin and/or gridproxy-style plugin. E.G., an HUD based drawing app, such as http://canvaspaint.org/ , which already works with the llMedia plugin app or a web-based version of http://www.secondplopp.com More robust web applications could be integrated quite easily with Second LIfe using a combination of the llMediaPlugin plus a hypothetical eventshandler plugin that I've already mentioned to some LIndens that would provide some gridproxy capabilities without the man in the middle proxy (just funnel specific packets and other internal client events to registered external handler plugins for manipulation/enhancement/injection, much the way the llMediaProxy is designed to do for simple GUI events). E.G., semi-professional building tools, for prims, sculpties AND mesh, could be created and run client-side using the llMediaPlugin in a HUD-based interface and allow for injection/display/uploading of the finished product without extra steps that detract from the "in-world" immersion. Whiteboards are possible already using the llMediaPlugin, but would require ownership/access to a public website, which limits their usefulness, and currently require that one have parcel media control anyway, which also limits their usefulness. The ability to point a HUD or even a prim media URL to an arbitrary external URL would enable ad-hoc whiteboards that would work at any arbitrary moment. The ability to point a HUD or prim URL to localhost might enable more sophisticated whiteboards like Croquet-on-a-HUD, where the Croquet client (or moral equivalent) is providing the peer-to-peer capabilities for participating avatars who have established their own P2P connections behind the scenes using whatever external app is suitable. The ability to use a HUD with an arbitrary media URL that isn't controlled by parcel access should be obvious. It extends the LSL Browser HUD model to allow control of external apps with clientside (or client-side LIKE) scripting rather than LSL-serverside apps, and allows true immersion. Localhost URLs are the most easily controlled by regular users, and should be the first to be enabled for this purpose. Less restrictive options can be tested as time goes by both for HUDs and non-HUD prims. Greater synergy can be obtained by using a hypothetical external events handler plugin combined with the llMediaPlugin. I'll list a few of the possibilities in another post. Be warned: the possibilities are, for all practical purposes, limitless. Lawson Celierra Darling wrote: > To support being able to pass media URLs to agents without an > associated parcel, I'd direct attention to the spin-off issues > (SVC-4272, -4273, or -4274; I think *SVC-4273 > * is most relevant here). > That did look useful, but it was a bit of a hack, and it probably > would have been only a matter of time before the lack of that parcel > check would have caused trouble or at least annoyance (ex. something > scanner-based radiating into adjacent parcels accidentally, perhaps). > But I hope they do turn around and provide one of those better > suggestions in its place. > > Celi > > On Tue, Aug 18, 2009 at 7:05 PM, mitch at mckenzie.ws > > wrote: > > Hi Lawson, > > I had a hud that does alot of what you are talking about, even had > a way > to implement it that avoided silly parcel limitations by using a > single > antenna in the sim to make the media call to the agent, not the > parcel, > but then Soft Linden decided to kill it off and call it a "Bug" after > several years in active use on the main grid with out a single > compliant. You can see the nasty history here: > http://jira.secondlife.com/browse/SVC-4133 ... They decided it > could be > used to harvest I.P.s even though the current parcel system allows for > simple I.P. harvesting just as it sits today. > > I still have some levels of functionality available, but not near the > simplicity for users as it was before they killed it off.Hollar and I > will show you my examples in world.. > > Media Hax > > > > Lawson English wrote: > > Lawson English wrote: > > > >> I think the problem is that there's no way for a non-land-owner > to SET > >> the url in the first place. > >> > >> > >> > > > > Just to clarify: right now, you need to have the ability to set the > > parcel media URL. When people start producing custom plugins for the > > media plugin API, that limitation will still exist, as far as I > can tell. > > > > What is needed is a way for someone to be able to set a media URL or > > plugin equivalent that is independent of the parcel media URL. > > > > The private URL could be directed to a localhost server, or to a > private > > server, or whatever. With a bit of clever hacking, it MAY be > possible > > to integrate existing/future collaboration tools into SL that work > > independently of the parcel media. FOr example, if a group of people > > want to play multi-person tic-tac-toe in a HUD, there should be > a way > > for them to privately arrange a URL or other connection to a central > > server or to each other, independently of there ability to set the > > parcel media URL. > > > > ALong those lines, it would be valuable for businesses to > individually > > set a URL for each person interacting with a prim. That way, several > > different webpages, plugins, etc could be used, each directed to a > > specific avatar. Personalized tech support would be possible > this way, > > for example. > > > > > > Of course, the ultimate implementation of this idea would be > > Croquet-on-a-HUD, which might actually be doable with the new > media plugin: > > > > http://www.youtube.com/watch?v=NLMkc7sI2-w > > > > > > > > Lawson > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated > posting privileges > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From kakurady at gmail.com Thu Aug 20 06:16:36 2009 From: kakurady at gmail.com (Kakurady Drakenar) Date: Thu, 20 Aug 2009 09:16:36 -0400 Subject: [sldev] Building (Snowglobe) on VC++2008 Express - boost okay, encoding problems, llmozlib hell? Message-ID: <4A8D4CB4.9030808@gmail.com> All right, I was trying to build Snowglobe with MSVC++2008 Express three times and failed three times. The first time from the vanilla source provided by the Lab. Needless to say the Boost libraries didn't match. At linking stage I had errors like this: |12>libboost_program_options-vc80-mt-1_34_1.lib(cmdline.obj) : error LNK2019: ????????? "__declspec(dllimport) public: class std::_String_iterator,class std::allocator > __thiscall std::basic_string,class std::allocator >::erase(class std::_String_iterator,class std::allocator >)" (__imp_?erase@?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@QAE?AV?$_String_iterator at DU?$char_traits at D@std@@V?$allocator at D@2@@2 at V32@@Z)? ?????? "public: class std::vector,class std::allocator > > __thiscall boost::program_options::detail::cmdline::parse_short_option(class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > &)" (?parse_short_option at cmdline@detail at program_options@boost@@QAE?AV?$vector at V?$basic_option at D@program_options at boost@@V?$allocator at V?$basic_option at D@program_options at boost@@@std@@@std@@AAV?$vector at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@V?$allocator at V?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@2@@6@@Z) ????| So instead of being stuck in a endless loop, the program won't link at all. The second time I built my own Boost libs, but by mistake, instead of 1.34.1 I used version 1.39.0. It didn't even compile. |12>------ ?????: ??: llui, ??: RelWithDebInfo Win32 ------ 12>????... 12>llalertdialog.cpp 9>llcommon.cpp 9>llbase64.cpp 9>llbase32.cpp 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(370) : error C2589: ?(?: ?::???????? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(370) : error C2059: ???? : ?::? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(390) : error C2589: ?(?: ?::???????? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(390) : error C2059: ???? : ?::? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(395) : error C2589: ?(?: ?::???????? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(395) : error C2059: ???? : ?::? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(400) : error C2589: ?(?: ?::???????? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(400) : error C2059: ???? : ?::? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(405) : error C2589: ?(?: ?::???????? 12>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\complex(405) : error C2059: ???? : ?::?| The third time I got the 1.34.1 boost libs and in there are a couple of files that doesn't read in codepage 936. In addition to the one named in VWR-12427, utilities/enable_if.hpp, lexical_cast.hpp, tokenizer.hpp, the whole numeric/conversion/, a utf8_codecvt_facet.cpp and two utf8_codecvt_facet.hpp has to be converted to UTF-8. Then I built and placed the boost binaries by following instructions from http://wiki.secondlife.com/wiki/User:Jodiah_Jensen. Everything went smoothly afterwards, except... fmod is not needed, but it's in the linker configs. Okay, remove that. Still doesn't work because llmozlib was built with VS2005: 1>------ ?????: ??: secondlife-bin, ??: Debug Win32 ------ 1>Setting the secondlife-bin working directory for debugging. 1>Editing solution: C:/Users/Kakurady/dev/snowglobe/working/linden/indra/build-VC90/SecondLife.sln 1>Looking for existing VisualStudio instance... 1> Didn't find open solution, starting new background VisualStudio instance... 1> Reading .sln file version... 1> Using version: VC90... 1>?????? 1>???: type 1>Quitting do to error opening: C:\Users\Kakurady\dev\snowglobe\working\linden\indra\build-VC90\SecondLife.sln 1>Verifying message template 1>master: http://secondlife.com/app/message_template/master_message_template.msg 1>current: C:\Users\Kakurady\dev\snowglobe\working\linden\scripts\messages\message_template.msg 1>--- PASS --- 1>Older 1> in message DirPopularReply: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message DirPopularQueryBackend: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message ViewerStats: is less deprecated: NotDeprecated vs. UDPDeprecated in base 1> in message ChildAgentUpdate: missing 1 extra blocks 1> in message DirPopularQuery: is less deprecated: NotDeprecated vs. Deprecated in base 1> in message RequestParcelTransfer: missing 1 extra blocks 1> 1>C:\Users\Kakurady\dev\snowglobe\working\linden\indra\lib\python\indra\ipc\llmessage.py:29: DeprecationWarning: the sets module is deprecated 1> from sets import Set, ImmutableSet 1>????... 1> ????? C:\Users\Kakurady\dev\snowglobe\working\linden\indra\build-VC90\newview\Debug\secondlife-bin.lib ??? C:\Users\Kakurady\dev\snowglobe\working\linden\indra\build-VC90\newview\Debug\secondlife-bin.exp 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_ParserFree ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_ErrorString ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_GetCurrentByteCount ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_GetCurrentByteIndex ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_GetCurrentColumnNumber ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_GetCurrentLineNumber ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_GetErrorCode ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_Parse ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_SetUserData ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_SetCharacterDataHandler ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_SetElementHandler ??? _xml_elem_parse_buf ??? 1>xmlrpcepi.lib(xml_element.obj) : warning LNK4217: ??????? _XML_ParserCreate ??? _xml_elem_parse_buf ??? 1>llmozlib2d-vc80.lib(llmozlib2.obj) : error LNK2019: ????????? "__declspec(dllimport) public: __thiscall std::_Container_base::~_Container_base(void)" (__imp_??1_Container_base at std@@QAE at XZ)??????? "public: __thiscall std::_Tmap_traits,class std::allocator >,0>::~_Tmap_traits,class std::allocator >,0>(void)" (??1?$_Tmap_traits at HPAVLLEmbeddedBrowserWindow@@U?$less at H@std@@V?$allocator at U?$pair@$$CBHPAVLLEmbeddedBrowserWindow@@@std@@@3@$0A@@std@@QAE at XZ) ???? 1>llmozlib2d-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2001: ????????? "__declspec(dllimport) public: __thiscall std::_Container_base::~_Container_base(void)" (__imp_??1_Container_base at std@@QAE at XZ) 1>llmozlib2d-vc80.lib(llmozlib2.obj) : error LNK2019: ????????? "__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)" (__imp_??0_Container_base at std@@QAE at XZ)??????? "public: __thiscall std::_Tmap_traits,class std::allocator >,0>::_Tmap_traits,class std::allocator >,0>(struct std::less)" (??0?$_Tmap_traits at HPAVLLEmbeddedBrowserWindow@@U?$less at H@std@@V?$allocator at U?$pair@$$CBHPAVLLEmbeddedBrowserWindow@@@std@@@3@$0A@@std@@QAE at U?$less at H@1@@Z) ???? 1>llmozlib2d-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2001: ????????? "__declspec(dllimport) public: __thiscall std::_Container_base::_Container_base(void)" (__imp_??0_Container_base at std@@QAE at XZ) 1>C:\Users\Kakurady\dev\snowglobe\working\linden\indra\build-VC90\newview\Debug\secondlife-bin.exe : fatal error LNK1120: 2 ?????????? 1>????????file://c:\Users\Kakurady\dev\snowglobe\working\linden\indra\build-VC90\newview\secondlife-bin.dir\Debug\BuildLog.htm? 1>secondlife-bin - 5 ????12 ??? ========== ??: ?? 0 ???? 1 ???? 22 ???? 0 ? ========== I'm no C++ dev, so I'm not sure where to go next. I could build llmozlib from scratch, but I may not succeed and I think it takes really, really long. Kakurady / Geneko Nemeth -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090820/1dd1ac5f/attachment-0001.htm From I_really_needed_a_new_mailbox at gmx.de Thu Aug 20 16:22:49 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Fri, 21 Aug 2009 01:22:49 +0200 Subject: [sldev] [WEB] [VWR] Advanced Menu experts? Message-ID: Hi there! :-) DanielRavenNest Noe is currently spending quite some time on documenting every tiny bit of the current SL viewer. He now reached the "Advanced menu" and is asking for input, since many options in there are just miracles. I figured, that there might be quite some people in here who'd be able to contribute to that page. About a sentence or two per option would be enough to get an idea of what that feature actually does. The more explanation worthy features might get on their own pages (and beeing linked to from there) though it would be great if some of you could jump in and fill out the blanks. The article is located at https://wiki.secondlife.com/wiki/Advanced_menu and the related discussion page is obviously https://wiki.secondlife.com/wiki/Talk:Advanced_menu Thank you very much in advance! --zai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090821/7863b5d7/attachment.htm From merov at lindenlab.com Thu Aug 20 18:04:26 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 20 Aug 2009 18:04:26 -0700 Subject: [sldev] Requesting review: SNOW-200 Message-ID: <78f69850908201804g34dcc6cbu56dd6bf9a7df7766@mail.gmail.com> Hi, This is small (and tested) change to the map code that I'd like to commit into SnowGlobe. No change from a user standpoint, just cleaner code. Please add review of the patch code in the PJIRA. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090820/f605fa0e/attachment.htm From izzee at hotmail.co.uk Fri Aug 21 04:47:36 2009 From: izzee at hotmail.co.uk (izze euler) Date: Fri, 21 Aug 2009 11:47:36 +0000 Subject: [sldev] Renaming secondlife-bin.exe Message-ID: Hi, I am trying to launch my compiled version of the Second Life viewer from a browser by calling secondlife:///app/login. I have changed the registry to open my version, however when the launch application popup opens, it lists the software as secondlife-bin.exe. Is there anyway I can change the text that is displayed? Or do I have to change the .exe file? If I change the secondlife-bin.exe file to mysecondlife.exe for example, will this affect me compiling my viewer? If so, what else do I need to change? Thanks Kind Regards, Izze _________________________________________________________________ Windows Live Messenger: Celebrate 10 amazing years with free winks and emoticons. http://clk.atdmt.com/UKM/go/157562755/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090821/150916b3/attachment.htm From aleric.inglewood at gmail.com Fri Aug 21 06:02:26 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Fri, 21 Aug 2009 15:02:26 +0200 Subject: [sldev] Sharing edit permissions of a script - without the need to transfer ownership first. Please comment Message-ID: <1e01733d0908210602x1ac48b4eqd3372626a8465934@mail.gmail.com> http://jira.secondlife.com/browse/SVC-316 I added a few comments to that jira and would appreciate it if some people could comment. We need to get to a consensus that this IS a bug, and what is the solution, so it can be fixed :) Quote from jira: Since permissions are irrelevant, I'll put comments about permissions between brackets and make them ridiculously permissive , just to make a point. Needed two avatars, A and B, both in a group G (both active). Let A create a prim (set the prim to group G, check "Share with group", "Allow anyone to copy", "Next owner can Modify, Copy and Resell/Give away"). Let A go to contents and create a new script. Edit the properties of the new script and mark "Share with group" (check "Allow anyone to copy", and "Next owner can Modify, Copy and Resell/Give away"). (Let A and B even be partners , heheh) (Let A and B have eachothers Build permissions) Let B come and try to view/edit the script... insufficient permissions... Excuse me? Insufficient permissions? Where? From sllists at boroon.dasgupta.ch Sat Aug 22 04:26:23 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 22 Aug 2009 13:26:23 +0200 Subject: [sldev] supported versions of Python for building, [PATCH] VWR-201 Message-ID: <4A8FD5DF.2090709@boroon.dasgupta.ch> Hi all, after lurking (and sometimes commenting) on SLDev for quite a long time, here come my first "real" patches (don't get too excited, just fixes a non-fatal warning): http://jira.secondlife.com/browse/SNOW-201 "DeprecationWarning: the sets module is deprecated" with Python >= 2.6 Comments and reviews appreciated! Related, I'd like to ask what versions of Python are currently supported for building the viewer on the different platforms (so the respective wiki articles can be clarified/updated), and which versions should be supported in the future. cheers Boroondas From sllists at boroon.dasgupta.ch Sat Aug 22 04:30:03 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 22 Aug 2009 13:30:03 +0200 Subject: [sldev] oops, that should read "SNOW-201" in the subject (was: supported versions of Python for building, [PATCH] VWR-201) In-Reply-To: <4A8FD5DF.2090709@boroon.dasgupta.ch> References: <4A8FD5DF.2090709@boroon.dasgupta.ch> Message-ID: <4A8FD6BB.6070308@boroon.dasgupta.ch> looks like proofreading twice and spell check still isn't enough :-/ From aleric.inglewood at gmail.com Sun Aug 23 04:07:25 2009 From: aleric.inglewood at gmail.com (Aleric Inglewood) Date: Sun, 23 Aug 2009 13:07:25 +0200 Subject: [sldev] Sharing edit permissions of a script - without the need to transfer ownership first. Please comment In-Reply-To: <1e01733d0908210602x1ac48b4eqd3372626a8465934@mail.gmail.com> References: <1e01733d0908210602x1ac48b4eqd3372626a8465934@mail.gmail.com> Message-ID: <1e01733d0908230407j63496b55o2568de7631815935@mail.gmail.com> Well, at least all this led to an update of the page https://wiki.secondlife.com/wiki/Editing_someone_else%27s_scripts_and_notecards Remaining questions: * Isn't it a bug that the requirement to first set the group and then set 'share with group' and not the other way around, exists? * Shouldn't a script be also editable if it has 'Allow anyone to copy" set (as opposed to 'share with with group'?) * Shouldn't one be able to edit scripts of someone else if one has that someone else's build permissions and the script has Next Owner can 'Modify / Copy (/ Transfer, whatever)' set (indicating the intent of being full perm / open source). On Fri, Aug 21, 2009 at 3:02 PM, Aleric Inglewood wrote: > http://jira.secondlife.com/browse/SVC-316 From fire at b3dMultitech.com Mon Aug 24 12:12:41 2009 From: fire at b3dMultitech.com (Fire) Date: Mon, 24 Aug 2009 12:12:41 -0700 Subject: [sldev] noob question: is llTextBox in the Snowglobe SVN? In-Reply-To: <4A48CD25.50907@watson.ibm.com> References: <1dabc2a30906260311u5f3cf4d5hd6d525b39b6defea@mail.gmail.com> <4A48CD25.50907@watson.ibm.com> Message-ID: <1dabc2a30908241212y65ea87b8w693e548f1c3553aa@mail.gmail.com> Hi there Mike, just wondering if you managed to get any further on this? Anxiously waiting! Thanks - keep up the good work! On Mon, Jun 29, 2009 at 7:18 AM, Mike Monkowski wrote: > I've convinced Admiral Admiral to work with me on > https://jira.secondlife.com/browse/VWR-10924 which will give you much more > than text boxes. We should have something by the end of the summer. > > Mike > SL: Mm Alder > > > > Fire wrote: > >> Hi there, >> >> just a question - I quite excited about llTextBox... as it would greatly >> enhance our lovely llDialog! >> >> Is llTextBox functionality in the opensource Snowglobe client, or are >> their any active devs in the sldev community working on this? >> How big an effort would be needed for this implementation? If you have any >> idea about this, please share. >> >> Thanks! >> >> *Paul Preibisch* >> Research Assistant, Sloodle.org >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090824/5a782b35/attachment.htm From monkowsk at watson.ibm.com Mon Aug 24 14:30:29 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 24 Aug 2009 17:30:29 -0400 Subject: [sldev] noob question: is llTextBox in the Snowglobe SVN? In-Reply-To: <1dabc2a30908241212y65ea87b8w693e548f1c3553aa@mail.gmail.com> References: <1dabc2a30906260311u5f3cf4d5hd6d525b39b6defea@mail.gmail.com> <4A48CD25.50907@watson.ibm.com> <1dabc2a30908241212y65ea87b8w693e548f1c3553aa@mail.gmail.com> Message-ID: <4A930675.4040403@watson.ibm.com> Yes, we (actually my son, Admiral Admiral) got quite far on this. At this point it's more of a toolkit than an end solution, because it needs some input from the community on implementation details. We'll post a patch file very soon that provides: --Tracing all GUI operations to the log file --Tracing all GUI operations to a floater --Load and trace a floater from an XML file and send the trace over chat --Load and trace a floater from a notecard and send the trace over chat --There is already a patch out there to fix "Load from XML" (VWR-14475) --The "Save to XML" function will write the correct XML tags More details soon. Mike Fire wrote: > Hi there Mike, just wondering if you managed to get any further on this? > > Anxiously waiting! Thanks - keep up the good work! > > On Mon, Jun 29, 2009 at 7:18 AM, Mike Monkowski > wrote: > > I've convinced Admiral Admiral to work with me on > https://jira.secondlife.com/browse/VWR-10924 which will give you > much more than text boxes. We should have something by the end of > the summer. > > Mike > SL: Mm Alder > > > > Fire wrote: > > Hi there, > > just a question - I quite excited about llTextBox... as it > would greatly enhance our lovely llDialog! > > Is llTextBox functionality in the opensource Snowglobe client, > or are their any active devs in the sldev community working on this? > How big an effort would be needed for this implementation? If > you have any idea about this, please share. > > Thanks! > > *Paul Preibisch* > Research Assistant, Sloodle.org > > From vector at leafpile.com Tue Aug 25 11:06:35 2009 From: vector at leafpile.com (Vector Hastings) Date: Tue, 25 Aug 2009 11:06:35 -0700 Subject: [sldev] Anybody succeeded at a 64 bit Vista client? In-Reply-To: <4A930675.4040403@watson.ibm.com> References: <1dabc2a30906260311u5f3cf4d5hd6d525b39b6defea@mail.gmail.com> <4A48CD25.50907@watson.ibm.com> <1dabc2a30908241212y65ea87b8w693e548f1c3553aa@mail.gmail.com> <4A930675.4040403@watson.ibm.com> Message-ID: <007601ca25ae$ca9b19e0$5fd14da0$@com> Has anyone managed to compile a 64 bit Vista client? If so, are you willing to pass on any insights as to how to get it done? All the best, Vector From robla at lindenlab.com Thu Aug 27 15:38:48 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 27 Aug 2009 15:38:48 -0700 Subject: [sldev] SNOW-93 translation patch Message-ID: Hi folks, As you may have saw, we posted a proposal on rentacoder.com asking for an implementation of automatic translation of public chat. We worked with a developer on the result, and posted it here: https://jira.secondlife.com/browse/SNOW-93 The code is in pretty good shape, but needs some minor cleanup work, which is detailed in SNOW-93. Anyone care to carry this work over the goal line? We'd love to see this make it into Snowglobe 1.2. Rob p.s. I'm hoping the developer who worked on it steps forward to discuss this more, but I'll refrain from discussing further for privacy reasons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090827/2bc1a3e9/attachment.htm From monkowsk at watson.ibm.com Thu Aug 27 08:21:33 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 27 Aug 2009 11:21:33 -0400 Subject: [sldev] Open Source Meeting Message-ID: <4A96A47D.80602@watson.ibm.com> I've added these to today's agenda. # At SLCC there was a "Sneak Peek" at viewer 2.0. Could we get more details such as whether it will be an alternate viewer, alternate skin, or the only supported viewer. How has the GUI code changed? Additions, refactoring, complete rewrite? Is 2.0 just about appearance or will it have other new things? Mm Alder 15:05, 27 August 2009 (UTC) # Anything else from SLCC that might be of interest to the Open Source community. Mm Alder 15:05, 27 August 2009 (UTC) Mike From merov at lindenlab.com Thu Aug 27 19:01:23 2009 From: merov at lindenlab.com (Philippe (Merov) Bossut) Date: Thu, 27 Aug 2009 19:01:23 -0700 Subject: [sldev] plugin-api changes Message-ID: <78f69850908271901r352de74dm39f3d323693ace42@mail.gmail.com> Hi, I'm bringing some improvements from internal branches to the plugin-api branch (not SnowGlobe). It's a little bit rocky right now but the Linux build is now re-enabled with a gstreamer plug-in for your enjoyment. I've apparently though broken some fmod stuff on the Windows version in the process so this is really "for dev only" for the moment. Once I succeed stabilizing that branch, I'll proceed with a SnowGlobe integration. ETA sometime next week I think. Cheers, - Merov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090827/530d8f14/attachment.htm From cypren at gmail.com Thu Aug 27 20:03:21 2009 From: cypren at gmail.com (Cypren Christenson) Date: Thu, 27 Aug 2009 20:03:21 -0700 Subject: [sldev] SNOW-93 translation patch In-Reply-To: References: Message-ID: <7810dc520908272003t289440c8r9cf90f4ac6308364@mail.gmail.com> I've taken a look at the patch and feel comfortable picking up this project. I won't be able to work on it until after this weekend, however, so if someone wants to address it faster than that, they're welcome to do so. On Thu, Aug 27, 2009 at 3:38 PM, Rob Lanphier wrote: > Hi folks, > > As you may have saw, we posted a proposal on rentacoder.com asking for an > implementation of automatic translation of public chat.? We worked with a > developer on the result, and posted it here: > https://jira.secondlife.com/browse/SNOW-93 > > The code is in pretty good shape, but needs some minor cleanup work, which > is detailed in SNOW-93.? Anyone care to carry this work over the goal line? > We'd love to see this make it into Snowglobe 1.2. > > Rob > p.s. I'm hoping the developer who worked on it steps forward to discuss this > more, but I'll refrain from discussing further for privacy reasons > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From carlo at alinoe.com Fri Aug 28 03:48:09 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 28 Aug 2009 12:48:09 +0200 Subject: [sldev] SNOW-93 translation patch In-Reply-To: References: Message-ID: <20090828104809.GA17581@alinoe.com> On Thu, Aug 27, 2009 at 03:38:48PM -0700, Rob Lanphier wrote: > As you may have saw, we posted a proposal on rentacoder.com asking for an > implementation of automatic translation of public chat. Was that fact posted here when you posted it to rentacoder.com? I can't remember to have seen it on this list. -- Carlo Wood From carlo at alinoe.com Fri Aug 28 03:51:54 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 28 Aug 2009 12:51:54 +0200 Subject: [sldev] plugin-api changes In-Reply-To: <78f69850908271901r352de74dm39f3d323693ace42@mail.gmail.com> References: <78f69850908271901r352de74dm39f3d323693ace42@mail.gmail.com> Message-ID: <20090828105154.GB17581@alinoe.com> On Thu, Aug 27, 2009 at 07:01:23PM -0700, Philippe (Merov) Bossut wrote: > I'm bringing some improvements from internal branches to the plugin-api branch > (not SnowGlobe). It's a little bit rocky right now but the Linux build is now > re-enabled with a gstreamer plug-in for your enjoyment. I've apparently though > broken some fmod stuff on the Windows version in the process so this is really > "for dev only" for the moment. Seems "don't fix what isn't broken" applies here. Usually 'improvements' mean improvements, not 'rocky' and 'breaking things'. Do we get to review this patch before you (are allowed to) commit this to snowglobe? What are the improvements? -- Carlo Wood From billwindwalker at rocketmail.com Fri Aug 28 04:58:28 2009 From: billwindwalker at rocketmail.com (Bill Windwalker) Date: Fri, 28 Aug 2009 04:58:28 -0700 (PDT) Subject: [sldev] SNOWGLOBE In-Reply-To: References: Message-ID: <656171.61496.qm@web111215.mail.gq1.yahoo.com> Need to know befor filing a jira. Hi i think i have found a bug in the Map that i have been seeing a large number of islands thats not there on the SL client. but i can not find a jira about this bug if there is one . any one remember seeing this happen or a jira on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090828/c58da26b/attachment.htm From latifer at streamgrid.net Fri Aug 28 07:11:03 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Fri, 28 Aug 2009 16:11:03 +0200 Subject: [sldev] plugin-api changes In-Reply-To: <78f69850908271901r352de74dm39f3d323693ace42@mail.gmail.com> References: <78f69850908271901r352de74dm39f3d323693ace42@mail.gmail.com> Message-ID: <5ebce2ec0908280711s144cfe43haca0f6c6beb3a12c@mail.gmail.com> On Fri, Aug 28, 2009 at 4:01 AM, Philippe (Merov) Bossut wrote: > Hi, > > I'm bringing some improvements from internal branches to the plugin-api > branch (not SnowGlobe). It's a little bit rocky right now but the Linux > build is now re-enabled with a gstreamer plug-in for your enjoyment. I've > apparently though broken some fmod stuff on the Windows version in the > process so this is really "for dev only" for the moment. > > Once I succeed stabilizing that branch, I'll proceed with a SnowGlobe > integration. ETA sometime next week I think. Wow, getting plugins api to Snowglobe branch would be awesome, great work! Cannot wait to see it merged :) -- L From robla at lindenlab.com Fri Aug 28 08:28:30 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 28 Aug 2009 08:28:30 -0700 Subject: [sldev] SNOW-93 translation patch In-Reply-To: <20090828104809.GA17581@alinoe.com> References: <20090828104809.GA17581@alinoe.com> Message-ID: On Fri, Aug 28, 2009 at 3:48 AM, Carlo Wood wrote: > On Thu, Aug 27, 2009 at 03:38:48PM -0700, Rob Lanphier wrote: > > As you may have saw, we posted a proposal on rentacoder.com asking for > an > > implementation of automatic translation of public chat. > > Was that fact posted here when you posted it to rentacoder.com? > > I can't remember to have seen it on this list. Nope, sorry about that. We plan to make sure that future work is posted here. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090828/0ea17e2d/attachment.htm From robla at lindenlab.com Fri Aug 28 10:55:23 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 28 Aug 2009 10:55:23 -0700 Subject: [sldev] New format for Snowglobe usage/crash stats Message-ID: Hi folks, Below is a new format I'm playing with for Snowglobe usage/crash stats.? This only catches versions that have at least 10 users and have at least 20 hours of total use in a day. Thoughts?? Note that this doesn't preclude getting this out there in a graph/whatever, but I'd like to get useful raw data flowing first, and then we can figure out the right way to doll it up.? So, suggestions welcome for a different text format, but lets hold off on graph suggestions. Thanks Rob 2009-08-26: Snowglobe Release 1.1.2.2584: 10.84 crashes/100 hr, 1474 crashes, 8998.90 hours, 6302 sessions, 3095 agents Snowglobe Release 1.0.2.2451: 11.79 crashes/100 hr, 235 crashes, 1358.80 hours, 913 sessions, 468 agents Snowglobe Release 1.0.3.2537: 9.48 crashes/100 hr, 81 crashes, 591.20 hours, 385 sessions, 201 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 125.00 hours, 60 sessions, 37 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 57.00 hours, 47 sessions, 25 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 48.40 hours, 25 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 22.20 hours, 28 sessions, 14 agents 2009-08-25: Snowglobe Release 1.1.2.2584: 9.91 crashes/100 hr, 1382 crashes, 9210.10 hours, 6425 sessions, 3118 agents Snowglobe Release 1.0.2.2451: 12.35 crashes/100 hr, 252 crashes, 1314.80 hours, 918 sessions, 458 agents Snowglobe Release 1.0.3.2537: 6.73 crashes/100 hr, 62 crashes, 612.80 hours, 395 sessions, 202 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 166.70 hours, 83 sessions, 45 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 66.20 hours, 37 sessions, 18 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 59.80 hours, 21 sessions, 13 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 45.80 hours, 42 sessions, 21 agents 2009-08-24: Snowglobe Release 1.1.2.2584: 10.22 crashes/100 hr, 1395 crashes, 9062.40 hours, 6199 sessions, 3077 agents Snowglobe Release 1.0.2.2451: 10.47 crashes/100 hr, 223 crashes, 1464.60 hours, 930 sessions, 495 agents Snowglobe Release 1.0.3.2537: 9.02 crashes/100 hr, 81 crashes, 591.20 hours, 371 sessions, 208 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 179.00 hours, 58 sessions, 36 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 90.30 hours, 40 sessions, 20 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 44.30 hours, 28 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 41.40 hours, 39 sessions, 18 agents 2009-08-23: Snowglobe Release 1.1.2.2584: 9.25 crashes/100 hr, 1377 crashes, 9986.80 hours, 6514 sessions, 3065 agents Snowglobe Release 1.0.2.2451: 10.32 crashes/100 hr, 230 crashes, 1533.00 hours, 955 sessions, 494 agents Snowglobe Release 1.0.3.2537: 8.96 crashes/100 hr, 89 crashes, 714.90 hours, 487 sessions, 241 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 154.00 hours, 67 sessions, 41 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 74.90 hours, 23 sessions, 11 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 66.20 hours, 39 sessions, 18 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 45.00 hours, 42 sessions, 16 agents 2009-08-22: Snowglobe Release 1.1.2.2584: 9.27 crashes/100 hr, 1458 crashes, 10616.00 hours, 6580 sessions, 3093 agents Snowglobe Release 1.0.2.2451: 11.58 crashes/100 hr, 254 crashes, 1430.40 hours, 967 sessions, 467 agents Snowglobe Release 1.0.3.2537: 11.32 crashes/100 hr, 146 crashes, 822.90 hours, 477 sessions, 250 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 170.40 hours, 97 sessions, 44 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 72.30 hours, 41 sessions, 18 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 62.80 hours, 22 sessions, 11 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 32.90 hours, 35 sessions, 13 agents 2009-08-21: Snowglobe Release 1.1.2.2584: 10.48 crashes/100 hr, 1452 crashes, 9417.40 hours, 6235 sessions, 3001 agents Snowglobe Release 1.0.2.2451: 9.75 crashes/100 hr, 239 crashes, 1526.00 hours, 956 sessions, 506 agents Snowglobe Release 1.0.3.2537: 8.51 crashes/100 hr, 105 crashes, 742.60 hours, 524 sessions, 271 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 127.80 hours, 68 sessions, 35 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 98.10 hours, 43 sessions, 21 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 39.80 hours, 18 sessions, 11 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 27.00 hours, 39 sessions, 12 agents 2009-08-20: Snowglobe Release 1.1.2.2584: 9.97 crashes/100 hr, 1356 crashes, 9199.90 hours, 6163 sessions, 3005 agents Snowglobe Release 1.0.2.2451: 9.27 crashes/100 hr, 216 crashes, 1514.60 hours, 1001 sessions, 502 agents Snowglobe Release 1.0.3.2537: 9.37 crashes/100 hr, 103 crashes, 741.50 hours, 541 sessions, 292 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 93.90 hours, 64 sessions, 23 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 87.60 hours, 67 sessions, 37 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 22.70 hours, 33 sessions, 11 agents 2009-08-19: Snowglobe Release 1.1.2.2584: 10.60 crashes/100 hr, 1443 crashes, 9222.00 hours, 6076 sessions, 2904 agents Snowglobe Release 1.0.2.2451: 11.25 crashes/100 hr, 265 crashes, 1652.30 hours, 1083 sessions, 520 agents Snowglobe Release 1.0.3.2537: 7.68 crashes/100 hr, 85 crashes, 767.10 hours, 560 sessions, 289 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 99.70 hours, 58 sessions, 36 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 66.80 hours, 42 sessions, 18 agents Snowglobe Release 1.1.2.2607: 0.00 crashes/100 hr, 0 crashes, 56.20 hours, 25 sessions, 12 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 45.10 hours, 35 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 35.20 hours, 36 sessions, 13 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 20.30 hours, 31 sessions, 12 agents 2009-08-18: Snowglobe Release 1.1.2.2584: 9.71 crashes/100 hr, 1355 crashes, 9294.40 hours, 6095 sessions, 2975 agents Snowglobe Release 1.0.2.2451: 11.63 crashes/100 hr, 277 crashes, 1538.20 hours, 1108 sessions, 558 agents Snowglobe Release 1.0.3.2537: 10.44 crashes/100 hr, 120 crashes, 785.30 hours, 538 sessions, 286 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 94.00 hours, 76 sessions, 43 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 48.40 hours, 24 sessions, 16 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 45.00 hours, 30 sessions, 14 agents Snowglobe Test Build 1.2.0.2604: 0.00 crashes/100 hr, 0 crashes, 42.00 hours, 33 sessions, 20 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 29.80 hours, 38 sessions, 14 agents 2009-08-17: Snowglobe Release 1.1.2.2584: 10.00 crashes/100 hr, 1387 crashes, 9257.90 hours, 6154 sessions, 3017 agents Snowglobe Release 1.0.2.2451: 10.08 crashes/100 hr, 247 crashes, 1577.80 hours, 1116 sessions, 556 agents Snowglobe Release 1.0.3.2537: 9.44 crashes/100 hr, 127 crashes, 965.30 hours, 591 sessions, 299 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 109.30 hours, 78 sessions, 45 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 62.40 hours, 27 sessions, 12 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 49.20 hours, 32 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 32.40 hours, 34 sessions, 16 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 25.40 hours, 38 sessions, 12 agents 2009-08-16: Snowglobe Release 1.1.2.2584: 10.08 crashes/100 hr, 1455 crashes, 9674.70 hours, 6316 sessions, 2949 agents Snowglobe Release 1.0.2.2451: 10.64 crashes/100 hr, 283 crashes, 1794.30 hours, 1222 sessions, 614 agents Snowglobe Release 1.0.3.2537: 8.68 crashes/100 hr, 121 crashes, 980.50 hours, 660 sessions, 329 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 137.90 hours, 81 sessions, 40 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 70.80 hours, 28 sessions, 15 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 35.60 hours, 22 sessions, 13 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 22.30 hours, 21 sessions, 13 agents 2009-08-15: Snowglobe Release 1.1.2.2584: 9.21 crashes/100 hr, 1390 crashes, 10247.10 hours, 6082 sessions, 2811 agents Snowglobe Release 1.0.2.2451: 10.78 crashes/100 hr, 292 crashes, 1799.50 hours, 1243 sessions, 598 agents Snowglobe Release 1.0.3.2537: 6.57 crashes/100 hr, 105 crashes, 1129.70 hours, 678 sessions, 350 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 134.20 hours, 89 sessions, 40 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 35.70 hours, 32 sessions, 17 agents 2009-08-14: Snowglobe Release 1.1.2.2584: 10.04 crashes/100 hr, 1430 crashes, 9438.60 hours, 6047 sessions, 2807 agents Snowglobe Release 1.0.2.2451: 11.17 crashes/100 hr, 333 crashes, 1905.20 hours, 1258 sessions, 656 agents Snowglobe Release 1.0.3.2537: 8.95 crashes/100 hr, 155 crashes, 1086.60 hours, 698 sessions, 347 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 136.30 hours, 90 sessions, 42 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 45.80 hours, 30 sessions, 13 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 39.60 hours, 23 sessions, 13 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 23.60 hours, 17 sessions, 12 agents 2009-08-13: Snowglobe Release 1.1.2.2584: 9.67 crashes/100 hr, 1341 crashes, 9090.10 hours, 5909 sessions, 2811 agents Snowglobe Release 1.0.2.2451: 11.65 crashes/100 hr, 339 crashes, 1863.70 hours, 1293 sessions, 621 agents Snowglobe Release 1.0.3.2537: 9.36 crashes/100 hr, 135 crashes, 958.20 hours, 697 sessions, 355 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 185.20 hours, 91 sessions, 47 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 60.40 hours, 24 sessions, 11 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 34.00 hours, 35 sessions, 11 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 30.60 hours, 32 sessions, 19 agents Snowglobe Test Build 1.1.0.2598: 0.00 crashes/100 hr, 0 crashes, 28.70 hours, 27 sessions, 12 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 24.20 hours, 26 sessions, 12 agents 2009-08-12: Snowglobe Release 1.1.2.2584: 10.82 crashes/100 hr, 1507 crashes, 8914.40 hours, 5978 sessions, 2834 agents Snowglobe Release 1.0.2.2451: 11.50 crashes/100 hr, 363 crashes, 1950.80 hours, 1306 sessions, 659 agents Snowglobe Release 1.0.3.2537: 10.65 crashes/100 hr, 165 crashes, 1079.30 hours, 731 sessions, 403 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 137.70 hours, 89 sessions, 45 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 53.50 hours, 38 sessions, 13 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 43.40 hours, 26 sessions, 12 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 42.10 hours, 28 sessions, 17 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 24.00 hours, 25 sessions, 14 agents 2009-08-11: Snowglobe Release 1.1.2.2584: 9.41 crashes/100 hr, 1262 crashes, 9050.10 hours, 5885 sessions, 2778 agents Snowglobe Release 1.0.2.2451: 11.18 crashes/100 hr, 354 crashes, 1960.00 hours, 1377 sessions, 702 agents Snowglobe Release 1.0.3.2537: 8.29 crashes/100 hr, 164 crashes, 1334.40 hours, 815 sessions, 437 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 153.10 hours, 91 sessions, 50 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 42.40 hours, 29 sessions, 14 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 41.70 hours, 31 sessions, 16 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 39.80 hours, 26 sessions, 12 agents 2009-08-10: Snowglobe Release 1.1.2.2584: 10.42 crashes/100 hr, 1386 crashes, 8895.20 hours, 5911 sessions, 2790 agents Snowglobe Release 1.0.2.2451: 10.26 crashes/100 hr, 356 crashes, 2217.80 hours, 1474 sessions, 722 agents Snowglobe Release 1.0.3.2537: 10.43 crashes/100 hr, 192 crashes, 1206.20 hours, 880 sessions, 480 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 145.80 hours, 112 sessions, 52 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 75.20 hours, 31 sessions, 16 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 54.80 hours, 36 sessions, 17 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 40.90 hours, 25 sessions, 13 agents 2009-08-09: Snowglobe Release 1.1.2.2584: 9.60 crashes/100 hr, 1348 crashes, 9290.10 hours, 6035 sessions, 2801 agents Snowglobe Release 1.0.2.2451: 12.96 crashes/100 hr, 514 crashes, 2315.20 hours, 1574 sessions, 768 agents Snowglobe Release 1.0.3.2537: 8.47 crashes/100 hr, 200 crashes, 1625.00 hours, 1056 sessions, 534 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 156.40 hours, 95 sessions, 43 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 52.00 hours, 29 sessions, 14 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 51.40 hours, 39 sessions, 19 agents 2009-08-08: Snowglobe Release 1.1.2.2584: 9.63 crashes/100 hr, 1353 crashes, 9213.70 hours, 5700 sessions, 2565 agents Snowglobe Release 1.0.2.2451: 9.78 crashes/100 hr, 386 crashes, 2564.80 hours, 1662 sessions, 808 agents Snowglobe Release 1.0.3.2537: 7.42 crashes/100 hr, 198 crashes, 1850.80 hours, 1129 sessions, 569 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 200.10 hours, 85 sessions, 50 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 82.90 hours, 49 sessions, 20 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 78.50 hours, 38 sessions, 14 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 61.60 hours, 28 sessions, 13 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 34.60 hours, 36 sessions, 14 agents 2009-08-07: Snowglobe Release 1.1.2.2584: 9.07 crashes/100 hr, 1187 crashes, 8740.20 hours, 5520 sessions, 2552 agents Snowglobe Release 1.0.2.2451: 9.09 crashes/100 hr, 363 crashes, 2603.80 hours, 1815 sessions, 904 agents Snowglobe Release 1.0.3.2537: 11.23 crashes/100 hr, 314 crashes, 1878.70 hours, 1260 sessions, 660 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 159.80 hours, 74 sessions, 42 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 77.10 hours, 30 sessions, 14 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 68.10 hours, 45 sessions, 23 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 65.00 hours, 29 sessions, 16 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 49.60 hours, 33 sessions, 15 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 34.30 hours, 33 sessions, 16 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 33.40 hours, 31 sessions, 16 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 26.20 hours, 25 sessions, 12 agents 2009-08-06: Snowglobe Release 1.1.2.2584: 10.66 crashes/100 hr, 1188 crashes, 7064.80 hours, 4846 sessions, 2334 agents Snowglobe Release 1.0.2.2451: 9.74 crashes/100 hr, 405 crashes, 2774.80 hours, 1771 sessions, 891 agents Snowglobe Release 1.0.3.2537: 12.03 crashes/100 hr, 397 crashes, 2159.40 hours, 1507 sessions, 800 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 133.70 hours, 82 sessions, 50 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 67.20 hours, 45 sessions, 19 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 48.60 hours, 33 sessions, 17 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 46.50 hours, 30 sessions, 14 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 34.10 hours, 27 sessions, 14 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 30.50 hours, 25 sessions, 12 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 26.00 hours, 39 sessions, 16 agents 2009-08-05: Snowglobe Release 1.1.2.2584: 9.37 crashes/100 hr, 815 crashes, 5831.00 hours, 4051 sessions, 1942 agents Snowglobe Release 1.0.2.2451: 9.14 crashes/100 hr, 444 crashes, 3297.60 hours, 1987 sessions, 992 agents Snowglobe Release 1.0.3.2537: 9.25 crashes/100 hr, 423 crashes, 3104.60 hours, 1992 sessions, 1091 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 143.60 hours, 99 sessions, 51 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 82.90 hours, 39 sessions, 17 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 77.10 hours, 39 sessions, 21 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 58.90 hours, 35 sessions, 18 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 53.60 hours, 48 sessions, 21 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 25.60 hours, 20 sessions, 12 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 25.20 hours, 18 sessions, 13 agents 2009-08-04: Snowglobe Release 1.1.2.2584: 8.45 crashes/100 hr, 621 crashes, 5051.00 hours, 3368 sessions, 1580 agents Snowglobe Release 1.0.3.2537: 9.33 crashes/100 hr, 568 crashes, 3967.90 hours, 2606 sessions, 1392 agents Snowglobe Release 1.0.2.2451: 10.50 crashes/100 hr, 545 crashes, 3526.60 hours, 2203 sessions, 1089 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 174.80 hours, 98 sessions, 62 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 98.10 hours, 23 sessions, 18 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 54.00 hours, 40 sessions, 23 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 49.60 hours, 38 sessions, 21 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 44.60 hours, 28 sessions, 13 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 37.60 hours, 39 sessions, 19 agents 2009-08-03: Snowglobe Release 1.0.3.2537: 10.93 crashes/100 hr, 2144 crashes, 6379.90 hours, 4471 sessions, 2244 agents Snowglobe Release 1.0.2.2451: 11.81 crashes/100 hr, 1108 crashes, 3056.00 hours, 2195 sessions, 1113 agents Snowglobe Release 1.1.2.2584: 8.81 crashes/100 hr, 228 crashes, 883.90 hours, 810 sessions, 512 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 191.40 hours, 118 sessions, 55 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 76.70 hours, 44 sessions, 25 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 75.30 hours, 45 sessions, 25 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 48.00 hours, 33 sessions, 20 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 41.00 hours, 35 sessions, 17 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 27.90 hours, 30 sessions, 11 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 27.20 hours, 37 sessions, 13 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 25.60 hours, 26 sessions, 13 agents 2009-08-02: Snowglobe Release 1.0.3.2537: 10.04 crashes/100 hr, 2638 crashes, 8633.30 hours, 5336 sessions, 2480 agents Snowglobe Release 1.0.2.2451: 9.86 crashes/100 hr, 1204 crashes, 3843.60 hours, 2391 sessions, 1152 agents Snowglobe Release 1.1.2.2584: 5.35 crashes/100 hr, 48 crashes, 280.80 hours, 212 sessions, 102 agents Snowglobe Test Build 1.1.0.2565: 3.61 crashes/100 hr, 24 crashes, 245.70 hours, 150 sessions, 71 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 81.60 hours, 71 sessions, 30 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 77.50 hours, 80 sessions, 37 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 68.70 hours, 44 sessions, 20 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 62.90 hours, 55 sessions, 26 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 58.90 hours, 53 sessions, 23 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 36.00 hours, 35 sessions, 13 agents 2009-08-01: Snowglobe Release 1.0.3.2537: 10.11 crashes/100 hr, 1386 crashes, 8658.00 hours, 5179 sessions, 2394 agents Snowglobe Release 1.0.2.2451: 10.63 crashes/100 hr, 677 crashes, 4066.80 hours, 2568 sessions, 1270 agents Snowglobe Test Build 1.1.0.2565: 0.00 crashes/100 hr, 0 crashes, 345.10 hours, 178 sessions, 83 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 138.90 hours, 122 sessions, 54 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 122.60 hours, 84 sessions, 35 agents Snowglobe Release 1.1.2.2584: 0.00 crashes/100 hr, 0 crashes, 111.50 hours, 80 sessions, 51 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 87.70 hours, 61 sessions, 23 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 59.70 hours, 43 sessions, 16 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 34.20 hours, 27 sessions, 15 agents Snowglobe Test Build 1.1.0.2573: 0.00 crashes/100 hr, 0 crashes, 30.00 hours, 22 sessions, 11 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 24.90 hours, 32 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 20.30 hours, 34 sessions, 14 agents 2009-07-31: Snowglobe Release 1.0.3.2537: 9.86 crashes/100 hr, 1264 crashes, 8240.60 hours, 5000 sessions, 2371 agents Snowglobe Release 1.0.2.2451: 10.08 crashes/100 hr, 629 crashes, 3951.10 hours, 2525 sessions, 1239 agents Snowglobe Test Build 1.1.0.2565: 2.79 crashes/100 hr, 14 crashes, 357.40 hours, 200 sessions, 101 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 223.80 hours, 165 sessions, 71 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 99.50 hours, 34 sessions, 19 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 90.00 hours, 49 sessions, 24 agents Snowglobe Test Build 1.1.1.2579: 0.00 crashes/100 hr, 0 crashes, 68.10 hours, 69 sessions, 42 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 58.30 hours, 39 sessions, 19 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 52.30 hours, 23 sessions, 14 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 47.00 hours, 35 sessions, 15 agents Snowglobe Test Build 1.1.0.2573: 0.00 crashes/100 hr, 0 crashes, 31.50 hours, 30 sessions, 13 agents 2009-07-30: Snowglobe Release 1.0.3.2537: 10.01 crashes/100 hr, 1213 crashes, 7399.20 hours, 4688 sessions, 2242 agents Snowglobe Release 1.0.2.2451: 11.00 crashes/100 hr, 717 crashes, 4128.60 hours, 2737 sessions, 1314 agents Snowglobe Test Build 1.1.0.2565: 2.46 crashes/100 hr, 15 crashes, 450.70 hours, 275 sessions, 134 agents Snowglobe Test Build 1.1.0.2573: 0.00 crashes/100 hr, 0 crashes, 109.40 hours, 85 sessions, 42 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 89.00 hours, 54 sessions, 25 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 73.30 hours, 48 sessions, 13 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 54.80 hours, 46 sessions, 19 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 49.60 hours, 40 sessions, 19 agents Snowglobe Test Build 1.1.0.2575: 0.00 crashes/100 hr, 0 crashes, 48.00 hours, 51 sessions, 34 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 44.80 hours, 27 sessions, 14 agents Snowglobe Test Build 1.1.0.2554: 0.00 crashes/100 hr, 0 crashes, 24.20 hours, 20 sessions, 11 agents 2009-07-29: Snowglobe Release 1.0.3.2537: 10.60 crashes/100 hr, 1227 crashes, 6863.80 hours, 4675 sessions, 2242 agents Snowglobe Release 1.0.2.2451: 11.32 crashes/100 hr, 752 crashes, 3982.40 hours, 2905 sessions, 1431 agents Snowglobe Test Build 1.1.0.2565: 5.96 crashes/100 hr, 50 crashes, 515.10 hours, 317 sessions, 142 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 101.00 hours, 82 sessions, 41 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 88.00 hours, 88 sessions, 24 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 56.30 hours, 53 sessions, 22 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 53.20 hours, 37 sessions, 19 agents Snowglobe Test Build 1.1.0.2554: 0.00 crashes/100 hr, 0 crashes, 39.30 hours, 15 sessions, 12 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 24.60 hours, 33 sessions, 16 agents 2009-07-28: Snowglobe Release 1.0.3.2537: 10.27 crashes/100 hr, 1130 crashes, 7091.70 hours, 4631 sessions, 2217 agents Snowglobe Release 1.0.2.2451: 10.73 crashes/100 hr, 745 crashes, 4333.40 hours, 3008 sessions, 1534 agents Snowglobe Test Build 1.1.0.2565: 4.09 crashes/100 hr, 24 crashes, 388.20 hours, 322 sessions, 158 agents Snowglobe Test Build 1.1.0.2558: 0.00 crashes/100 hr, 0 crashes, 137.00 hours, 94 sessions, 46 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 98.70 hours, 57 sessions, 30 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 70.90 hours, 82 sessions, 26 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 38.60 hours, 31 sessions, 19 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 28.90 hours, 38 sessions, 24 agents Snowglobe Test Build 1.1.0.2554: 0.00 crashes/100 hr, 0 crashes, 21.30 hours, 20 sessions, 11 agents 2009-07-27: Snowglobe Release 1.0.3.2537: 9.64 crashes/100 hr, 1010 crashes, 6708.50 hours, 4310 sessions, 2139 agents Snowglobe Release 1.0.2.2451: 10.46 crashes/100 hr, 771 crashes, 4923.70 hours, 3228 sessions, 1598 agents Snowglobe Test Build 1.1.0.2565: 2.56 crashes/100 hr, 15 crashes, 486.70 hours, 301 sessions, 145 agents Snowglobe Test Build 1.1.0.2558: 5.48 crashes/100 hr, 16 crashes, 206.50 hours, 120 sessions, 73 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 79.50 hours, 52 sessions, 24 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 46.40 hours, 42 sessions, 19 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 44.70 hours, 45 sessions, 20 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 37.00 hours, 33 sessions, 18 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 27.40 hours, 34 sessions, 11 agents Snowglobe Test Build 1.1.0.2554: 0.00 crashes/100 hr, 0 crashes, 20.10 hours, 21 sessions, 11 agents 2009-07-21: Snowglobe Release 1.0.2.2451: 11.12 crashes/100 hr, 1924 crashes, 10886.50 hours, 7102 sessions, 3476 agents Snowglobe Release 1.0.3.2537: 0.00 crashes/100 hr, 0 crashes, 147.30 hours, 123 sessions, 71 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 101.50 hours, 66 sessions, 34 agents Snowglobe Test Build 1.1.0.2511: 0.00 crashes/100 hr, 0 crashes, 95.00 hours, 73 sessions, 38 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 88.60 hours, 41 sessions, 24 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 60.10 hours, 63 sessions, 31 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 57.10 hours, 42 sessions, 19 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 39.60 hours, 29 sessions, 16 agents Snowglobe Test Build 1.1.0.2523: 0.00 crashes/100 hr, 0 crashes, 35.20 hours, 49 sessions, 20 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 34.60 hours, 22 sessions, 11 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 23.70 hours, 24 sessions, 11 agents 2009-07-20: Snowglobe Release 1.0.2.2451: 11.18 crashes/100 hr, 1818 crashes, 10453.40 hours, 7165 sessions, 3428 agents Snowglobe Test Build 1.1.0.2511: 0.00 crashes/100 hr, 0 crashes, 192.40 hours, 146 sessions, 75 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 124.30 hours, 90 sessions, 43 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 86.60 hours, 76 sessions, 30 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 76.30 hours, 60 sessions, 36 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 58.30 hours, 53 sessions, 25 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 51.30 hours, 26 sessions, 11 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 49.50 hours, 27 sessions, 11 agents Snowglobe Test Build 1.1.0.2523: 0.00 crashes/100 hr, 0 crashes, 20.80 hours, 28 sessions, 18 agents 2009-07-19: Snowglobe Release 1.0.2.2451: 10.37 crashes/100 hr, 1956 crashes, 11694.50 hours, 7419 sessions, 3393 agents Snowglobe Test Build 1.1.0.2511: 4.75 crashes/100 hr, 13 crashes, 197.30 hours, 163 sessions, 75 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 182.60 hours, 93 sessions, 47 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 85.80 hours, 58 sessions, 25 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 84.10 hours, 65 sessions, 31 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 81.20 hours, 31 sessions, 15 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 73.40 hours, 61 sessions, 28 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 35.50 hours, 26 sessions, 11 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 31.20 hours, 26 sessions, 13 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 22.20 hours, 21 sessions, 13 agents 2009-07-18: Snowglobe Release 1.0.2.2451: 11.20 crashes/100 hr, 2044 crashes, 11640.70 hours, 7113 sessions, 3293 agents Snowglobe Test Build 1.1.0.2511: 4.59 crashes/100 hr, 12 crashes, 140.80 hours, 138 sessions, 62 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 136.00 hours, 71 sessions, 38 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 120.70 hours, 95 sessions, 39 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 60.80 hours, 53 sessions, 23 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 60.20 hours, 31 sessions, 15 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 46.10 hours, 45 sessions, 21 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 39.80 hours, 31 sessions, 13 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 39.40 hours, 27 sessions, 12 agents 2009-07-17: Snowglobe Release 1.0.2.2451: 10.20 crashes/100 hr, 1884 crashes, 11603.40 hours, 6787 sessions, 3328 agents Snowglobe Test Build 1.1.0.2511: 0.00 crashes/100 hr, 0 crashes, 165.20 hours, 107 sessions, 56 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 124.80 hours, 82 sessions, 43 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 106.10 hours, 54 sessions, 20 agents Snowglobe Test Build 1.1.0.2490: 7.60 crashes/100 hr, 15 crashes, 100.50 hours, 73 sessions, 45 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 73.00 hours, 25 sessions, 12 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 63.70 hours, 34 sessions, 18 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 52.30 hours, 44 sessions, 23 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 37.70 hours, 25 sessions, 11 agents 2009-07-16: Snowglobe Release 1.0.2.2451: 11.41 crashes/100 hr, 1860 crashes, 10316.90 hours, 6753 sessions, 3308 agents Snowglobe Test Build 1.1.0.2490: 7.96 crashes/100 hr, 21 crashes, 185.80 hours, 144 sessions, 70 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 102.00 hours, 87 sessions, 48 agents Snowglobe Test Build 1.1.0.2511: 0.00 crashes/100 hr, 0 crashes, 100.30 hours, 105 sessions, 50 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 93.20 hours, 61 sessions, 27 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 53.70 hours, 22 sessions, 12 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 53.10 hours, 45 sessions, 20 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 38.90 hours, 21 sessions, 12 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 34.00 hours, 24 sessions, 11 agents Snowglobe Release 1.22.11.0: 0.00 crashes/100 hr, 0 crashes, 24.20 hours, 24 sessions, 13 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 21.50 hours, 29 sessions, 12 agents 2009-07-15: Snowglobe Release 1.0.2.2451: 10.06 crashes/100 hr, 1736 crashes, 10776.00 hours, 6865 sessions, 3298 agents Snowglobe Test Build 1.1.0.2490: 6.25 crashes/100 hr, 23 crashes, 231.40 hours, 163 sessions, 85 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 91.70 hours, 83 sessions, 41 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 75.60 hours, 61 sessions, 33 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 75.40 hours, 26 sessions, 15 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 51.80 hours, 31 sessions, 16 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 43.30 hours, 27 sessions, 16 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 42.80 hours, 50 sessions, 23 agents Snowglobe Test Build 1.1.0.2511: 0.00 crashes/100 hr, 0 crashes, 25.10 hours, 23 sessions, 19 agents 2009-07-14: Snowglobe Release 1.0.2.2451: 10.04 crashes/100 hr, 1637 crashes, 10435.00 hours, 7088 sessions, 3408 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 241.50 hours, 203 sessions, 104 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 133.00 hours, 91 sessions, 42 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 96.00 hours, 35 sessions, 20 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 73.20 hours, 57 sessions, 34 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 67.20 hours, 39 sessions, 17 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 64.80 hours, 77 sessions, 30 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 39.60 hours, 23 sessions, 16 agents 2009-07-13: Snowglobe Release 1.0.2.2451: 9.79 crashes/100 hr, 1648 crashes, 11200.00 hours, 7072 sessions, 3403 agents Snowglobe Test Build 1.1.0.2490: 9.07 crashes/100 hr, 32 crashes, 253.40 hours, 159 sessions, 88 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 140.00 hours, 103 sessions, 40 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 101.30 hours, 99 sessions, 29 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 100.60 hours, 102 sessions, 43 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 78.10 hours, 46 sessions, 18 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 71.20 hours, 31 sessions, 16 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 47.60 hours, 35 sessions, 15 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 37.70 hours, 42 sessions, 15 agents 2009-07-12: Snowglobe Release 1.0.2.2451: 9.01 crashes/100 hr, 1604 crashes, 11414.00 hours, 6947 sessions, 3286 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 154.00 hours, 101 sessions, 49 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 145.00 hours, 76 sessions, 39 agents Snowglobe Test Build 1.1.0.2490: 5.55 crashes/100 hr, 12 crashes, 144.40 hours, 148 sessions, 72 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 83.60 hours, 47 sessions, 21 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 71.20 hours, 37 sessions, 18 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 60.70 hours, 37 sessions, 16 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 41.00 hours, 34 sessions, 15 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 36.70 hours, 21 sessions, 11 agents Snowglobe Release 1.23.4.0: 0.00 crashes/100 hr, 0 crashes, 25.20 hours, 38 sessions, 13 agents 2009-07-11: Snowglobe Release 1.0.2.2451: 9.01 crashes/100 hr, 1630 crashes, 11907.40 hours, 7180 sessions, 3231 agents Snowglobe Test Build 1.1.0.2462: 6.21 crashes/100 hr, 17 crashes, 159.60 hours, 107 sessions, 51 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 124.80 hours, 123 sessions, 56 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 118.00 hours, 77 sessions, 35 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 68.10 hours, 39 sessions, 16 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 52.20 hours, 24 sessions, 13 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 50.00 hours, 20 sessions, 13 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 40.00 hours, 47 sessions, 16 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 37.80 hours, 29 sessions, 16 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 30.10 hours, 33 sessions, 14 agents 2009-07-10: Snowglobe Release 1.0.2.2451: 9.28 crashes/100 hr, 1598 crashes, 11486.40 hours, 6861 sessions, 3229 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 225.10 hours, 103 sessions, 50 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 185.80 hours, 112 sessions, 54 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 114.50 hours, 30 sessions, 15 agents Snowglobe Test Build 1.1.0.2490: 8.25 crashes/100 hr, 16 crashes, 102.50 hours, 99 sessions, 45 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 72.80 hours, 26 sessions, 13 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 63.70 hours, 24 sessions, 16 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 54.80 hours, 46 sessions, 22 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 46.30 hours, 41 sessions, 11 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 37.20 hours, 21 sessions, 12 agents 2009-07-09: Snowglobe Release 1.0.2.2451: 8.87 crashes/100 hr, 1436 crashes, 10401.50 hours, 6623 sessions, 3156 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 193.20 hours, 106 sessions, 56 agents Snowglobe Test Build 1.1.0.2486: 7.76 crashes/100 hr, 17 crashes, 135.60 hours, 113 sessions, 60 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 88.00 hours, 49 sessions, 26 agents Snowglobe Test Build 1.1.0.2490: 0.00 crashes/100 hr, 0 crashes, 76.40 hours, 71 sessions, 39 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 64.80 hours, 25 sessions, 11 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 59.60 hours, 33 sessions, 16 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 57.70 hours, 21 sessions, 16 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 47.70 hours, 64 sessions, 29 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 32.50 hours, 28 sessions, 11 agents 2009-07-08: Snowglobe Release 1.0.2.2451: 9.64 crashes/100 hr, 1370 crashes, 9415.90 hours, 6316 sessions, 3061 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 252.00 hours, 141 sessions, 82 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 123.70 hours, 106 sessions, 49 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 83.10 hours, 62 sessions, 28 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 75.30 hours, 38 sessions, 16 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 58.20 hours, 33 sessions, 21 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 54.20 hours, 22 sessions, 15 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 26.40 hours, 16 sessions, 12 agents 2009-07-07: Snowglobe Release 1.0.2.2451: 9.37 crashes/100 hr, 1400 crashes, 9750.40 hours, 6163 sessions, 3010 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 192.40 hours, 155 sessions, 77 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 138.80 hours, 90 sessions, 55 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 92.60 hours, 47 sessions, 22 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 56.80 hours, 39 sessions, 18 agents Snowglobe Test Build 1.1.0.2457: 0.00 crashes/100 hr, 0 crashes, 55.30 hours, 25 sessions, 11 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 52.40 hours, 33 sessions, 17 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 47.70 hours, 25 sessions, 12 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 43.60 hours, 30 sessions, 14 agents Snowglobe Release 1.22.11.0: 0.00 crashes/100 hr, 0 crashes, 35.40 hours, 27 sessions, 14 agents 2009-07-06: Snowglobe Release 1.0.2.2451: 9.26 crashes/100 hr, 1363 crashes, 9623.80 hours, 6073 sessions, 2897 agents Snowglobe Test Build 1.1.0.2486: 5.33 crashes/100 hr, 14 crashes, 169.50 hours, 129 sessions, 80 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 162.60 hours, 113 sessions, 57 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 95.60 hours, 50 sessions, 20 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 77.60 hours, 16 sessions, 12 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 60.40 hours, 32 sessions, 12 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 55.90 hours, 37 sessions, 17 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 40.50 hours, 48 sessions, 31 agents Snowglobe Release 1.22.11.0: 0.00 crashes/100 hr, 0 crashes, 24.90 hours, 26 sessions, 15 agents 2009-07-05: Snowglobe Release 1.0.2.2451: 8.71 crashes/100 hr, 1276 crashes, 9844.70 hours, 6187 sessions, 2884 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 212.70 hours, 112 sessions, 59 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 159.60 hours, 121 sessions, 68 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 96.00 hours, 63 sessions, 32 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 80.10 hours, 35 sessions, 15 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 65.80 hours, 41 sessions, 20 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 62.00 hours, 42 sessions, 18 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 54.10 hours, 23 sessions, 11 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 44.00 hours, 50 sessions, 21 agents 2009-07-04: Snowglobe Release 1.0.2.2451: 9.04 crashes/100 hr, 1363 crashes, 9694.90 hours, 6000 sessions, 2788 agents Snowglobe Test Build 1.1.0.2462: 6.71 crashes/100 hr, 21 crashes, 180.10 hours, 129 sessions, 52 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 130.10 hours, 101 sessions, 63 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 117.60 hours, 51 sessions, 18 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 92.50 hours, 50 sessions, 21 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 74.80 hours, 45 sessions, 24 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 62.00 hours, 59 sessions, 21 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 56.60 hours, 30 sessions, 12 agents Snowglobe Test Build 1.1.0.2457: 0.00 crashes/100 hr, 0 crashes, 40.00 hours, 29 sessions, 12 agents 2009-07-03: Snowglobe Release 1.0.2.2451: 9.06 crashes/100 hr, 1166 crashes, 8304.20 hours, 5029 sessions, 2623 agents Snowglobe Test Build 1.1.0.2462: 0.00 crashes/100 hr, 0 crashes, 232.00 hours, 138 sessions, 65 agents Snowglobe Test Build 1.1.0.2484: 0.00 crashes/100 hr, 0 crashes, 133.40 hours, 77 sessions, 38 agents Snowglobe Release 1.0.0.2435: 0.00 crashes/100 hr, 0 crashes, 91.90 hours, 42 sessions, 27 agents Snowglobe Test Build 1.1.0.2459: 0.00 crashes/100 hr, 0 crashes, 69.80 hours, 36 sessions, 12 agents Snowglobe Release 1.0.1.2446: 0.00 crashes/100 hr, 0 crashes, 69.50 hours, 22 sessions, 11 agents Snowglobe Test Build 1.1.0.2457: 0.00 crashes/100 hr, 0 crashes, 44.00 hours, 34 sessions, 18 agents Snowglobe Test Build 1.1.0.2486: 0.00 crashes/100 hr, 0 crashes, 42.80 hours, 38 sessions, 30 agents Snowglobe Release 1.0.2.0: 0.00 crashes/100 hr, 0 crashes, 39.20 hours, 29 sessions, 14 agents Snowglobe Release 1.1.0.0: 0.00 crashes/100 hr, 0 crashes, 32.40 hours, 35 sessions, 16 agents From billwindwalker at rocketmail.com Sat Aug 29 04:15:45 2009 From: billwindwalker at rocketmail.com (Bill Windwalker) Date: Sat, 29 Aug 2009 04:15:45 -0700 (PDT) Subject: [sldev] SnowGlobe and copybots In-Reply-To: References: <20090828104809.GA17581@alinoe.com> Message-ID: <763227.23648.qm@web111207.mail.gq1.yahoo.com> Good day every one. Yesterday i was a victim of a copybot and a group of griefers. this type of bullying and theft of content needs to stop they are making a joke out of all the hard work people do in SL. As i sat and talk to a friend a griefer had taken only a sec to copy my AV and every thing i had on in a sec and did it to the very sim i was in. And what they did say in voice made it sound like linden lab had no power to stop any griefer. i even have screen shots of this attack. what im told is they can do it with open source viewers . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090829/26a39d8a/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: proof of copybot.tga Type: application/octet-stream Size: 786450 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090829/26a39d8a/attachment-0001.obj From stickman at gmail.com Sat Aug 29 04:48:07 2009 From: stickman at gmail.com (Stickman) Date: Sat, 29 Aug 2009 04:48:07 -0700 Subject: [sldev] SnowGlobe and copybots In-Reply-To: <763227.23648.qm@web111207.mail.gq1.yahoo.com> References: <20090828104809.GA17581@alinoe.com> <763227.23648.qm@web111207.mail.gq1.yahoo.com> Message-ID: Bill, I'm not sure this issue relates to open source development in Second Life. You mention it in the end -- but your point is like saying you can use a yard stick to hit someone with. Sure, but that's not the intended utility. If they really wanted to hit someone, they'd use whatever was handy. As for your issue, you may want to reread the Terms of Service everyone has to agree to in order to log into Second Life. Stealing other people's content, harassment, griefing -- it's not allowed. You can Abuse Report the people that do so. If you're a content creator and they steal your creations you can file a DMCA notice and Linden Labs will look into the copyright infringement. Terms of Service - http://secondlife.com/corporate/tos.php Abuse Reporting - http://wiki.secondlife.com/wiki/Help:When_and_how_to_file_an_Abuse_Report DMCA - http://secondlife.com/corporate/dmca.php Also, I created a Jira a little while back recommending a brave Lawyer Linden open up some office hours: http://jira.secondlife.com/browse/MISC-3263 Seems like a good time to promote it. Happy SLing! -Stickman On Sat, Aug 29, 2009 at 4:15 AM, Bill Windwalker wrote: > Good day every one. > Yesterday i was a victim of a copybot and a group of griefers. > this type of bullying and theft of content needs to stop they are making a > joke out of all the hard work people do in SL. > As i sat and talk to a friend a griefer had taken only a sec to copy my AV > and every thing i had on in a sec and did it to the very sim i was in. > And what they did say in voice made it sound like linden lab had no power to > stop any griefer. > i even have screen shots of this attack. > what im told is they can do it with open source viewers . > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From open at autistici.org Sat Aug 29 06:22:38 2009 From: open at autistici.org (Opensource Obscure) Date: Sat, 29 Aug 2009 13:22:38 +0000 Subject: [sldev] SnowGlobe and copybots In-Reply-To: <763227.23648.qm@web111207.mail.gq1.yahoo.com> References: <20090828104809.GA17581@alinoe.com> <763227.23648.qm@web111207.mail.gq1.yahoo.com> Message-ID: <131307f4a0dd3a5f5d36db2c54c08003@localhost> On Sat, 29 Aug 2009 04:15:45 -0700 (PDT), Bill Windwalker wrote: > Good day every one. > Yesterday i was a victim of a copybot and a group of griefers. > this type of bullying and theft of content needs to stop they are making a > joke out of all the hard work people do in SL. > As i sat and talk to a friend a griefer had taken only a sec to copy my AV > and every thing i had on in a sec and did it to the very sim i was in. > And what they did say in voice made it sound like linden lab had no power > to stop any griefer. > i even have screen shots of this attack. > what im told is they can do it with open source viewers . hi Bill, I'm sorry for what happened to you. Be aware though that 1) the official LL viewer IS an open source viewer 2) copybots existed BEFORE the viewer was made open source Please transmit this information to those people that told you that "they can do it with open source viewers", because they're actually spreading misinformation and confusing others when they say so. Best regards, Opensource Obscure From thickbrick.sleaford at gmail.com Sat Aug 29 09:54:35 2009 From: thickbrick.sleaford at gmail.com (Thickbrick Sleaford) Date: Sat, 29 Aug 2009 19:54:35 +0300 Subject: [sldev] SNOWGLOBE In-Reply-To: <656171.61496.qm@web111215.mail.gq1.yahoo.com> References: <656171.61496.qm@web111215.mail.gq1.yahoo.com> Message-ID: <200908291954.35942.thickbrick.sleaford@gmail.com> On Friday 28 August 2009 14:58:28 Bill Windwalker wrote: > Need to know befor filing a jira. > Hi i think i have found a bug in the Map that i have been seeing a large > number of islands thats not there on the SL client. but i can not find a > jira about this bug if there is one . > any one remember seeing this happen or a jira on this? If you mean the viewer map in Snowglobe, It sounds like SNOW-111 https://jira.secondlife.com/browse/SNOW-111 From aimee.trescothick at gmail.com Sun Aug 30 18:46:49 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Mon, 31 Aug 2009 02:46:49 +0100 Subject: [sldev] [PATCH] Request review for SNOW-210 Message-ID: <8D7F0C6D-0120-4923-8CE7-8C73C02B4766@gmail.com> Hi, Can someone review SNOW-210 for inclusion in Snowglobe so that I can commit it? Most of this has already gone into maint-viewer, except for one additional one that was introduced with a recent patch in Snowglobe. Now that GCC-4.2 is the default compiler on Snow Leopard it would be nice to get this in, so that Snowglobe still compiles out of the box on OS X 10.6 Aimee. From lenglish5 at cox.net Mon Aug 31 00:14:25 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 31 Aug 2009 00:14:25 -0700 Subject: [sldev] Tip of the iceberg... Message-ID: <4A9B7851.90107@cox.net> grats to aimee trescothick: http://www.youtube.com/watch?v=TtHO4AtVSwc and for heaven's sake, Linden Lab, wake up to the potential. In addition to things like Croquet on a prim, you can have IDEs of all descriptions on a prim, advanced building systems that inject packets into the local viewer while allowing manipulation of the prim in hybrid in-world/out-world creation systems, private p2p content sharing/manipulation systems, etc. (XMPP and Google Wave, eat your heart out). We need a way to access localhost without going round our elbow to fake the SL viewer into letting us work with our own local content before uploading, our own advanced scripting/programming/etc stuff and etc. Not all of us have direct permission to set parcel media. At the least, as I've pointed out, we need to be able to set multiple localhost urls within a HUD so we can work with our own custom media types before making them available to the SL Community. Lawson From carlo at alinoe.com Mon Aug 31 05:05:15 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 31 Aug 2009 14:05:15 +0200 Subject: [sldev] Tip of the iceberg... In-Reply-To: <4A9B7851.90107@cox.net> References: <4A9B7851.90107@cox.net> Message-ID: <20090831120515.GA663@alinoe.com> On Mon, Aug 31, 2009 at 12:14:25AM -0700, Lawson English wrote: > grats to aimee trescothick: > > http://www.youtube.com/watch?v=TtHO4AtVSwc Is this visible in-world to everyone? Or only to the person running the plugin? It seems that it can only look like this to the one running the plugin: it is a 100% local thing. While useful, it "breaks" the demand of a shared experience. -- Carlo Wood From aimee.trescothick at gmail.com Mon Aug 31 05:46:27 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Mon, 31 Aug 2009 13:46:27 +0100 Subject: [sldev] Tip of the iceberg... In-Reply-To: <4A9B7851.90107@cox.net> References: <4A9B7851.90107@cox.net> Message-ID: <79DDB444-C95A-42BD-8954-B857B824FF45@gmail.com> On 31 Aug 2009, at 08:14, Lawson English wrote: > grats to aimee trescothick: > > http://www.youtube.com/watch?v=TtHO4AtVSwc Thank you Sai :) The video was done to go with the article at http://www.rezmagazine.co.uk/2009/08/trescothick-aims-to-please.html where I talk about the plug-in a bit in the second half if you want to skip the boring stuff about me LOL > and for heaven's sake, Linden Lab, wake up to the potential. To be fair, from the conversations I've had this week I think they're well aware of it, that's why they wrote the API that makes this possible. > We need a way to access localhost without going round our elbow to > fake > the SL viewer into letting us work with our own local content before > uploading, our own advanced scripting/programming/etc stuff and etc. > Not > all of us have direct permission to set parcel media. At the least, as > I've pointed out, we need to be able to set multiple localhost urls > within a HUD so we can work with our own custom media types before > making them available to the SL Community. There's more work to come here yet, as shown by the multiple media streams demo at SLCC. It wouldn't be hard though to patch the viewer so you could "fake" your own media URL for testing or whatever. Aimee. From aimee.trescothick at gmail.com Mon Aug 31 05:52:16 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Mon, 31 Aug 2009 13:52:16 +0100 Subject: [sldev] Tip of the iceberg... In-Reply-To: <20090831120515.GA663@alinoe.com> References: <4A9B7851.90107@cox.net> <20090831120515.GA663@alinoe.com> Message-ID: It will be visible to anyone else running the plug-in too, as long as they are authorised to connect to the remote machine. Of course that means that everyone viewing needs a chunk of bandwidth, so for more than just a small group, or on the local network, you'll want to use a VNC reflector between it and the clients (similar to what you would already do with streaming server for a video stream). Otherwise you'll most likely soon saturate an upstream DSL connection or whatever. Once the client supports it, any authorised viewer will also be able to control the remote machine through it too. The video was done to go with the article at http://bit.ly/xJK9B where I talk a bit about the VNC/plug-in stuff in the second half, if you want to skip the boring bits about me LOL Aimee. On 31 Aug 2009, at 13:05, Carlo Wood wrote: > On Mon, Aug 31, 2009 at 12:14:25AM -0700, Lawson English wrote: >> grats to aimee trescothick: >> >> http://www.youtube.com/watch?v=TtHO4AtVSwc > > Is this visible in-world to everyone? Or only to the person > running the plugin? > > It seems that it can only look like this to the > one running the plugin: it is a 100% local thing. > > While useful, it "breaks" the demand of a shared > experience. > > -- > Carlo Wood From secret.argent at gmail.com Mon Aug 31 06:35:25 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon, 31 Aug 2009 08:35:25 -0500 Subject: [sldev] Tip of the iceberg... In-Reply-To: <4A9B7851.90107@cox.net> References: <4A9B7851.90107@cox.net> Message-ID: <83CC85FF-7BFF-4B4C-A2E5-DC1B516E9E4C@gmail.com> I've been speculating about this for years, though not using the parcel media, or the overhead of VNC. It should be possible to make SL act as a window manager, and have local media textures (only visible to and set within the viewer) render locally executing programs without this kind of rigamarole. From lenglish5 at cox.net Mon Aug 31 06:53:34 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 31 Aug 2009 06:53:34 -0700 Subject: [sldev] Tip of the iceberg... In-Reply-To: <83CC85FF-7BFF-4B4C-A2E5-DC1B516E9E4C@gmail.com> References: <4A9B7851.90107@cox.net> <83CC85FF-7BFF-4B4C-A2E5-DC1B516E9E4C@gmail.com> Message-ID: <4A9BD5DE.2030707@cox.net> Argent Stonecutter wrote: > I've been speculating about this for years, though not using the > parcel media, or the overhead of VNC. It should be possible to make SL > act as a window manager, and have local media textures (only visible > to and set within the viewer) render locally executing programs > without this kind of rigamarole. > _______________________________________________ > Certainly possible with Squeak smalltalk since you can direct the rendering to an offscreen buffer if you want. Unfortunately, I'm not so hep on how to take the shared buffer created by the SL plugin and pass it on to the squeak-side plugin. I guess just pass the address in with a POST to the localhost URL A more interesting situation will result when you start to manipulate packets via a gridproxy (or preferably an external event handler plugin so you can have more fine-grained control) and use a webpage or in-world GUI for the programming interface to an IDE. You can also use the same principle to feed a view-only stream to a regular media stream so that others can watch as you program (or combine things as Aimee suggests with a remote VNC server). For me, the ultimate prototyping/hacking SL plugin will be the combo I'm trying to work on: a seaside localhost webserver that can manipulate packets via gridproxy, and provide control surfaces for packet interfaces via localhost webpages and/or interactive Squeak windowing done through the media pliugin. http://www.seaside.st seaside is a smalltalk-based webserver that maintains server-side state for each webpage in a session, and comes bundled with all manner of goodies like blogs/wikis and of course squeak itself. Perfect for private database/blogging/diary/programming/asset managing/content creation/etc/etc stuff. And if you have a need to share your work with others, you can use smalltalk to provide P2P communications with other clients, or send whatever you want to share to an external media server for normal viewing via SL media URLs. Of course, other programming languages and IDEs could be used instead of squeak, but there's just this thing about "Croquet on a Prim" as a multi-media P2P IM system that appeals to me (not to mention that smalltalk is about the ultimate prototyping language if you don't need maximum speed since you can modify the entire system on the fly). Lawson From overdrive at dceo.rutgers.edu Mon Aug 31 10:15:06 2009 From: overdrive at dceo.rutgers.edu (Ron Festa) Date: Mon, 31 Aug 2009 13:15:06 -0400 Subject: [sldev] SnowGlobe and copybots Message-ID: <3c59673d0908311015h7fb922f2h8261d4f27c2f80eb@mail.gmail.com> While its true they can modify the opensource code to turn a client into a copybot, as far as I know there really hasn't been any known copybot viewers that have popped up because there's no code in the LL viewer that allows asset copying. Majority of copybots are really modded poorly written legit bots. While there is a really obscure patch that's floating around griefer circles, most griefers are not programmers. Most do not know how to inject and maintain custom code into the source code then compile it with every version. But, thanks to the open source viewers floating around you also have an amount of protection from griefers you can't get in the LL viewer. Viewers like Meerkat & Emerald make it impossible for them to steel your clothing and provides additional tools that would prevent them from attacking your or removing them from your property before they become a problem. Plus they have a bunch of fun stuff in them that just make your life easier in SL. On Sat, Aug 29, 2009 at 4:15 AM, Bill Windwalker wrote: > Good day every one. > Yesterday i was a victim of a copybot and a group of griefers. > this type of bullying and theft of content needs to stop they are making a > joke out of all the hard work people do in SL. > As i sat and talk to a friend a griefer had taken only a sec to copy my AV > and every thing i had on in a sec and did it to the very sim i was in. > And what they did say in voice made it sound like linden lab had no power to > stop any griefer. > i even have screen shots of this attack. > what im told is they can do it with open source viewers . > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090831/e7c8ac58/attachment.htm From nyx at lindenlab.com Mon Aug 31 10:52:35 2009 From: nyx at lindenlab.com (nyx linden) Date: Mon, 31 Aug 2009 13:52:35 -0400 Subject: [sldev] SnowGlobe and copybots In-Reply-To: <3c59673d0908311015h7fb922f2h8261d4f27c2f80eb@mail.gmail.com> References: <3c59673d0908311015h7fb922f2h8261d4f27c2f80eb@mail.gmail.com> Message-ID: <4A9C0DE3.4030208@lindenlab.com> Additionally, the technique to stop malicious clients from stealing your clothing textures (namely, only sending out baked but not local texture data) will be in the main client in the next major release, as part of a larger avatar overhaul. The reasons for this extend beyond content theft, but stopping this is a major benefit to this switch in protocol. Combating griefing attacks and content theft is not an easy task, but we are taking steps to minimize the potential for abuse, and we try to have systems in place for what to do when it does occur (including dealing with the specific instance of abuse as well as looking for ways to prevent future issues). We're always looking for ways of making the client secure, and welcome feedback and ideas to help us move in this direction. -Nyx Ron Festa wrote: > While its true they can modify the opensource code to turn a client > into a copybot, as far as I know there really hasn't been any known > copybot viewers that have popped up because there's no code in the LL > viewer that allows asset copying. Majority of copybots are really > modded poorly written legit bots. While there is a really obscure > patch that's floating around griefer circles, most griefers are not > programmers. Most do not know how to inject and maintain custom code > into the source code then compile it with every version. > > But, thanks to the open source viewers floating around you also have > an amount of protection from griefers you can't get in the LL viewer. > Viewers like Meerkat & Emerald make it impossible for them to steel > your clothing and provides additional tools that would prevent them > from attacking your or removing them from your property before they > become a problem. Plus they have a bunch of fun stuff in them that > just make your life easier in SL. > > On Sat, Aug 29, 2009 at 4:15 AM, Bill > Windwalker > wrote: > > Good day every one. > > Yesterday i was a victim of a copybot and a group of griefers. > > this type of bullying and theft of content needs to stop they are > making a > > joke out of all the hard work people do in SL. > > As i sat and talk to a friend a griefer had taken only a sec to copy > my AV > > and every thing i had on in a sec and did it to the very sim i was in. > > And what they did say in voice made it sound like linden lab had no > power to > > stop any griefer. > > i even have screen shots of this attack. > > what im told is they can do it with open source viewers . > > > > > > > > > > ______________________________ > _________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From tigrospottystripes at gmail.com Mon Aug 31 13:21:12 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Mon, 31 Aug 2009 17:21:12 -0300 Subject: [sldev] VWR-14840, opinions? Message-ID: <4A9C30B8.8000604@Gmail.com> I'm sending this msg 'cause I wanna hear your opinions about this feature request http://jira.secondlife.com/browse/VWR-14840 From labrat.hb at gmail.com Mon Aug 31 15:37:50 2009 From: labrat.hb at gmail.com (Harold Brown) Date: Mon, 31 Aug 2009 15:37:50 -0700 Subject: [sldev] Tip of the iceberg... In-Reply-To: <4A9BD5DE.2030707@cox.net> References: <4A9B7851.90107@cox.net> <83CC85FF-7BFF-4B4C-A2E5-DC1B516E9E4C@gmail.com> <4A9BD5DE.2030707@cox.net> Message-ID: I just wanna see Hulu on a prim [?] On Mon, Aug 31, 2009 at 6:53 AM, Lawson English wrote: > Argent Stonecutter wrote: > > I've been speculating about this for years, though not using the > > parcel media, or the overhead of VNC. It should be possible to make SL > > act as a window manager, and have local media textures (only visible > > to and set within the viewer) render locally executing programs > > without this kind of rigamarole. > > _______________________________________________ > > > > Certainly possible with Squeak smalltalk since you can direct the > rendering to an offscreen buffer if you want. Unfortunately, I'm not so > hep on how to take the shared buffer created by the SL plugin and pass > it on to the squeak-side plugin. I guess just pass the address in with a > POST to the localhost URL > > > > A more interesting situation will result when you start to manipulate > packets via a gridproxy (or preferably an external event handler plugin > so you can have more fine-grained control) and use a webpage or in-world > GUI for the programming interface to an IDE. > > > You can also use the same principle to feed a view-only stream to a > regular media stream so that others can watch as you program (or combine > things as Aimee suggests with a remote VNC server). > > For me, the ultimate prototyping/hacking SL plugin will be the combo I'm > trying to work on: a seaside localhost webserver that can manipulate > packets via gridproxy, and provide control surfaces for packet > interfaces via localhost webpages and/or interactive Squeak windowing > done through the media pliugin. > > > http://www.seaside.st > > seaside is a smalltalk-based webserver that maintains server-side state > for each webpage in a session, and comes bundled with all manner of > goodies like blogs/wikis and of course squeak itself. Perfect for > private database/blogging/diary/programming/asset managing/content > creation/etc/etc stuff. > > And if you have a need to share your work with others, you can use > smalltalk to provide P2P communications with other clients, or send > whatever you want to share to an external media server for normal > viewing via SL media URLs. > > > Of course, other programming languages and IDEs could be used instead of > squeak, but there's just this thing about "Croquet on a Prim" as a > multi-media P2P IM system that appeals to me (not to mention that > smalltalk is about the ultimate prototyping language if you don't need > maximum speed since you can modify the entire system on the fly). > > > > > Lawson > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090831/6b2bfedd/attachment.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 453 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090831/6b2bfedd/attachment.gif From robla at lindenlab.com Mon Aug 31 16:35:00 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 31 Aug 2009 16:35:00 -0700 Subject: [sldev] Routine code review: SNOW-212 - DirectX March 2009 update Message-ID: Hi folks, Quick two line patch to make builds using the March 2009 SDK work fine: https://jira.secondlife.com/browse/SNOW-212 Please comment on JIRA Rob From lenglish5 at cox.net Mon Aug 31 20:18:29 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 31 Aug 2009 20:18:29 -0700 Subject: [sldev] Tip of the iceberg... In-Reply-To: References: <4A9B7851.90107@cox.net> <83CC85FF-7BFF-4B4C-A2E5-DC1B516E9E4C@gmail.com> <4A9BD5DE.2030707@cox.net> Message-ID: <4A9C9285.7030900@cox.net> Harold Brown wrote: > I just wanna see Hulu on a prim That's doable right now with Aimee's VNC plugin. Just call up the webpage and watch. You can even select the program and adjust the volume via the laptop prim. DOn't know if she has audio working, come to think of it, but you DID say "see"... Lawson