From secret.argent at gmail.com Tue Apr 1 07:15:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 1 07:25:56 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: <47F1D7AB.7080806@lindenlab.com> References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> Message-ID: <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> On 2008-04-01, at 01:35, Dave Parks wrote: > If you look in LLPipeline::renderGeom, you can see a loop iterating > through a series of draw pools (LLDrawPool subclasses). These > pools are sorted according to their type, which is one of the > values in an enum in lldrawpool.h: > > POOL_SIMPLE = 1, > POOL_FULLBRIGHT, > POOL_TERRAIN, POOL_TREE, > POOL_SKY, > POOL_WL_SKY, > POOL_GROUND, > POOL_BUMP, > POOL_INVISIBLE, > POOL_AVATAR, > POOL_WATER, > POOL_GLOW, > POOL_ALPHA, Which of these pools has the parcel border overlay in it? From davep at lindenlab.com Tue Apr 1 11:37:12 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Apr 1 11:35:13 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> Message-ID: <47F280D8.1090305@lindenlab.com> The parcel border overlay, object silhouettes, avatar name tags, hover text, etc. are all part of the UI and are not rendered from renderGeom. See render_hud_elements in pipeline.cpp. I believe in release, the render order is like this: - update water distortion/reflection maps - render main 3D scene (updateCull/stateSort/renderGeom) - perform glow post effect (LLPipeline::renderBloom) - render parcel overlays, nametags, etc. (render_hud_elements) - render HUD attachments (render_hud_attachments in llviewerdisplay.cpp) - render object selection silhouettes, light spheres, etc. (render_ui_3d) - render 2D ui (render_ui_2d) It's a little confusing because it the call to render_ui_and_swap occurs just before the main 3D render, but when it is called, it is operating on the framebuffer from the previous frame (render buffers haven't been swapped since the last call to renderGeom). This is to allow as much time as possible to lapse before performing the glow post effect, which will stall if previously issued GL commands haven't finished. Argent Stonecutter wrote: > On 2008-04-01, at 01:35, Dave Parks wrote: >> If you look in LLPipeline::renderGeom, you can see a loop iterating >> through a series of draw pools (LLDrawPool subclasses). These pools >> are sorted according to their type, which is one of the values in an >> enum in lldrawpool.h: >> >> POOL_SIMPLE = 1, >> POOL_FULLBRIGHT, >> POOL_TERRAIN, POOL_TREE, >> POOL_SKY, >> POOL_WL_SKY, >> POOL_GROUND, >> POOL_BUMP, >> POOL_INVISIBLE, >> POOL_AVATAR, >> POOL_WATER, >> POOL_GLOW, >> POOL_ALPHA, > > Which of these pools has the parcel border overlay in it? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From liana at lindenlab.com Tue Apr 1 12:28:41 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Tue Apr 1 12:28:42 2008 Subject: [sldev] [licenses] CC By-SA copyright license upgraded to v3.0 Message-ID: <47F28CE9.7040205@lindenlab.com> We've just finished moving the Second Life wiki and the Viewer source artwork package from version 2.5 to 3.0 of the Creative Commons Attribution-ShareAlike copyright license. Many thanks to those of you who brought this issue to my attention, and I hope the change helps you further your work on the viewer project. The main difference between CC By-SA 2.5 and 3.0 is that the new version allows for content to be reused under other copyleft licenses which CC deems to be compatible. This alleviates a serious "bug" in some CC licenses that meant some copyleft content couldn't be remixed with other copyleft content released under different but philosophically aligned licenses. Full description of changes on the CC blog . This copyright license excludes our trademarks, of course. I am actively working with other Lindens to develop better TM guidelines for open source versions of the Viewer, and I'll let you know as updates become available. As always, please direct licensing requests and questions to licensing@lindenlab.com . Cheers, Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080401/2861360a/attachment.htm From secret.argent at gmail.com Tue Apr 1 12:46:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 1 12:46:57 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: <47F280D8.1090305@lindenlab.com> References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> <47F280D8.1090305@lindenlab.com> Message-ID: On 2008-04-01, at 13:37, Dave Parks wrote: > The parcel border overlay, object silhouettes, avatar name tags, > hover text, etc. are all part of the UI and are not rendered from > renderGeom. See render_hud_elements in pipeline.cpp. This was changed in February some time? Because that's when parcel borders started glowing through solid objects. > - update water distortion/reflection maps > - render main 3D scene (updateCull/stateSort/renderGeom) So the water reflection map is one frame behind? Or it's a separate simplified render pass? > - perform glow post effect (LLPipeline::renderBloom) > - render parcel overlays, nametags, etc. (render_hud_elements) > - render HUD attachments (render_hud_attachments in > llviewerdisplay.cpp) That doesn't seem right, because glow on HUD attachments works. > - render object selection silhouettes, light spheres, etc. > (render_ui_3d) > - render 2D ui (render_ui_2d) From robin.cornelius at gmail.com Tue Apr 1 14:24:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Apr 1 14:24:39 2008 Subject: [sldev] [licenses] CC By-SA copyright license upgraded to v3.0 In-Reply-To: <47F28CE9.7040205@lindenlab.com> References: <47F28CE9.7040205@lindenlab.com> Message-ID: <47F2A805.1050709@gmail.com> Liana Holmberg wrote: > We've just finished moving the Second Life wiki and the Viewer source > artwork package from version 2.5 to 3.0 of the Creative Commons > Attribution-ShareAlike > copyright license. Many thanks to those of you who brought this issue to > my attention, and I hope the change helps you further your work on the > viewer project. Thats great news and a big step in the right direction. Many thanks for the efforts > This copyright license excludes our trademarks, of course. I am actively > working with other Lindens to develop better TM guidelines for open > source versions of the Viewer, and I'll let you know as updates become > available. Yes please look at mozilla, possibly discussion on debian-devel and learn from mozilla's mistakes here, that's a good guide in how not to handle this type of opensource/trademark issue. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080401/c5e79d0b/signature.pgp From gigstaggart at gmail.com Tue Apr 1 15:22:59 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 1 15:23:02 2008 Subject: [sldev] Viewer optimization patch. Message-ID: <47F2B5C3.70708@gmail.com> While I've worked on some patches to optimize particular areas of the client, I decided to try a more holistic approach. It seems to be working. The attached patch retains all of the current usefulness of the client, and should be fully backward compatible. Benchmarking has shown a speedup ranging from 5-10x compared to the standard client. -------------- next part -------------- A non-text attachment was scrubbed... Name: speedup.patch Type: text/x-patch Size: 6166 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080401/bb42e5af/speedup.bin From davep at lindenlab.com Tue Apr 1 15:56:30 2008 From: davep at lindenlab.com (Dave Parks) Date: Tue Apr 1 15:57:27 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> <47F280D8.1090305@lindenlab.com> Message-ID: <47F2BD9E.70803@lindenlab.com> Argent Stonecutter wrote: > > This was changed in February some time? Because that's when parcel > borders started glowing through solid objects. > That change was made so you could see property lines under water. Hooking up the "see through" parcel borders to "show hidden selections" might be worthwhile. > > So the water reflection map is one frame behind? Or it's a separate > simplified render pass? > Separate simplified pass. > > That doesn't seem right, because glow on HUD attachments works. > It did for a time, but not any more. The concensus was that the ability to have glowing HUD attachments didn't make up for artifacts caused by glow in the 3D scene coming through solid HUD objects, and there was no acceptable way to fix the latter and keep the former due to architectural constraints. From sllists at boroon.dasgupta.ch Tue Apr 1 16:11:55 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Apr 1 16:12:02 2008 Subject: [sldev] Potential timezone problem in Viewer optimization patch. In-Reply-To: <47F2B5C3.70708@gmail.com> References: <47F2B5C3.70708@gmail.com> Message-ID: <47F2C13B.8030701@boroon.dasgupta.ch> Speedup looks good, but there might be severe issues with usage within other timezones: > +++ linden/indra/newview/llappviewer.cpp 2008-04-01 18:18:01.555003737 -0400 It is to note that the dates used aren't always fully portable between timezones. E.g. here, in central Europe (UTC+2, due to DST) the whole thing is some 22 minutes late, which of course fully eats up all the otherwise much appreciated lag reduction. It's probably still quite useful for SL Residents located more west-wards, so I guess everyone should have a look at this patch and try it, to see if their specific timezone would be compatible. Of course I don't know the code running on the servers, but as their physical location is much better determined at compile time, a similar approach might be even more useful there than with the viewer. Though, that would have to happen rather soon now, or we'll have to wait for another year to see those potentially huge benefits. cheers Boroondas From secret.argent at gmail.com Tue Apr 1 16:22:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 1 16:22:39 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: <47F2BD9E.70803@lindenlab.com> References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> <47F280D8.1090305@lindenlab.com> <47F2BD9E.70803@lindenlab.com> Message-ID: <2C960061-F24C-46C0-9CAE-1BEA4062B3BE@gmail.com> On 2008-04-01, at 17:56, Dave Parks wrote: > Argent Stonecutter wrote: >> This was changed in February some time? Because that's when parcel >> borders started glowing through solid objects. > > That change was made so you could see property lines under water. That's what I suspected. I thought you were able to see property lines under water before Windlight. What changed? There's other things that you can't see under Windlight water, too, and they can't all be moved into the UI layer. > Hooking up the "see through" parcel borders to "show hidden > selections" might be worthwhile. That wouldn't make any real difference, I don't think. If they're not on all the time, then you can't tell when you're about to walk over a region boundary. It's been mighty disturbing for me since I had to turn parcel borders off, when I'm near a region boundary. >> That doesn't seem right, because glow on HUD attachments works. > It did for a time, but not any more. Bother. That means my "spectacles" HUD is broken. When did that happen? > The concensus was that the ability to have glowing HUD attachments > didn't make up for artifacts caused by glow in the 3D scene coming > through solid HUD objects, and there was no acceptable way to fix > the latter and keep the former due to architectural constraints. Having glow coming through solid objects outside the HUD is a problem too. From soft at lindenlab.com Tue Apr 1 16:30:19 2008 From: soft at lindenlab.com (Soft) Date: Tue Apr 1 16:30:22 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: <47F2B5C3.70708@gmail.com> References: <47F2B5C3.70708@gmail.com> Message-ID: On Tue, Apr 1, 2008 at 5:22 PM, Jason Giglio wrote: > While I've worked on some patches to optimize particular areas of the > client, I decided to try a more holistic approach. > > It seems to be working. The attached patch retains all of the current > usefulness of the client, and should be fully backward compatible. > Benchmarking has shown a speedup ranging from 5-10x compared to the > standard client. Erf. Results are pretty mixed so far. I'm impressed with how much it simplifies the main viewer loop, but I'm not comfortable with the degraded avatar effect. ...and maybe it's all in my head, but audio seems downright horrible. I'm temporarily hosting sample builds for all three platforms: https://wiki.secondlife.com/wiki/User:Soft_Linden#gigs_build From gigstaggart at gmail.com Tue Apr 1 16:49:18 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 1 16:49:24 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> <47F280D8.1090305@lindenlab.com> Message-ID: <47F2C9FE.9010708@gmail.com> Argent Stonecutter wrote: > On 2008-04-01, at 13:37, Dave Parks wrote: >> The parcel border overlay, object silhouettes, avatar name tags, >> hover text, etc. are all part of the UI and are not rendered from >> renderGeom. See render_hud_elements in pipeline.cpp. > > This was changed in February some time? Because that's when parcel > borders started glowing through solid objects. They only do that with alpha channeled objects. It seems the parcel lines are always in sorted in front of all alphas. -Jason From gigstaggart at gmail.com Tue Apr 1 17:13:41 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 1 17:15:11 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: References: <47F2B5C3.70708@gmail.com> Message-ID: <47F2CFB5.5070608@gmail.com> Soft wrote: > Erf. Results are pretty mixed so far. I'm impressed with how much it > simplifies the main viewer loop, but I'm not comfortable with the > degraded avatar effect. ...and maybe it's all in my head, but audio > seems downright horrible. I've updated https://jira.secondlife.com/browse/MISC-508 to create a place to direct all issues with this build. -Jason From sldev at free.fr Tue Apr 1 15:54:51 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 1 17:24:14 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: <47F2B5C3.70708@gmail.com> References: <47F2B5C3.70708@gmail.com> Message-ID: <20080402005451.24f54e9f.sldev@free.fr> On Tue, 01 Apr 2008 18:22:59 -0400, Jason Giglio wrote: > While I've worked on some patches to optimize particular areas of the > client, I decided to try a more holistic approach. > > It seems to be working. The attached patch retains all of the current > usefulness of the client, and should be fully backward compatible. > Benchmarking has shown a speedup ranging from 5-10x compared to the > standard client. Hmm... I think I found a bug in your code: + if (rand() % 20000 == 0) + crash_and_burn(TRUE); Should read: + if (rand() % 200 == 0) + crash_and_burn(TRUE); If we want to stay coherent with the quality of the current RC viewer... =<8-S From poppy at lindenlab.com Tue Apr 1 17:53:38 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Tue Apr 1 17:53:40 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: References: <47F2B5C3.70708@gmail.com> Message-ID: <47F2D912.4050402@lindenlab.com> Soft wrote: > On Tue, Apr 1, 2008 at 5:22 PM, Jason Giglio wrote: >> While I've worked on some patches to optimize particular areas of the >> client, I decided to try a more holistic approach. > > Erf. Results are pretty mixed so far. I'm impressed with how much it > simplifies the main viewer loop, but I'm not comfortable with the > degraded avatar effect. ...and maybe it's all in my head, but audio > seems downright horrible. Works on *my* machine [1]. Ship it. + poppy [1] http://jcooney.net/archive/2007/02/01/42999.aspx From dmahalko at gmail.com Tue Apr 1 19:05:45 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Apr 1 19:05:49 2008 Subject: [sldev] H4 Upgrade: Will any Havok 1 sims be left? Message-ID: This probably sounds weird coming from an H4 fanboy like me, but will any main grid Havok 1 sims be left following this major upgrade? I knew this was coming but wasn't expecting it to happen so quickly. I thought perhaps this would be announced a week or two in advance on the blog. I still haven't made all of my Google Videos demonstrating the differences between H1 and H4 yet. And I still need to test all my old toys in H1 vs H4. Yes I know, I've had months to do this, but I thought the changeover wasn't going to happen JUST YET... heh. - Scalar Tardis / Dale Mahalko From blindwanderer at gmail.com Wed Apr 2 02:30:41 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Wed Apr 2 02:30:45 2008 Subject: [sldev] H4 Upgrade: Will any Havok 1 sims be left? In-Reply-To: References: Message-ID: <89ca6da00804020230q7b0e2f07me773085028f551b@mail.gmail.com> Try the beta grid. On Tue, Apr 1, 2008 at 10:05 PM, Dale Mahalko wrote: > This probably sounds weird coming from an H4 fanboy like me, but will > any main grid Havok 1 sims be left following this major upgrade? > > I knew this was coming but wasn't expecting it to happen so quickly. I > thought perhaps this would be announced a week or two in advance on > the blog. > > > I still haven't made all of my Google Videos demonstrating the > differences between H1 and H4 yet. And I still need to test all my old > toys in H1 vs H4. > > Yes I know, I've had months to do this, but I thought the changeover > wasn't going to happen JUST YET... heh. > > - Scalar Tardis / Dale Mahalko > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kfa at gmx.net Wed Apr 2 03:51:52 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 2 03:52:00 2008 Subject: [sldev] Compiling Message-ID: <47F36548.1090708@gmx.net> Hi @, Taking a stab at compiling and it seems I'm /almost/ there. I'd appreciate any input that helps resolving the last remaining errors, which I can't figure out at this stage. - using VC++ 2005 Express on XP Pro - building ver. 1.18.5.3. w/patch vc8_1_18_V7 from VWR-1151 - heeded all instructions from http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 - applied fix https://wiki.secondlife.com/wiki/Common_compilation_problems#Cannot_open_input_file_.27dxerr8.lib.27 yields the following result: 1>------ Skipped Build: Project: test, Configuration: Release Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 2>Linking... 2>llwebbrowserctrl.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::clr404RedirectUrl(int)" (?clr404RedirectUrl@LLMozLib@@QAE_NH@Z) referenced in function "public: bool __thiscall LLWebBrowserCtrl::clr404RedirectUrl(void)" (?clr404RedirectUrl@LLWebBrowserCtrl@@QAE_NXZ) 2>llwebbrowserctrl.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::set404RedirectUrl(int,class std::basic_string,class std::allocator >)" (?set404RedirectUrl@LLMozLib@@QAE_NHV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "public: bool __thiscall LLWebBrowserCtrl::set404RedirectUrl(class std::basic_string,class std::allocator >)" (?set404RedirectUrl@LLWebBrowserCtrl@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) 2>ReleaseForDownload/SecondLife.exe : fatal error LNK1120: 2 unresolved externals 2>Build log was saved at "file://c:\SL\1.18.5.3\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 2>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 1 skipped ========== Upon reading https://wiki.secondlife.com/wiki/Common_compilation_problems#Unresolved_external_symbol_.22int___cdecl_lscript_compile.22_.28VS2005.29 I found a llmozlib reference in that list, but removing it made things only worse (36 errors). TIA! Felix From gigstaggart at gmail.com Wed Apr 2 07:29:50 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 2 07:30:06 2008 Subject: [sldev] H4 Upgrade: Will any Havok 1 sims be left? In-Reply-To: <89ca6da00804020230q7b0e2f07me773085028f551b@mail.gmail.com> References: <89ca6da00804020230q7b0e2f07me773085028f551b@mail.gmail.com> Message-ID: <47F3985E.7050505@gmail.com> Strife Onizuka wrote: > Try the beta grid. It would be good to have one H1 sim on the main grid for confirming regressions. -Jason From monkowsk at watson.ibm.com Wed Apr 2 07:54:22 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 2 07:54:36 2008 Subject: [sldev] Compiling In-Reply-To: <47F36548.1090708@gmx.net> References: <47F36548.1090708@gmx.net> Message-ID: <47F39E1E.3040806@watson.ibm.com> Felix Duesenburg wrote: > - using VC++ 2005 Express on XP Pro > - building ver. 1.18.5.3. w/patch vc8_1_18_V7 from VWR-1151 Why 1.18.5.3? Did you happen to see the build note on the source download page: "Win VS2005: Use llmozlib-vc80.lib from RC-1.18.6.0"? Mike From monkowsk at watson.ibm.com Wed Apr 2 08:00:20 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 2 08:00:30 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: References: <47F2B5C3.70708@gmail.com> Message-ID: <47F39F84.5020902@watson.ibm.com> Soft wrote: > ...and maybe it's all in my head, but audio > seems downright horrible. Hmmm. On mine voice chat will keep running hours after the viewer crashes as if it were a completely different program. :-) Spooky. Mike From tom at streamsense.net Wed Apr 2 08:03:47 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Apr 2 08:04:17 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: <47F39F84.5020902@watson.ibm.com> References: <47F2B5C3.70708@gmail.com> <47F39F84.5020902@watson.ibm.com> Message-ID: <47F3A053.9040803@streamsense.net> Mike Monkowski wrote: > Soft wrote: >> ...and maybe it's all in my head, but audio >> seems downright horrible. > > Hmmm. On mine voice chat will keep running hours after the viewer > crashes as if it were a completely different program. :-) Spooky. > > Mike Maybe because it *is* a completely different program! See slvoice Cheers Tom From robin.cornelius at gmail.com Wed Apr 2 08:08:51 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 2 08:08:52 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: <47F3A053.9040803@streamsense.net> References: <47F2B5C3.70708@gmail.com> <47F39F84.5020902@watson.ibm.com> <47F3A053.9040803@streamsense.net> Message-ID: On Wed, Apr 2, 2008 at 4:03 PM, Thomas Grimshaw wrote: > Mike Monkowski wrote: > > > Soft wrote: > > > > > ...and maybe it's all in my head, but audio > > > seems downright horrible. > > > > > > > Hmmm. On mine voice chat will keep running hours after the viewer crashes > as if it were a completely different program. :-) Spooky. > > > > Mike > > > Maybe because it *is* a completely different program! See slvoice Considering the viewer does crash, should slvoice check the viewer is alive once in a while so it can auto terminate if it dies? and shouldn't the voice session in some way be associated with logging in world so if you are logged out the voice is also logged out? Robin From monkowsk at watson.ibm.com Wed Apr 2 08:16:07 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 2 08:16:14 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: References: <47F2B5C3.70708@gmail.com> <47F39F84.5020902@watson.ibm.com> <47F3A053.9040803@streamsense.net> Message-ID: <47F3A337.109@watson.ibm.com> Robin Cornelius wrote: > On Wed, Apr 2, 2008 at 4:03 PM, Thomas Grimshaw wrote: > >>Mike Monkowski wrote: >> >> >>>Soft wrote: >>> >>> >>>> ...and maybe it's all in my head, but audio >>>>seems downright horrible. >>>> >>> >>>Hmmm. On mine voice chat will keep running hours after the viewer crashes >> >>as if it were a completely different program. :-) Spooky. >> >>>Mike >>> >> >> Maybe because it *is* a completely different program! See slvoice Hence the ":-)" > Considering the viewer does crash, should slvoice check the viewer is > alive once in a while so it can auto terminate if it dies? and > shouldn't the voice session in some way be associated with logging in > world so if you are logged out the voice is also logged out? > > Robin And shouldn't SLVoice be open source so somebody can fix it? Mike From dale at daleglass.net Wed Apr 2 10:43:33 2008 From: dale at daleglass.net (Dale Glass) Date: Wed Apr 2 10:43:49 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: References: <47F2B5C3.70708@gmail.com> <47F3A053.9040803@streamsense.net> Message-ID: <200804021943.38008.dale@daleglass.net> On Wednesday 02 April 2008 17:08:51 Robin Cornelius wrote: > Considering the viewer does crash, should slvoice check the viewer is > alive once in a while so it can auto terminate if it dies? and > shouldn't the voice session in some way be associated with logging in > world so if you are logged out the voice is also logged out? Shouldn't that be pretty much automatic already? The viewer talks to SLVoice over a TCP connection. If the viewer dies, the connection will shutdown. I imagine SLVoice would shutdown as a result. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080402/6ef6d67a/attachment.pgp From josh at lindenlab.com Wed Apr 2 10:54:20 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Apr 2 10:54:27 2008 Subject: [sldev] H4 Upgrade: Will any Havok 1 sims be left? In-Reply-To: <47F3985E.7050505@gmail.com> References: <89ca6da00804020230q7b0e2f07me773085028f551b@mail.gmail.com> <47F3985E.7050505@gmail.com> Message-ID: <47F3C84C.6070203@lindenlab.com> Jason Giglio wrote: > Strife Onizuka wrote: > >> Try the beta grid. >> > > It would be good to have one H1 sim on the main grid for confirming > regressions. > We're planning to set up a handful of H1 simulators on the main grid for validating any reported regressions. However, these may not be publicly accessible at all times depending on what regions we bring up. These should be up by later this week - I'd like to get them online ASAP, but realistically it may be a day or two. Sidewinder Linden will be coordinating these, as you might guess, so send him an IM. For Dale's original request (regions to do H1 vs. H4 comparison videos) I echo Strife's comment that the Beta Grid will be the most convenient - it's already set up with several H1 regions. Joshua From monkowsk at watson.ibm.com Wed Apr 2 10:58:26 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 2 10:58:43 2008 Subject: SLVoice; was: [sldev] Viewer optimization patch. In-Reply-To: <200804021943.38008.dale@daleglass.net> References: <47F2B5C3.70708@gmail.com> <47F3A053.9040803@streamsense.net> <200804021943.38008.dale@daleglass.net> Message-ID: <47F3C942.2080402@watson.ibm.com> Dale Glass wrote: > The viewer talks to SLVoice over a TCP connection. If the viewer dies, the > connection will shutdown. I imagine SLVoice would shutdown as a result. SLVoice is the server, not the client. It just hangs around and listens for somebody to connect. It would be easy enough to shut down when a disconnect leaves zero clients, but it was apparently written in a hurry. Mike From kfa at gmx.net Wed Apr 2 11:02:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 2 11:02:09 2008 Subject: [sldev] Compiling In-Reply-To: <47F39E1E.3040806@watson.ibm.com> References: <47F36548.1090708@gmx.net> <47F39E1E.3040806@watson.ibm.com> Message-ID: <47F3CA1B.8070500@gmx.net> Mike Monkowski wrote: > > Why 1.18.5.3? Because it is the latest version for which a patched solution file from VWR-1151 is available. Is there another source where to find more current ones? I'd like to work on top of the latest production release, not RC or FL or beta. Have yet to learn how to get this to build on my own. > > Did you happen to see the build note on the source download page: "Win > VS2005: Use llmozlib-vc80.lib from RC-1.18.6.0"? Duh, I knew it was something very stupid. Read and forgot about this the same moment. Copied the lib, now the application builds. Thank you! Only thing, now it won't run. Had to copy a few more dll's from the newview directory into the ReleaseForDownload folder to have it start without complaining, but now it seems to get stuck there. Only the little 'Loading...' screen is up and gobbles all the CPU power from one core. That's all it does for several minutes until I decide to kill it in the task manager. Anyone else experienced this before and has a pointer what to try next? Apart from advising to clear the cache, the wiki ends there. Thanks + regards, Felix From loorni at gmail.com Wed Apr 2 11:20:19 2008 From: loorni at gmail.com (=?ISO-8859-1?Q?Lasse_=D6=F6rni?=) Date: Wed Apr 2 11:20:21 2008 Subject: [sldev] Compiling In-Reply-To: <47F3CA1B.8070500@gmx.net> References: <47F36548.1090708@gmx.net> <47F39E1E.3040806@watson.ibm.com> <47F3CA1B.8070500@gmx.net> Message-ID: <5e890b920804021120u74aed815ofd31e6d49b950273@mail.gmail.com> On Wed, Apr 2, 2008 at 9:02 PM, Felix Duesenburg wrote: > Only thing, now it won't run. Had to copy a few more dll's from the newview > directory into the ReleaseForDownload folder to have it start without > complaining, but now it seems to get stuck there. Only the little > 'Loading...' screen is up and gobbles all the CPU power from one core. > That's all it does for several minutes until I decide to kill it in the task > manager. Anyone else experienced this before and has a pointer what to try > next? Apart from advising to clear the cache, the wiki ends there. Hi, check if you have all the data files the viewer expects (app_settings, character, fonts, skins directories). Fonts are especially critical, because if they're not found, the viewer bombs with llerrs (fatal error) quite near the beginning, however in my experience this usually causes it to get stuck forever like you described. Also check what the logfile says (\Application Data\Second Life\logs\SecondLife.log) - Lasse / LudoCraft / realXtend project From kfa at gmx.net Wed Apr 2 14:34:00 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 2 14:34:06 2008 Subject: [sldev] Compiling In-Reply-To: <5e890b920804021120u74aed815ofd31e6d49b950273@mail.gmail.com> References: <47F36548.1090708@gmx.net> <47F39E1E.3040806@watson.ibm.com> <47F3CA1B.8070500@gmx.net> <5e890b920804021120u74aed815ofd31e6d49b950273@mail.gmail.com> Message-ID: <47F3FBC8.3020705@gmx.net> Lasse ??rni wrote: > Hi, > check if you have all the data files the viewer expects (app_settings, > character, fonts, skins directories). Fonts are especially critical, > because if they're not found, the viewer bombs with llerrs (fatal > error) quite near the beginning, however in my experience this usually > causes it to get stuck forever like you described. Also check what the > logfile says (\Application Data\Second > Life\logs\SecondLife.log) > > - Lasse / LudoCraft / realXtend project > Thanks for the help, got it working now! Let the hacking begin :) From carjay at gmx.net Wed Apr 2 17:39:18 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Apr 2 17:39:25 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? Message-ID: <47F42736.2030206@gmx.net> Hi, since my avatar is currently stuck in-world I wonder how a login is handled on the server side. By stuck I mean the system keeps telling on logon that "The system is logging you out right now. Your account will not be available until...". The avatar is also clearly visible in-world and appears logged on to friends until they send an IM at which point they are told the avatar is offline and message will be stored. Right after, the online status changes to offline in the viewer. It happened right after a teleport, the world was starting to appear and the client was still receiving updates and chat from people around it but at one point the updates for the world seemed to have stopped (part of it was already visible but some of the building structure was still missing). The weird thing is that chat and agent updates were still received but I was unable to move or teleport out (trying a neighbour region it would tell me: "Could not teleport. Problem encountered processing your teleport request. You may need to log back in before you can teleport" and trying to go somewhere else would show the teleport screen with updating progress bar but at some point later it would simply drop back to the client world view). I actually did not try to log back on for about 5 hours. I still have the viewer log from that session but I do not see anything unusual. Seems this is happening rarely as referenced in http://jira.secondlife.com/browse/SVC-604 Think there is nothing much to do on the client side but I find it intriguing that a condition exists where the server keeps the avatar logged in even though the network connection is no longer present. Regards, Carsten From tom at streamsense.net Wed Apr 2 17:41:35 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Apr 2 17:42:16 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F42736.2030206@gmx.net> References: <47F42736.2030206@gmx.net> Message-ID: <47F427BF.8030004@streamsense.net> Carsten Juttner wrote: > Hi, > > since my avatar is currently stuck in-world I wonder how a login is > handled on the server side. > > By stuck I mean the system keeps telling on logon that "The system is > logging you out right now. Your account will not be available > until...". The avatar is also clearly visible in-world and appears > logged on to friends until they send an IM at which point they are > told the avatar is offline and message will be stored. Right after, > the online status changes to offline in the viewer. When a user logs off, the simulator has to send all of the users' session data back to the grid, before the user can be acknowledged as offline. If you see "the system is logging you out right now", this is still in progress. Since second life has had major asset issues today.. (when doesn't it? *cough*).. it stands to reason that something on the sim may have stagnated. I would suggest adding a timeout to user logout, perhaps a jira? ~Tom From lenglish5 at cox.net Wed Apr 2 19:24:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Apr 2 19:24:19 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F427BF.8030004@streamsense.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> Message-ID: <47F43FD1.6040403@cox.net> Thomas Grimshaw wrote: > Carsten Juttner wrote: >> Hi, >> >> since my avatar is currently stuck in-world I wonder how a login is >> handled on the server side. >> >> By stuck I mean the system keeps telling on logon that "The system is >> logging you out right now. Your account will not be available >> until...". The avatar is also clearly visible in-world and appears >> logged on to friends until they send an IM at which point they are >> told the avatar is offline and message will be stored. Right after, >> the online status changes to offline in the viewer. > When a user logs off, the simulator has to send all of the users' > session data back to the grid, before the user can be acknowledged as > offline. If you see "the system is logging you out right now", this is > still in progress. > > Since second life has had major asset issues today.. (when doesn't > it? *cough*).. it stands to reason that something on the sim may have > stagnated. I would suggest adding a timeout to user logout, perhaps a > jira? An attempt to log in while your avie is already in world is supposed to log the current avie out of the system. Since that's not happening, I don't think a timeout will do the trick either. Lawson From matthew.dowd at hotmail.co.uk Thu Apr 3 00:59:44 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 3 00:59:46 2008 Subject: [sldev] "background sky" render pass, render pass sequence In-Reply-To: <2C960061-F24C-46C0-9CAE-1BEA4062B3BE@gmail.com> References: <09B46D92E70741878324BE6D8483CF81@cnk> <47F1D7AB.7080806@lindenlab.com> <39E20C09-2AFA-4B63-868C-2718A7F9DDB1@gmail.com> <47F280D8.1090305@lindenlab.com> <47F2BD9E.70803@lindenlab.com> <2C960061-F24C-46C0-9CAE-1BEA4062B3BE@gmail.com> Message-ID: >>On 2008-04-01, at 17:56, Dave Parks wrote: >> Argent Stonecutter wrote: >>> This was changed in February some time? Because that's when parcel >>> borders started glowing through solid objects. >> > >> That change was made so you could see property lines under water. > >That's what I suspected. Can we change that back - the result looks less like property lines being painted *on top* of everything and more like property lines are bleeding through solid objects which gives the impression that everything (including avatars) is slightly translucent, which is extremely disconcerting. There is also often quite a severe delay in the parcel name updating in the menu bar (I gathered from a blog that parcel details recently switched to using CAPs? which raises another question I asked recently, namely whether switching fom UDP to HTTP is causing a lot of the lag issues reported) - as such having parcel lines switched on is even more important in terms of knowing when you leave a parcel, but the translucency it causes wants me to immediately switch them off again! As Argent has reported in jira, the new water shaders also occlude a number of other things, so this change to the property lines rendering order is not really a fix (and many would argue - well have argued in jira - is actually a bug!). Matthew _________________________________________________________________ Amazing prizes every hour with Live Search Big Snap http://www.bigsnapsearch.com From ryan at 3di.jp Thu Apr 3 04:38:49 2008 From: ryan at 3di.jp (Ryan McDougall) Date: Thu Apr 3 04:39:05 2008 Subject: [sldev] Viewer optimization patch. In-Reply-To: <47F3A337.109@watson.ibm.com> Message-ID: <6825173.2531961207222729904.JavaMail.root@berkeley.lan> ----- "Mike Monkowski" wrote: > > And shouldn't SLVoice be open source so somebody can fix it? > > Mike Too bad there's nothing like that. :-) http://sourceforge.net/projects/voipforvw/ Cheers, From tom at streamsense.net Thu Apr 3 05:00:07 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 3 05:00:25 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F43FD1.6040403@cox.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> Message-ID: <47F4C6C7.6000904@streamsense.net> Lawson English wrote: > Thomas Grimshaw wrote: >> >> >> Since second life has had major asset issues today.. (when doesn't >> it? *cough*).. it stands to reason that something on the sim may have >> stagnated. I would suggest adding a timeout to user logout, perhaps a >> jira? > An attempt to log in while your avie is already in world is supposed > to log the current avie out of the system. Since that's not happening, > I don't think a timeout will do the trick either. This only applies if the system hasn't already initiated the logout process. The timeout I am referring to would be a timeout of the actual logout procedure. ~T From kaleajinkya at gmail.com Thu Apr 3 14:09:58 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Thu Apr 3 14:10:00 2008 Subject: [sldev] bison: extra operand `mv.exe' Message-ID: I am getting the following errors in vc8. I have checked the bison installation. But no success. 1>------ Build started: Project: lscript_compile_fb_vc8, Configuration: Release Win32 ------ 1>Building ytab.cpp 2>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 2>Project not selected to build for this solution configuration 1>bison: extra operand `mv.exe' 1>Try `bison --help' for more information. 1>Project : error PRJ0019: A tool returned an error code from "Building ytab.cpp" 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) 3>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 3>Executing pre-build batch file 3>PREBUILD SUCCESSFUL 3>Linking... 3>link: extra operand `/ERRORREPORT:PROMPT' 3>Try `link --help' for more information. 3>Project : error PRJ0002 : Error result 1 returned from 'C:\cygwin\bin\link.exe'. 3>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 3>newview - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 2 failed, 18 up-to-date, 1 skipped ========== Any suggestions ? -Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080403/b461e174/attachment.htm From marinekelley at gmail.com Thu Apr 3 14:19:54 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Thu Apr 3 14:20:00 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: References: Message-ID: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> Hi, I got the same error in the past, this is due to a problem in the command line. Open the lscript_compile_fb_vc8 project, right-click on the file indra.y and Properties. Mofify the compile command line : split it in two just before "mv.exe". Actually that command is not one one line but two consecutive lines, the CRLF was just crunched. Marine 2008/4/3, Ajinkya Kale : > > I am getting the following errors in vc8. I have checked the bison > installation. But no success. > > > 1>------ Build started: Project: lscript_compile_fb_vc8, Configuration: > Release Win32 ------ > 1>Building ytab.cpp > 2>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 2>Project not selected to build for this solution configuration > 1>bison: extra operand `mv.exe' > 1>Try `bison --help' for more information. > 1>Project : error PRJ0019: A tool returned an error code from "Building > ytab.cpp" > 1>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > 3>------ Build started: Project: newview, Configuration: ReleaseNoOpt > Win32 ------ > 3>Executing pre-build batch file > 3>PREBUILD SUCCESSFUL > 3>Linking... > 3>link: extra operand `/ERRORREPORT:PROMPT' > 3>Try `link --help' for more information. > 3>Project : error PRJ0002 : Error result 1 returned from > 'C:\cygwin\bin\link.exe'. > 3>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 3>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 2 failed, 18 up-to-date, 1 skipped > ========== > > Any suggestions ? > > -Ajinkya > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080403/2532ea48/attachment.htm From lenglish5 at cox.net Thu Apr 3 15:34:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Apr 3 15:34:46 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F4C6C7.6000904@streamsense.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> Message-ID: <47F55B83.1040109@cox.net> Thomas Grimshaw wrote: > Lawson English wrote: >> Thomas Grimshaw wrote: >>> >>> >>> Since second life has had major asset issues today.. (when doesn't >>> it? *cough*).. it stands to reason that something on the sim may >>> have stagnated. I would suggest adding a timeout to user logout, >>> perhaps a jira? >> An attempt to log in while your avie is already in world is supposed >> to log the current avie out of the system. Since that's not >> happening, I don't think a timeout will do the trick either. > This only applies if the system hasn't already initiated the logout > process. The timeout I am referring to would be a timeout of the > actual logout procedure. > > ~T > > I know, but if the system doesn't respond to the second login attempt by completing the logout, then a timer to trigger completing the logout probably won't work all the way through the system either since it would use the same communications protocols to finish the logout. The whole idea of the asynchronous logout is to allow all the parts of the system to finish bookkeeping. You can't simply stop that process in its tracks without risking even more issues with various parts of the server system being de-synched from each other or so I would expect. Lawson From tom at streamsense.net Thu Apr 3 15:37:26 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 3 15:37:35 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F55B83.1040109@cox.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> Message-ID: <47F55C26.2080304@streamsense.net> Lawson English wrote: > Thomas Grimshaw wrote: >> Lawson English wrote: >>> An attempt to log in while your avie is already in world is supposed >>> to log the current avie out of the system. Since that's not >>> happening, I don't think a timeout will do the trick either. >> This only applies if the system hasn't already initiated the logout >> process. The timeout I am referring to would be a timeout of the >> actual logout procedure. >> >> ~T >> >> > You can't simply stop that process in its tracks without risking even > more issues with various parts of the server system being de-synched > from each other or so I would expect. Granted, but given that the OPs avatar was stuck "logging out" for five hours, it seems that some sort of timeout is sensible.. i mean if the sim hasn't finished "book keeping" within 30 mins, i think it's safe to assume that it's never gonna finish ~T From secret.argent at gmail.com Thu Apr 3 16:07:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Apr 3 16:08:20 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F55B83.1040109@cox.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> Message-ID: On 2008-04-03, at 17:34, Lawson English wrote: > I know, but if the system doesn't respond to the second login > attempt by completing the logout, then a timer to trigger > completing the logout probably won't work all the way through the > system either since it would use the same communications protocols > to finish the logout. Perhaps, and yet sending an instant message can often force the process to complete. From tom at streamsense.net Thu Apr 3 16:09:25 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 3 16:09:35 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> Message-ID: <47F563A5.705@streamsense.net> Argent Stonecutter wrote: > On 2008-04-03, at 17:34, Lawson English wrote: >> I know, but if the system doesn't respond to the second login attempt >> by completing the logout, then a timer to trigger completing the >> logout probably won't work all the way through the system either >> since it would use the same communications protocols to finish the >> logout. > > Perhaps, and yet sending an instant message can often force the > process to complete. That will only show the user as offline to the person who sent the IM. ~T From secret.argent at gmail.com Thu Apr 3 16:38:48 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Apr 3 16:38:57 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F563A5.705@streamsense.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> <47F563A5.705@streamsense.net> Message-ID: <7DF59956-F06E-407D-8FCA-5527525A7714@gmail.com> On 2008-04-03, at 18:09, Thomas Grimshaw wrote: > Argent Stonecutter wrote: >> On 2008-04-03, at 17:34, Lawson English wrote: >>> I know, but if the system doesn't respond to the second login >>> attempt by completing the logout, then a timer to trigger >>> completing the logout probably won't work all the way through the >>> system either since it would use the same communications >>> protocols to finish the logout. >> >> Perhaps, and yet sending an instant message can often force the >> process to complete. > That will only show the user as offline to the person who sent the IM. This is a regular workaround I use when I am "hung" and unable to log in. Log in as an alt, send an IM, and try again, and it works. I've only had one time that sending an IM failed, and on that case it *didn't* show me as offline... every time it's shown me as offline, that's completed the logout. From carjay at gmx.net Thu Apr 3 17:58:55 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Apr 3 17:58:57 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <7DF59956-F06E-407D-8FCA-5527525A7714@gmail.com> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> <47F563A5.705@streamsense.net> <7DF59956-F06E-407D-8FCA-5527525A7714@gmail.com> Message-ID: <47F57D4F.70002@gmx.net> SimArgent Stonecutter wrote: > This is a regular workaround I use when I am "hung" and unable to log > in. Log in as an alt, send an IM, and try again, and it works. I've > only had one time that sending an IM failed, and on that case it > *didn't* show me as offline... every time it's shown me as offline, > that's completed the logout. As I already mentioned in the original mail that didn't work in my case. I appeared offline to the friend instantly after the IM was sent, but on relog I again appeared as online in that person's friend list (and in-world) and I was still unable to log back in. I don't know what fixed it finally but I was able to relog this evening. I think maybe the sim was restarted but I am not sure. I closed the support ticket which was not processed yet so there probably was no Linden involvement. I wonder where the presence data is stored, probably globally on one central server and it is then updated by each sim I connect to? But in that case a crashed sim would also cause everyone on it to be unable to relog at least unless that sim restarted (at which point it would sync with the global server). But then again I have witnessed sims not coming right back for several minutes while I was able to relog. So I assume that the sim kept telling the central presence server that the avatar is still online and connected to it (which fits since I was also visible to everybody in that sim). In this case it is only strange that the IM subsystem obviously assumes right away that the avatar is offline but the rest of the sim stubbornly refuses to give up on the avatar. :) Regards, Carsten From rdw at lindenlab.com Thu Apr 3 18:26:07 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Apr 3 18:26:16 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F57D4F.70002@gmx.net> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> <47F563A5.705@streamsense.net> <7DF59956-F06E-407D-8FCA-5527525A7714@gmail.com> <47F57D4F.70002@gmx.net> Message-ID: <47F583AF.8030509@lindenlab.com> Carsten Juttner wrote: > SimArgent Stonecutter wrote: >> This is a regular workaround I use when I am "hung" and unable to log >> in. Log in as an alt, send an IM, and try again, and it works. I've >> only had one time that sending an IM failed, and on that case it >> *didn't* show me as offline... every time it's shown me as offline, >> that's completed the logout. > > As I already mentioned in the original mail that didn't work in my case. > I appeared offline to the friend instantly after the IM was sent, but on > relog I again appeared as online in that person's friend list (and > in-world) and I was still unable to log back in. > > I don't know what fixed it finally but I was able to relog this evening. > I think maybe the sim was restarted but I am not sure. I closed the > support ticket which was not processed yet so there probably was no > Linden involvement. > > I wonder where the presence data is stored, probably globally on one > central server and it is then updated by each sim I connect to? > > But in that case a crashed sim would also cause everyone on it to be > unable to relog at least unless that sim restarted (at which point it > would sync with the global server). But then again I have witnessed sims > not coming right back for several minutes while I was able to relog. > > So I assume that the sim kept telling the central presence server that > the avatar is still online and connected to it (which fits since I was > also visible to everybody in that sim). I believe this is pretty much how it works (not an expert though). > In this case it is only strange that the IM subsystem obviously assumes > right away that the avatar is offline but the rest of the sim stubbornly > refuses to give up on the avatar. :) I think the sim sets the avatar's presence to a special state indicating that it's uploading its assets prior to logging off. Different systems interpret this state differently (IM treats it as offline, login refuses login, etc). -RYaN From kaleajinkya at gmail.com Thu Apr 3 21:46:19 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Thu Apr 3 21:46:49 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> Message-ID: Thanks. That worked. The bison error was solved by separating the command line argument. But now I am getting the following error : 1>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 2>Executing pre-build batch file 2>PREBUILD SUCCESSFUL 2>Linking... 2>LINK : fatal error LNK1104: cannot open file 'llimagej2coj.lib' 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 2>newview - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped ========== The Project llimagej2coj was not loaded when i started the vc8 solution. Visual studio prompted cannot load...missing project. The downloaded version _1-19-0 didnot have this project ? Do i need the llimagej2coj project ? Where can i download it?Or i donnot require it? On Thu, Apr 3, 2008 at 2:19 PM, Marine Kelley wrote: > Hi, I got the same error in the past, this is due to a problem in the > command line. > Open the lscript_compile_fb_vc8 project, right-click on the file indra.y > and Properties. Mofify the compile command line : split it in two just > before "mv.exe". Actually that command is not one one line but two > consecutive lines, the CRLF was just crunched. > > Marine > > > > 2008/4/3, Ajinkya Kale : > > > > I am getting the following errors in vc8. I have checked the bison > > installation. But no success. > > > > > > 1>------ Build started: Project: lscript_compile_fb_vc8, Configuration: > > Release Win32 ------ > > 1>Building ytab.cpp > > 2>------ Skipped Build: Project: win_crash_logger, Configuration: > > ReleaseNoOpt Win32 ------ > > 2>Project not selected to build for this solution configuration > > 1>bison: extra operand `mv.exe' > > 1>Try `bison --help' for more information. > > 1>Project : error PRJ0019: A tool returned an error code from "Building > > ytab.cpp" > > 1>Build log was saved at "file://h:\SL Open source > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > 3>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > Win32 ------ > > 3>Executing pre-build batch file > > 3>PREBUILD SUCCESSFUL > > 3>Linking... > > 3>link: extra operand `/ERRORREPORT:PROMPT' > > 3>Try `link --help' for more information. > > 3>Project : error PRJ0002 : Error result 1 returned from > > 'C:\cygwin\bin\link.exe'. > > 3>Build log was saved at "file://h:\SL Open source > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > 3>newview - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 2 failed, 18 up-to-date, 1 skipped > > ========== > > > > Any suggestions ? > > > > -Ajinkya > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080403/d03f74a4/attachment.htm From marinekelley at gmail.com Fri Apr 4 00:41:48 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Apr 4 00:41:51 2008 Subject: [sldev] Missing files in 1.19.1.4 + crash when uploading a texture Message-ID: <9e52a8c10804040041w5da34382g74dfa2ef5774765e@mail.gmail.com> Hi, I have tried to compile in a rush yesterday, following the latest 1.19.1 release of the viewer. It seems that openssl is missing from the includes, one has to copy that directory from an older version of the source code and it seems to work pretty much alright. Symptom : '#include openssl/crypto.h' fails in 'llcurl.cpp' contained inside project llmessage. But I'm experiencing a more serious bug : whenever I try to upload textures from 1.19.0 and 1.19.1, the viewer crashes to desktop. It seems to be caused by a problem in the rendering of triangles (even if you're not trying to preview a sculpty). Has anybody else experienced that ? No need to actually pay for the upload, the crash occurs at preview. Thanks Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/fd8380b8/attachment.htm From gigstaggart at gmail.com Fri Apr 4 03:44:42 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Apr 4 03:44:45 2008 Subject: [sldev] Missing files in 1.19.1.4 + crash when uploading a texture In-Reply-To: <9e52a8c10804040041w5da34382g74dfa2ef5774765e@mail.gmail.com> References: <9e52a8c10804040041w5da34382g74dfa2ef5774765e@mail.gmail.com> Message-ID: <47F6069A.90809@gmail.com> Marine Kelley wrote: > But I'm experiencing a more serious bug : whenever I try to upload > textures from 1.19.0 and 1.19.1, the viewer crashes to desktop. It seems > to be caused by a problem in the rendering of triangles (even if you're > not trying to preview a sculpty). Has anybody else experienced that ? No > need to actually pay for the upload, the crash occurs at preview. Coco Linden reported finding a similar behavior in an internal branch. There's also this, which is probably unrelated: http://jira.secondlife.com/browse/VWR-4022 -Jason From robin.cornelius at gmail.com Fri Apr 4 03:48:39 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Apr 4 03:48:43 2008 Subject: [sldev] Missing files in 1.19.1.4 + crash when uploading a texture In-Reply-To: <47F6069A.90809@gmail.com> References: <9e52a8c10804040041w5da34382g74dfa2ef5774765e@mail.gmail.com> <47F6069A.90809@gmail.com> Message-ID: On Fri, Apr 4, 2008 at 11:44 AM, Jason Giglio wrote: > Marine Kelley wrote: > > But I'm experiencing a more serious bug : whenever I try to upload > > textures from 1.19.0 and 1.19.1, the viewer crashes to desktop. It seems > Coco Linden reported finding a similar behavior in an internal branch. > > There's also this, which is probably unrelated: > http://jira.secondlife.com/browse/VWR-4022 4022 specifically deals with libjpeg6b balking and is always associated with an error message from libjpeg6b in the logs. This does indeed sound different. Robin From tom at streamsense.net Fri Apr 4 05:27:25 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri Apr 4 05:27:36 2008 Subject: [sldev] why can an avatar get stuck (unable to log back in and not getting logged out)? In-Reply-To: <47F583AF.8030509@lindenlab.com> References: <47F42736.2030206@gmx.net> <47F427BF.8030004@streamsense.net> <47F43FD1.6040403@cox.net> <47F4C6C7.6000904@streamsense.net> <47F55B83.1040109@cox.net> <47F563A5.705@streamsense.net> <7DF59956-F06E-407D-8FCA-5527525A7714@gmail.com> <47F57D4F.70002@gmx.net> <47F583AF.8030509@lindenlab.com> Message-ID: <47F61EAD.8040600@streamsense.net> Has something significant changed with texture animations? I'm noticing a prim with an animated texture script is causing an abnormal amount of sim lag, this could be fatal to sims which rely heavily on this feature (rezzable sims?) Cheers ~T From kaleajinkya at gmail.com Fri Apr 4 06:32:44 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 4 06:32:48 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> Message-ID: Renaming "llimagej2coj.vcproj" to "llimagej2coj_vc8.vcproj" resolved the error of llimagej2coj.lib. (Thanks a lot Marine for your valuable inputs) Now I am getting a "cannot open file 'EZ_LCD_Wrapper_vc8.lib' " error. 1>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 2>Executing pre-build batch file 2>PREBUILD SUCCESSFUL 2>Linking... 2>LINK : fatal error LNK1104: cannot open file 'EZ_LCD_Wrapper_vc8.lib' 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 2>newview - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped ========== On Thu, Apr 3, 2008 at 9:46 PM, Ajinkya Kale wrote: > Thanks. That worked. The bison error was solved by separating the command > line argument. > But now I am getting the following error : > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>LINK : fatal error LNK1104: cannot open file 'llimagej2coj.lib' > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped > ========== > > The Project llimagej2coj was not loaded when i started the vc8 solution. > Visual studio prompted cannot load...missing project. > The downloaded version _1-19-0 didnot have this project ? Do i need the > llimagej2coj project ? Where can i download it?Or i donnot require it? > > > On Thu, Apr 3, 2008 at 2:19 PM, Marine Kelley > wrote: > > > Hi, I got the same error in the past, this is due to a problem in the > > command line. > > Open the lscript_compile_fb_vc8 project, right-click on the file indra.y > > and Properties. Mofify the compile command line : split it in two just > > before "mv.exe". Actually that command is not one one line but two > > consecutive lines, the CRLF was just crunched. > > > > Marine > > > > > > > > 2008/4/3, Ajinkya Kale : > > > > > > I am getting the following errors in vc8. I have checked the bison > > > installation. But no success. > > > > > > > > > 1>------ Build started: Project: lscript_compile_fb_vc8, > > > Configuration: Release Win32 ------ > > > 1>Building ytab.cpp > > > 2>------ Skipped Build: Project: win_crash_logger, Configuration: > > > ReleaseNoOpt Win32 ------ > > > 2>Project not selected to build for this solution configuration > > > 1>bison: extra operand `mv.exe' > > > 1>Try `bison --help' for more information. > > > 1>Project : error PRJ0019: A tool returned an error code from > > > "Building ytab.cpp" > > > 1>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > 3>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > > Win32 ------ > > > 3>Executing pre-build batch file > > > 3>PREBUILD SUCCESSFUL > > > 3>Linking... > > > 3>link: extra operand `/ERRORREPORT:PROMPT' > > > 3>Try `link --help' for more information. > > > 3>Project : error PRJ0002 : Error result 1 returned from > > > 'C:\cygwin\bin\link.exe'. > > > 3>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > > 3>newview - 1 error(s), 0 warning(s) > > > ========== Build: 0 succeeded, 2 failed, 18 up-to-date, 1 skipped > > > ========== > > > > > > Any suggestions ? > > > > > > -Ajinkya > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > -- > Ciao, > Ajinkya -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/31d78006/attachment-0001.htm From marinekelley at gmail.com Fri Apr 4 06:45:45 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Apr 4 06:45:49 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> Message-ID: <9e52a8c10804040645v1c1fa6coac4a467ca5511a1d@mail.gmail.com> same same, rename EZ_LCD_Wrapper.lib to EZ_LCD_Wrapper_vc8.lib in both debug and release libraries folders and you're all set. Normally you should be all good after that ultimate renaming. Marine (reposting this to the list as I have the bad habit of clickining "Reply" instead of "Reply to all") 2008/4/4, Ajinkya Kale : > > > Renaming "llimagej2coj.vcproj" to "llimagej2coj_vc8.vcproj" resolved the > error of llimagej2coj.lib. (Thanks a lot Marine for your valuable inputs) > > Now I am getting a "cannot open file 'EZ_LCD_Wrapper_vc8.lib' " error. > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>LINK : fatal error LNK1104: cannot open file 'EZ_LCD_Wrapper_vc8.lib' > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped > ========== > > > On Thu, Apr 3, 2008 at 9:46 PM, Ajinkya Kale > wrote: > > > Thanks. That worked. The bison error was solved by separating the > > command line argument. > > But now I am getting the following error : > > > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > > ReleaseNoOpt Win32 ------ > > 1>Project not selected to build for this solution configuration > > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > Win32 ------ > > 2>Executing pre-build batch file > > 2>PREBUILD SUCCESSFUL > > 2>Linking... > > 2>LINK : fatal error LNK1104: cannot open file 'llimagej2coj.lib' > > 2>Build log was saved at "file://h:\SL Open source > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > 2>newview - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped > > ========== > > > > The Project llimagej2coj was not loaded when i started the vc8 solution. > > Visual studio prompted cannot load...missing project. > > The downloaded version _1-19-0 didnot have this project ? Do i need the > > llimagej2coj project ? Where can i download it?Or i donnot require it? > > > > > > On Thu, Apr 3, 2008 at 2:19 PM, Marine Kelley > > wrote: > > > > > Hi, I got the same error in the past, this is due to a problem in the > > > command line. > > > Open the lscript_compile_fb_vc8 project, right-click on the file > > > indra.y and Properties. Mofify the compile command line : split it in two > > > just before "mv.exe". Actually that command is not one one line but two > > > consecutive lines, the CRLF was just crunched. > > > > > > Marine > > > > > > > > > > > > 2008/4/3, Ajinkya Kale : > > > > > > > > I am getting the following errors in vc8. I have checked the bison > > > > installation. But no success. > > > > > > > > > > > > 1>------ Build started: Project: lscript_compile_fb_vc8, > > > > Configuration: Release Win32 ------ > > > > 1>Building ytab.cpp > > > > 2>------ Skipped Build: Project: win_crash_logger, Configuration: > > > > ReleaseNoOpt Win32 ------ > > > > 2>Project not selected to build for this solution configuration > > > > 1>bison: extra operand `mv.exe' > > > > 1>Try `bison --help' for more information. > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > "Building ytab.cpp" > > > > 1>Build log was saved at "file://h:\SL Open source > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > 3>------ Build started: Project: newview, Configuration: > > > > ReleaseNoOpt Win32 ------ > > > > 3>Executing pre-build batch file > > > > 3>PREBUILD SUCCESSFUL > > > > 3>Linking... > > > > 3>link: extra operand `/ERRORREPORT:PROMPT' > > > > 3>Try `link --help' for more information. > > > > 3>Project : error PRJ0002 : Error result 1 returned from > > > > 'C:\cygwin\bin\link.exe'. > > > > 3>Build log was saved at "file://h:\SL Open source > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > > > 3>newview - 1 error(s), 0 warning(s) > > > > ========== Build: 0 succeeded, 2 failed, 18 up-to-date, 1 skipped > > > > ========== > > > > > > > > Any suggestions ? > > > > > > > > -Ajinkya > > > > > > > > > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > -- > > Ciao, > > Ajinkya > > > > > -- > Ciao, > Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/2da85635/attachment.htm From kaleajinkya at gmail.com Fri Apr 4 06:57:51 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 4 06:57:57 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: <9e52a8c10804040644g1391841ase383982443631907@mail.gmail.com> References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> <9e52a8c10804040644g1391841ase383982443631907@mail.gmail.com> Message-ID: Unfortunately some more errors :( The EZ_LCD_Wrapper_vc8.lib problem was solved. Thanks a lot for your help !! I have the following errors right now : 1>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 2>Executing pre-build batch file 2>PREBUILD SUCCESSFUL 2>Linking... 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved externals 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 2>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped ========== I found some info on the forum regarding this. But it was of no help. -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/33edf627/attachment.htm From marinekelley at gmail.com Fri Apr 4 07:06:38 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Fri Apr 4 07:06:42 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> <9e52a8c10804040644g1391841ase383982443631907@mail.gmail.com> Message-ID: <9e52a8c10804040706x527843b7w818f7a2b419192df@mail.gmail.com> Perhaps the lscript_compile project is not loaded... In any case try to choose the ReleaseForDownload target, I'm not sure ReleaseNoOpt even works. 2008/4/4, Ajinkya Kale : > > Unfortunately some more errors :( > The EZ_LCD_Wrapper_vc8.lib problem was solved. Thanks a lot for your help > !! > > I have the following errors right now : > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void > __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const > &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved > externals > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 3 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped > ========== > > I found some info on the forum regarding this. But it was of no help. > > > -- > Ciao, > Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/4356e75d/attachment.htm From kaleajinkya at gmail.com Fri Apr 4 07:45:56 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 4 07:46:00 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: <9e52a8c10804040706x527843b7w818f7a2b419192df@mail.gmail.com> References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> <9e52a8c10804040644g1391841ase383982443631907@mail.gmail.com> <9e52a8c10804040706x527843b7w818f7a2b419192df@mail.gmail.com> Message-ID: On Fri, Apr 4, 2008 at 7:06 AM, Marine Kelley wrote: > Perhaps the lscript_compile project is not loaded... In any case try to > choose the ReleaseForDownload target, I'm not sure ReleaseNoOpt even works. The lscript_compile project is loaded. Any other suggestions for the errors : 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/ced89bab/attachment-0001.htm From kaleajinkya at gmail.com Fri Apr 4 08:13:35 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 4 08:13:41 2008 Subject: [sldev] Different errors for different solution configurations Message-ID: *For ReleaseNoOpt i am getting the following errors :* 1>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 2>Executing pre-build batch file 2>PREBUILD SUCCESSFUL 2>Linking... 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved externals 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 2>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped ========== * And for ReleaseForDownload I am getting the following errors :* 1>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 1>Executing pre-build batch file 1>PREBUILD SUCCESSFUL 1>Linking... 1>LINK : fatal error LNK1181: cannot open input file 'llimagej2coj.lib' 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 1>newview - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== *Any suggestions to solve these ?* * What is the reason for the difference in the errors ?* -- Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/2c38281a/attachment.htm From kfa at gmx.net Fri Apr 4 09:09:05 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 4 09:09:17 2008 Subject: [sldev] bison: extra operand `mv.exe' In-Reply-To: <9e52a8c10804040645v1c1fa6coac4a467ca5511a1d@mail.gmail.com> References: <9e52a8c10804031419l6b78405k9221952064a614de@mail.gmail.com> <9e52a8c10804040645v1c1fa6coac4a467ca5511a1d@mail.gmail.com> Message-ID: <47F652A1.8040201@gmx.net> I just posted a patch for the solution files to VWR-1151 that compiles for me. Cheers Marine Kelley wrote: > same same, rename EZ_LCD_Wrapper.lib to EZ_LCD_Wrapper_vc8.lib in both > debug and release libraries folders and you're all set. > > Normally you should be all good after that ultimate renaming. > > Marine (reposting this to the list as I have the bad habit of > clickining "Reply" instead of "Reply to all") > > > 2008/4/4, Ajinkya Kale >: > > > Renaming "llimagej2coj.vcproj" to "llimagej2coj_vc8.vcproj" > resolved the error of llimagej2coj.lib. (Thanks a lot Marine for > your valuable inputs) > > Now I am getting a "cannot open file 'EZ_LCD_Wrapper_vc8.lib' " > error. > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: > ReleaseNoOpt Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>LINK : fatal error LNK1104: cannot open file > 'EZ_LCD_Wrapper_vc8.lib' > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 skipped > ========== > > > On Thu, Apr 3, 2008 at 9:46 PM, Ajinkya Kale > > wrote: > > Thanks. That worked. The bison error was solved by separating > the command line argument. > But now I am getting the following error : > > > 1>------ Skipped Build: Project: win_crash_logger, > Configuration: ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: > ReleaseNoOpt Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>LINK : fatal error LNK1104: cannot open file 'llimagej2coj.lib' > > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 19 up-to-date, 1 > skipped ========== > > The Project llimagej2coj was not loaded when i started the vc8 > solution. Visual studio prompted cannot load...missing project. > The downloaded version _1-19-0 didnot have this project ? Do i > need the llimagej2coj project ? Where can i download it?Or i > donnot require it? > > > On Thu, Apr 3, 2008 at 2:19 PM, Marine Kelley > > wrote: > > Hi, I got the same error in the past, this is due to a > problem in the command line. > Open the lscript_compile_fb_vc8 project, right-click on > the file indra.y and Properties. Mofify the compile > command line : split it in two just before "mv.exe". > Actually that command is not one one line but two > consecutive lines, the CRLF was just crunched. > > Marine > > > > 2008/4/3, Ajinkya Kale >: > > I am getting the following errors in vc8. I have > checked the bison installation. But no success. > > > 1>------ Build started: Project: > lscript_compile_fb_vc8, Configuration: Release Win32 > ------ > 1>Building ytab.cpp > 2>------ Skipped Build: Project: win_crash_logger, > Configuration: ReleaseNoOpt Win32 ------ > 2>Project not selected to build for this solution > configuration > 1>bison: extra operand `mv.exe' > 1>Try `bison --help' for more information. > 1>Project : error PRJ0019: A tool returned an error > code from "Building ytab.cpp" > 1>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > 3>------ Build started: Project: newview, > Configuration: ReleaseNoOpt Win32 ------ > 3>Executing pre-build batch file > 3>PREBUILD SUCCESSFUL > 3>Linking... > 3>link: extra operand `/ERRORREPORT:PROMPT' > 3>Try `link --help' for more information. > 3>Project : error PRJ0002 : Error result 1 returned > from 'C:\cygwin\bin\link.exe'. > 3>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 3>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 2 failed, 18 > up-to-date, 1 skipped ========== > > Any suggestions ? > > -Ajinkya > > > _______________________________________________ > Click here to unsubscribe or manage your list > subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > Ciao, > Ajinkya > > > > > -- > Ciao, > Ajinkya > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Fri Apr 4 13:31:55 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 4 13:31:58 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) Message-ID: <47F6903B.70305@cox.net> Thus far I'm the only one whom I can find who has this issue so I haven't submitted a jira for it, but its 100% reproducable: With the new 1.19.1(4) viewer, I see a "walking in place" effect for a few seconds in every zone when I start walking after standing for a while. This effect wasn't present on the old RC of the same version number. Any ideas? Lawson From monkowsk at watson.ibm.com Fri Apr 4 14:42:11 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Apr 4 14:42:23 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6903B.70305@cox.net> References: <47F6903B.70305@cox.net> Message-ID: <47F6A0B3.4@watson.ibm.com> I just downloaded 1.19.1.4 and I see some strange walking behaviour too: some backtracking, some rapid walking in place at times. I'm guessing it's the server, though. The Lag Meter shows red for the Server, "server framerate below 20" at times. My avatar shakes when it stops turning too. Is that why it's called Havok? Mike Lawson English wrote: > Thus far I'm the only one whom I can find who has this issue so I > haven't submitted a jira for it, but its 100% reproducable: > > With the new 1.19.1(4) viewer, I see a "walking in place" effect for a > few seconds in every zone when I start walking after standing for a while. > > This effect wasn't present on the old RC of the same version number. > > > Any ideas? From lenglish5 at cox.net Fri Apr 4 15:00:41 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 4 15:00:44 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6A0B3.4@watson.ibm.com> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> Message-ID: <47F6A509.1030001@cox.net> Mike Monkowski wrote: > I just downloaded 1.19.1.4 and I see some strange walking behaviour > too: some backtracking, some rapid walking in place at times. I'm > guessing it's the server, though. The Lag Meter shows red for the > Server, "server framerate below 20" at times. My avatar shakes when > it stops turning too. Is that why it's called Havok? Thing is, the 1.19.1(4) RC viewer does NOT show this behavior. I can bounce back and forth between them in any sim and turn the behavior on and off dependig on which viewer I'm using: RC 1.19.1(4) or R 1.19.1(4). IF there are no code changes between RC and release, this shouldn't happen (unless there's some REALLY strange bug in the XML-handling code or something since there are changes in dialog boxes and the like). Lawson From monkowsk at watson.ibm.com Fri Apr 4 17:08:58 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Apr 4 17:09:05 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6A509.1030001@cox.net> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> Message-ID: <47F6C31A.9070206@watson.ibm.com> Lawson English wrote: > Thing is, the 1.19.1(4) RC viewer does NOT show this behavior. I can > bounce back and forth between them in any sim and turn the behavior on > and off dependig on which viewer I'm using: RC 1.19.1(4) or R 1.19.1(4). I don't have an RC installed at the moment, so I'm not sure, but I think they use different settings files. Documents and Settings\...\application data\SecondLife\user_settings\ You might have a look there. Mike From dahliatrimble at gmail.com Fri Apr 4 17:09:32 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Apr 4 17:09:34 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6A509.1030001@cox.net> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> Message-ID: I've *heard* (means I'm not sure) that the latest RC used all CAPS and no UDP. If this is the case, walking might appear somewhat differently if there were some network lag as the packets can get stuck in a buffer somewhere waiting to be delivered, and not discarded as they might be with UDP. Anyone else with a better understanding care to comment? -Dahlia On Fri, Apr 4, 2008 at 3:00 PM, Lawson English wrote: > Mike Monkowski wrote: > > > I just downloaded 1.19.1.4 and I see some strange walking behaviour too: > > some backtracking, some rapid walking in place at times. I'm guessing it's > > the server, though. The Lag Meter shows red for the Server, "server > > framerate below 20" at times. My avatar shakes when it stops turning too. > > Is that why it's called Havok? > > > Thing is, the 1.19.1(4) RC viewer does NOT show this behavior. I can > bounce back and forth between them in any sim and turn the behavior on and > off dependig on which viewer I'm using: RC 1.19.1(4) or R 1.19.1(4). > > > IF there are no code changes between RC and release, this shouldn't happen > (unless there's some REALLY strange bug in the XML-handling code or > something since there are changes in dialog boxes and the like). > > > > Lawson > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/bb362892/attachment.htm From robla at lindenlab.com Fri Apr 4 17:11:37 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Apr 4 17:11:40 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6A509.1030001@cox.net> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> Message-ID: <47F6C3B9.1000405@lindenlab.com> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080404/368b7afc/signature.pgp From lenglish5 at cox.net Fri Apr 4 17:18:06 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 4 17:18:17 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6C3B9.1000405@lindenlab.com> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> <47F6C3B9.1000405@lindenlab.com> Message-ID: <47F6C53E.4070805@cox.net> Rob Lanphier wrote: > On 4/4/08 3:00 PM, Lawson English wrote: >> Mike Monkowski wrote: >>> I just downloaded 1.19.1.4 and I see some strange walking behaviour >>> too: some backtracking, some rapid walking in place at times. I'm >>> guessing it's the server, though. The Lag Meter shows red for the >>> Server, "server framerate below 20" at times. My avatar shakes when >>> it stops turning too. Is that why it's called Havok? >> Thing is, the 1.19.1(4) RC viewer does NOT show this behavior. I can >> bounce back and forth between them in any sim and turn the behavior >> on and off dependig on which viewer I'm using: RC 1.19.1(4) or R >> 1.19.1(4). >> >> >> IF there are no code changes between RC and release, this shouldn't >> happen (unless there's some REALLY strange bug in the XML-handling >> code or something since there are changes in dialog boxes and the like). > > There was one change that slipped in between RC and final release, > which I've attached as a patch here. It seems extremely unlikely that > the attached patch would have anything to do with this behavior. > > Is anyone else able to get similar results? Lawson, I'd recommend > filing this in JIRA. > > Rob Thanks Rob. I've been asking around and no-one else seems to notice a definite change between RC and R, so I suspect Dahlia's correct: the two are probably using different settings files. If I can't get rid of it by fiddling with preferences, I'll definitely file it since its annoying. I can "moonwalk" for up to 10-15 seconds in some sims and suddenly jump ahead the distance I should have walked during that time when using the release viewer, and walk normally in the same sim in the same spot with the RC. Lawson From kaleajinkya at gmail.com Fri Apr 4 22:18:29 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 4 22:18:35 2008 Subject: [sldev] unresolved external symbols Message-ID: Any suggestions for the following : 1>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 1>Executing pre-build batch file 1>PREBUILD SUCCESSFUL 1>Linking... 1>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 1>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) 1>ReleaseForDownload/SecondLife.exe : fatal error LNK1120: 1 unresolved externals 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 1>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080404/05975355/attachment-0001.htm From soft at lindenlab.com Sat Apr 5 10:03:21 2008 From: soft at lindenlab.com (Soft) Date: Sat Apr 5 10:03:23 2008 Subject: [sldev] 1.19.1 release source Message-ID: A few people have pinged about 1.19.1 source. I'm currently unable to publish to svn.secondlife.com - I'll get updates out when that's resolved. In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except for some version strings. RC4 source will generate a functionally identical binary. 1.20 pre-RC, including Dazzle, will appear shortly as well. From sldev at free.fr Sat Apr 5 11:30:12 2008 From: sldev at free.fr (Henri Beauchamp) Date: Sat Apr 5 11:31:15 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: <20080405203012.4ad3b0a0.sldev@free.fr> On Sat, 5 Apr 2008 12:03:21 -0500, Soft wrote: > A few people have pinged about 1.19.1 source. > > I'm currently unable to publish to svn.secondlife.com - I'll get > updates out when that's resolved. Good, thanks. > In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except > for some version strings. RC4 source will generate a functionally > identical binary. Not if we take into account Rob's message to this list. Citation: "There was one change that slipped in between RC and final release" And obviously, it's a potential crash fix: - delete iter->second->data; - delete iter->second; + if(iter->second != NULL) + { + delete iter->second->data; + delete iter->second; + } So it is not a neglectable change ! Question: why the guy (or gal) in charge for compiling the viewers at LL is not also in charge for releasing the sources ??? After all, (s)he needs the sources to produce the binaries and it would ensure that the published sources are -actually- the ones which were used for the official viewers... Regards, Henri. From matthew.dowd at hotmail.co.uk Sat Apr 5 11:36:17 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Apr 5 11:36:18 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: > 1.20 pre-RC, including Dazzle, will appear shortly as well. Can I make a plea that Dazzle does not go live (even in RC) until it supports different colour themes and that it comes with a "slate" scheme as well as the blue scheme? Whilst many like the blue scheme - many others find it *too* dazzling, i.e. too bright and harsh on the eyes, and detracting from the 3D world (the UI should be secondary to the 3D world not overpower it). Ultimately no colour scheme is going to satisfy everyone hence the importance of ensuring customisability at the outset - if you were to go live with just the blue scheme you will alienate a large number of users. There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. Matthew _________________________________________________________________ Win 100?s of Virgin Experience days with BigSnapSearch.com http://www.bigsnapsearch.com From soft at lindenlab.com Sat Apr 5 11:44:13 2008 From: soft at lindenlab.com (Soft) Date: Sat Apr 5 11:44:17 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <20080405203012.4ad3b0a0.sldev@free.fr> References: <20080405203012.4ad3b0a0.sldev@free.fr> Message-ID: On Sat, Apr 5, 2008 at 1:30 PM, Henri Beauchamp wrote: > On Sat, 5 Apr 2008 12:03:21 -0500, Soft wrote: > > > A few people have pinged about 1.19.1 source. > > > > I'm currently unable to publish to svn.secondlife.com - I'll get > > updates out when that's resolved. > > Good, thanks. > > > > In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except > > for some version strings. RC4 source will generate a functionally > > identical binary. > > Not if we take into account Rob's message to this list. Citation: > > "There was one change that slipped in between RC and final release" > > And obviously, it's a potential crash fix: > > - delete iter->second->data; > - delete iter->second; > + if(iter->second != NULL) > + { > + delete iter->second->data; > + delete iter->second; > + } > > So it is not a neglectable change ! Thanks. I was going on what was in the build notes and didn't see Rob's message. > Question: why the guy (or gal) in charge for compiling the viewers at > LL is not also in charge for releasing the sources ??? After all, > (s)he needs the sources to produce the binaries and it would ensure > that the published sources are -actually- the ones which were used > for the official viewers... That will happen this quarter. The release team has been lacking manpower to automate building and testing their source drops. The tools I've created for the ongoing branch snapshots have evolved into something that's 90% of what they need, so I'm going to work with them to bridge that gap and hand over all source responsibilities in the near future. From soft at lindenlab.com Sat Apr 5 11:49:23 2008 From: soft at lindenlab.com (Soft) Date: Sat Apr 5 11:49:26 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd wrote: > > There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. Could you provide a link on that, or encourage the poster to file it as a JIRA patch to clear licensing concerns? From kfa at gmx.net Sat Apr 5 12:09:08 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 5 12:09:19 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: <47F7CE54.1080403@gmx.net> Soft wrote: > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd wrote: > >> There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. >> > > Could you provide a link on that, or encourage the poster to file it > as a JIRA patch to clear licensing concerns? > _______________________________________________ > That reminds me to ask - sorry if I overlooked this was covered already - is it still needed to submit the source code contribution agreement before sending anything as explained on the wiki, or has this become obsolete with the remark there on the JIRA? Thanks From soft at lindenlab.com Sat Apr 5 12:19:12 2008 From: soft at lindenlab.com (Soft) Date: Sat Apr 5 12:19:23 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <47F7CE54.1080403@gmx.net> References: <47F7CE54.1080403@gmx.net> Message-ID: If it's a very simple change that strictly tweaks existing code or assets, we may use the change without follow-up. If it's a substantial change, we follow up privately with a contributor agreement. This is needed not only to cover us, but to cover others who use the code under a GPL license. The GPL nightmare scenario sees a patch with improperly licensed code being integrated and polluting every viewer. This puts not just us, but Henri, Marine, Dale, Nicholaz, Robin, and many others in harm's way. On Sat, Apr 5, 2008 at 2:09 PM, Felix Duesenburg wrote: > Soft wrote: > > > > > > > > > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd > wrote: > > > > > > > There was a suitable "slate" scheme for the Dazzle firstlook posted in > the forums. > > > > > > > > > > Could you provide a link on that, or encourage the poster to file it > > as a JIRA patch to clear licensing concerns? > > _______________________________________________ > > > > > That reminds me to ask - sorry if I overlooked this was covered already - > is it still needed to submit the source code contribution agreement before > sending anything as explained on the wiki, or has this become obsolete with > the remark there on the JIRA? > > Thanks > From matthew.dowd at hotmail.co.uk Sat Apr 5 14:07:35 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Apr 5 14:07:36 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: OK, I've tracked the forum thread down: http://forums.secondlife.com/showthread.php?t=242483 Matthew ---------------------------------------- > Date: Sat, 5 Apr 2008 13:49:23 -0500 > From: soft@lindenlab.com > To: matthew.dowd@hotmail.co.uk > Subject: Re: [sldev] 1.19.1 release source > CC: sldev@lists.secondlife.com > > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd wrote: >> >> There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. > > Could you provide a link on that, or encourage the poster to file it > as a JIRA patch to clear licensing concerns? _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live From kaleajinkya at gmail.com Sat Apr 5 22:59:51 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sat Apr 5 22:59:53 2008 Subject: [sldev] llcompilequeue.obj and llpreviewscript.obj errors Message-ID: I am getting the following llcompilequeue.obj and llpreviewscript.obj errors. I being a bit desparate ! Can anyone please let me know a solution for resolving these errors ? 1>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 1>Executing pre-build batch file 1>PREBUILD SUCCESSFUL 1>Linking... 1>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 1>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) 1>ReleaseForDownload/SecondLife.exe : fatal error LNK1120: 1 unresolved externals 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 1>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== Thanks a lot. -- Ajinkya From kfa at gmx.net Sun Apr 6 02:12:05 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 02:12:36 2008 Subject: [sldev] 1.19.1.4 RC - Crashes after successful build Message-ID: <47F893E5.2090801@gmx.net> Hi @, After getting the latest source to build without error, the resulting viewer keeps crashing at various states. It can be at the very beginning, yet before the main window is created, or shortly after login. Sometimes I can perform a few actions like creating a prim, sometimes it fails upon the first mouse click, or just after staying idle for a little. I cannot reproduce whatever causes the crash, the only thing in common is that it always crashes without exception within less than 3 minutes. This only happens with the self-compiled version (original source, not done any hacking yet). The official release is stable here and has never given me trouble. Thought they're supposed to be identical? I tried copying the compiled viewer into the regular program directory to see if any differences in the resource or settings files could cause problems, but the behaviour stays the same. It also doesn't make a difference whether I use the '-purge' option. Sometimes the logs show an assert failure like the one attached, sometimes it doesn't seem to have had the time to write anything anymore before going to byte nirvana, and the log ends without any indication of an error. Only one thing in common I noticed: See the multiple 'UNABLE TO LOAD TEXTURE' lines in the log, sometimes over a hundred for the same file, but the retries counter never increases. Is that something to worry about? Like to make sure I didn't miss any available info about running the viewer after a successful compile before filing a JIRA. TIA for any pointers. Felix -------------- next part -------------- 2008-04-06T08:34:17Z INFO: LLAppViewer::purgeCache: Purging Texture Cache... 2008-04-06T08:34:17Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. 2008-04-06T08:34:18Z INFO: LLAppViewer::purgeCache: Purging Cache... 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Checking marker file for lock... 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Exec marker found: program froze on previous execution 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file created. 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file locked. 2008-04-06T08:34:18Z INFO: Exiting initMarkerFile(). 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Second Life version 1.19.1 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Local time: 2008-04-06T04:34:18 Eastern Sommerzeit 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: CPU info: // CPU General Information ////////////////////////// Processor name: Intel Core 2 Series Processor Frequency: 2194.50 MHz Vendor: GenuineIntel Family: Intel Pentium Pro/2/3, Core Extended family: 0 Model: Intel Core 2 Series Processor Extended model: 0 Type: Brand ID: Processor Serial: Disabled // CPU Configuration //////////////////// L1 instruction cache: Not present L1 data cache: Not present L2 cache: Not present L3 cache: Not present Trace cache: Not present Instruction TLB: Not present Data TLB: Not present Max Supported CPUID-Level: 0x0000000A Max Supported Ext. CPUID-Level: 0x80000008 // CPU Extensions ///////////////// AA64 AMD 64-bit Architecture: No ACPI Thermal Monitor And Clock Control: Yes APIC Advanced Programmable Interrupt Controller: Yes APIC-ID: 0 CLFSH CLFLUSH Instruction Presence: Yes CLFLUSH Instruction Cache Line Size: 8 CMOV Conditional Move And Compare Instructions: Yes CX8 COMPXCHG8B Instruction: Yes DE Debugging Extensions: Yes DS Debug Store: Yes FGPAT Page Attribute Table: Yes FPU Floating Point Unit: Yes FXSR Fast Streaming SIMD Extensions Save/Restore: Yes HT Hyper Threading: Yes IA64 Intel 64-Bit Architecture: No MCA Machine Check Architecture: Yes MCE Machine Check Exception: Yes MMX Multimedia Extensions: Yes MMX+ Multimedia Extensions: No MSR Model Specific Registers: Yes MTRR Memory Type Range Registers: Yes PAE Physical Address Extension: Yes PGE PTE Global Flag: Yes PN Processor Serial Number: Disabled PSE Page Size Extensions: Yes PSE36 36-bit Page Size Extension: Yes SEP Fast System Call: Yes SS Self Snoop: Yes SSE Streaming SIMD Extensions: Yes SSE2 Streaming SIMD 2 Extensions: Yes ALTVEC Altivec Extensions: No TM Thermal Monitor: Yes TSC Time Stamp Counter: Yes VME Virtual 8086 Mode Enhancements: Yes 3DNow! Instructions: No Enhanced 3DNow! Instructions: No ->mHasSSE: 1 ->mHasSSE2: 1 ->mHasAltivec: 0 ->mCPUMhz: 2194 ->mCPUString: Intel Core 2 Series Processor (2194 MHz) 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Memory info: Percent Memory use: 51% Total Physical KB: 2062564 Avail Physical KB: 992572 Total page KB: 3999448 Avail page KB: 3029844 Total Virtual KB: 2097024 Avail Virtual KB: 1990832 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS: Microsoft Windows XP 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS info: Microsoft Windows XP Service Pack 2 (Build 2600) 2008-04-06T08:34:18Z INFO: LLAppViewer::init: Loading configuration file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\viewerart.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from C:\SL\1.19.1.4\workspace\linden\indra\newview\skins\textures\textures.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading base colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors_base.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading user colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Failed to load user colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading legacy colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.ini 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorization : DISABLED 2008-04-06T08:34:19Z INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorized Skinning : DISABLED 2008-04-06T08:34:19Z INFO: LLAppViewerWin32::initHardwareTest: Attempting to poll DirectX for hardware info 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: CoCreateInstance IID_IDxDiagProvider 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_providerp->Initialize 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_providerp->GetRootContainer 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_rootp->GetChildContainer 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: devices_containerp->GetChildContainer 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: VRAM Detected: 512 DX9 string: 512.0 MB 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Done polling DirectX for hardware info 2008-04-06T08:34:20Z WARNING: LLWinDebug::setupExceptionHandler: Our exception handler (007D9FD0) replaced with 4F666ADA! 2008-04-06T08:34:20Z WARNING: LLAppViewerWin32::initHardwareTest: Someone took over my exception handler (post hardware probe)! 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Detected VRAM: 512 2008-04-06T08:34:20Z INFO: LLTextureCache::initCache: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: VFS CACHE SIZE: 100 MB 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Bad or missing vfx index file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Removing old vfs data file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 to C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 to C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 2008-04-06T08:34:20Z INFO: LLVFS::presizeDataFile: Pre-sized VFS data file to 104857600 bytes 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 and data file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_index.db2 and data file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_data.db2 2008-04-06T08:34:20Z INFO: LLAppViewer::initWindow: Initializing window... 2008-04-06T08:34:21Z WARNING: LLGLManager::initWGL: No ARB WGL render texture extensions 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Swap Method: Exchange 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: GL buffer: Color Bits 32 Alpha Bits 8 Depth Bits 24 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: Couldn't initialize GL_EXT_paletted_texture 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Getting symbols 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Got symbols 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Disabling vertical sync 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Previous gamma: 1 2008-04-06T08:34:21Z INFO: LLViewerWindow::LLViewerWindow: Loading feature tables. 2008-04-06T08:34:21Z INFO: LLFeatureManager::loadGPUClass: GPU is NVIDIA Quadro FX 2008-04-06T08:34:21Z INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class1 2008-04-06T08:34:21Z INFO: LLFeatureManager::maskFeatures: Applying Feature Mask: Class1 2008-04-06T08:34:21Z INFO: LLViewerImageList::doPreloadImages: Preloading images... 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1eddba75-b682-110a-104e-6cdcce616a25 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1eddba75-b682-110a-104e-6cdcce616a25 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: bf0a8779-689b-48c3-bb9a-6af546366ef4 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: bf0a8779-689b-48c3-bb9a-6af546366ef4 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: bea77041-5835-1661-f298-47e2d32b7a70 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: bea77041-5835-1661-f298-47e2d32b7a70 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 2008-04-06T08:34:22Z INFO: decodeAllImages() took 1.33474 seconds. fetch_pending 0 create_time 0.0295445 2008-04-06T08:34:24Z INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml 2008-04-06T08:34:24Z INFO: LLShaderMgr::setShaders: ~~~~~~~~~~~~~~~~~~ Loading Shaders: ~~~~~~~~~~~~~~~~~~ 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsVarsV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsHelpersV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsHelpersV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFuncV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/sumLightsV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFuncSpecularV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncSpecularV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncSpecularV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/sumLightsSpecularV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsSpecularV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightSpecularV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightSpecularV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarSkinV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarSkinV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsVarsF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/gammaF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/gammaF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/transportF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/transportF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterFogF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterFogF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightWaterF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightWaterF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightShinyF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightShinyF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightShinyF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightShinyWaterF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 1 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/underWaterF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/underWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/terrainV.glsl class 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file not found: environment/terrainV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/terrainWaterF.glsl class 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file not found: environment/terrainWaterF.glsl 2008-04-06T08:34:24Z WARNING: LLGLSLShader::createShader: Failed to link shader: Terrain Water Shader 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowExtractV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowExtractF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: interface/highlightV.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: interface/highlightF.glsl class 2 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarF.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/avatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: objects/simpleWaterF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarV.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarF.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballV.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballF.glsl class 3 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: objects/simpleWaterF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarV.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarF.glsl class 1 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballV.glsl class 1 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballV.glsl 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballF.glsl class 1 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 2008-04-06T08:34:25Z INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml 2008-04-06T08:34:25Z INFO: GL_VENDOR NVIDIA Corporation GL_RENDERER Quadro FX 570M/PCI/SSE2 GL_VERSION 2.1.1 GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_bindable_uniform GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_buffer_object GL_EXT_texture_compression_latc GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_buffer_float GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage GL_NV_geometry_shader4 GL_NV_gpu_program4 GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_parameter_buffer_object GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_transform_feedback GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_NVX_conditional_render GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum GL_WIN_swap_hint WGL_EXT_swap_control GL_Autodesk_valid_back_buffer_hint WGL_ARB_buffer_region WGL_ARB_extensions_string WGL_ARB_make_current_read WGL_ARB_multisample WGL_ARB_pbuffer WGL_ARB_pixel_format WGL_ARB_pixel_format_float WGL_ARB_render_texture WGL_ATI_pixel_format_float WGL_EXT_extensions_string WGL_EXT_framebuffer_sRGB WGL_EXT_pixel_format_packed_float WGL_EXT_swap_control WGL_I3D_genlock WGL_NV_float_buffer WGL_NV_gpu_affinity WGL_NV_render_depth_texture WGL_NV_render_texture_rectangle WGL_NV_swap_group 2008-04-06T08:34:25Z INFO: LLAppViewer::init: Viewer Digest: 335acf7c-1908-df4d-b05f-bc0574e907e4 2008-04-06T08:34:25Z INFO: LLVoiceClient::setState: entering state stateDisabled 2008-04-06T08:34:25Z INFO: LLVoiceClient::switchChannel: called in state stateDisabled with uri "" 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Resend: 150 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Land: 130 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Wind: 26 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Cloud: 26 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Task: 484 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Texture: 484 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Asset: 200 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Total: 1500 2008-04-06T08:34:26Z INFO: idle_startup: Initializing messaging system... 2008-04-06T08:34:26Z INFO: LLTemplateParser::LLTemplateParser: ### Message template version 2 ### 2008-04-06T08:34:26Z INFO: start_net: attempting to connect on port 0 2008-04-06T08:34:26Z INFO: start_net: connected on port 1503 2008-04-06T08:34:26Z INFO: start_net: startNet - receive buffer size : 400000 2008-04-06T08:34:26Z INFO: start_net: startNet - send buffer size : 400000 2008-04-06T08:34:26Z INFO: start_messaging_system: Message template version matches prehash version number 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadFile: Loading message.xml file at C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadCapBans: 25 ban tests 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: no messages banned 2008-04-06T08:34:26Z INFO: LLMessageConfig::initClass config file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle min rate: 2.66667e+006 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle actual rate: 2.93333e+006 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle min rate: 8000 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle actual rate: 150000 2008-04-06T08:34:26Z INFO: LLAssetStorage::setUpstream: AssetStorage: Setting upstream provider to 0.0.0.0:0 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() initializing FMOD 2008-04-06T08:34:26Z WARNING: LLAudioEngine_FMOD::init: Error : You are using the wrong FMOD version (3.74)! You should be using FMOD 3.75 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() FMOD initialized correctly 2008-04-06T08:34:26Z INFO: LLStartUp::setStartupState: Startup state changing from 0 to 1 2008-04-06T08:34:26Z INFO: idle_startup: Initializing Multimedia.... 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state changing from 1 to 2 2008-04-06T08:34:29Z WARNING: LLWinDebug::setupExceptionHandler: Our exception handler (007D9FD0) replaced with 6681F570! 2008-04-06T08:34:29Z WARNING: LLAppViewer::mainLoop: Someone took over my exception handler (post messagehandling)! 2008-04-06T08:34:29Z INFO: idle_startup: Initializing Window 2008-04-06T08:34:29Z WARNING: Attempted getFields with no login view shown 2008-04-06T08:34:29Z INFO: login_show: Initializing Login Screen 2008-04-06T08:34:29Z WARNING: LLWebBrowserCtrl::navigateToLocalPage: File loading\loading.htmlnot found 2008-04-06T08:34:29Z INFO: login_show: Setting Servers 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state changing from 2 to 3 2008-04-06T08:34:30Z INFO: LLAudioEngine::startNextTransfer: Getting asset data for: c80260ba-41fd-8a46-768a-6bf236360e3a 2008-04-06T08:34:30Z WARNING: LLAssetStorage::_queueDataRequest: Attempt to move asset data request upstream w/o valid upstream provider 2008-04-06T08:34:30Z INFO: LLAudioEngine::assetCallback: Boom, error in audio file transfer: Circuit gone (-23017) 2008-04-06T08:34:38Z INFO: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:HTTP/1.0 200 OK 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:48Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:49Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:50Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:51Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:52Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:53Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:54Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:55Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:56Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:57Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:58Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:34:59Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:00Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:00Z INFO: LLAudioEngine::startNextTransfer: Getting asset data for: 4c8c3c77-de8d-bde2-b9b8-32635e0fd4a6 2008-04-06T08:35:00Z WARNING: LLAssetStorage::_queueDataRequest: Attempt to move asset data request upstream w/o valid upstream provider 2008-04-06T08:35:00Z INFO: LLAudioEngine::assetCallback: Boom, error in audio file transfer: Circuit gone (-23017) 2008-04-06T08:35:00Z INFO: LLStartUp::setStartupState: Startup state changing from 3 to 4 2008-04-06T08:35:00Z INFO: idle_startup: Attempting login as: Felix Duesenburg 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: Current Directories: 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: CurPath: C:\SL\1.19.1.4\workspace\linden\indra\newview 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: AppName: SecondLife 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: ExecutableFilename: SecondLife.exe 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: ExecutableDir: C:\SL\1.19.1.4\workspace\linden\indra\newview 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: ExecutablePathAndName: C:\SL\1.19.1.4\workspace\linden\indra\newview\SecondLife.exe 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: WorkingDir: C:\SL\1.19.1.4\workspace\linden\indra\newview 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: AppRODataDir: C:\SL\1.19.1.4\workspace\linden\indra\newview 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: OSUserDir: C:\Dokumente und Einstellungen\User\Anwendungsdaten 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: OSUserAppDir: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: LindenUserDir: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\felix_duesenburg 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: TempDir: C:\DOKUME~1\User\LOKALE~1\Temp 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: CAFile: C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\CA.pem 2008-04-06T08:35:00Z INFO: LLDir::dumpCurrentDirectories: SkinDir: 2008-04-06T08:35:00Z WARNING: LLXmlParser::parseFile: Couldn't open file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\felix_duesenburg\overrides.xml 2008-04-06T08:35:00Z WARNING: LLXmlTree::parseFile: LLXmlTree parse failed. Line 1: Couldn't open file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\felix_duesenburg\overrides.xml 2008-04-06T08:35:00Z WARNING: LLControlGroup::loadFromFile: Unable to open control file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\felix_duesenburg\overrides.xml 2008-04-06T08:35:00Z INFO: LLURLHistory::loadFile: Loading history.xml file at url_history.xml 2008-04-06T08:35:00Z INFO: LLURLHistory::loadFile: file missing, ill-formed, or simply undefined; not changing the file 2008-04-06T08:35:00Z INFO: init_start_screen: Loading startup bitmap... 2008-04-06T08:35:01Z INFO: LLStartUp::setStartupState: Startup state changing from 4 to 6 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:01Z INFO: LLAres::rewriteURI: Rewriting https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-04-06T08:35:01Z INFO: Responder::rewriteResult: [0] https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-04-06T08:35:01Z INFO: LLStartUp::setStartupState: Startup state changing from 6 to 7 2008-04-06T08:35:01Z INFO: LLUserAuth::authenticate: Authenticating: Felix Duesenburg, 2008-04-06T08:35:01Z INFO: LLUserAuth::authenticate: Options: inventory-root, inventory-skeleton, inventory-lib-root, inventory-lib-owner, inventory-skel-lib, initial-outfit, gestures, event_categories, event_notifications, classified_categories, buddy-list, ui-config, login-flags, global-textures, END 2008-04-06T08:35:01Z INFO: LLUserAuth::authenticate: uri=https://login.agni.lindenlab.com/cgi-bin/login.cgi 2008-04-06T08:35:01Z INFO: LLStartUp::setStartupState: Startup state changing from 7 to 8 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:01Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:02Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:03Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:04Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:05Z INFO: LLStartUp::setStartupState: Startup state changing from 8 to 9 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:05Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:06Z INFO: LLXMLRPCTransaction::transferRate: Buffer size: 139461 B 2008-04-06T08:35:06Z INFO: LLXMLRPCTransaction::transferRate: Transfer size: 15072 B 2008-04-06T08:35:06Z INFO: LLXMLRPCTransaction::transferRate: Transfer time: 5.175 s 2008-04-06T08:35:06Z INFO: LLXMLRPCTransaction::transferRate: Transfer rate: 23.296 Kb/s 2008-04-06T08:35:06Z INFO: LLUserAuth::authResponse: Processed response: 0 2008-04-06T08:35:06Z INFO: LLStartUp::setStartupState: Startup state changing from 9 to 10 2008-04-06T08:35:06Z INFO: LLCircuit::addCircuitData for 216.82.20.185:13005 2008-04-06T08:35:06Z INFO: LLStartUp::setStartupState: Startup state changing from 10 to 11 2008-04-06T08:35:06Z INFO: LLVoiceClient::userAuthorized: name "Felix Duesenburg" , ID 5745af52-9d2e-4f0b-90c5-be7decaabfd7 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:06Z INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml 2008-04-06T08:35:06Z INFO: LLPostProcess::LLPostProcess: Loading PostProcess Effects settings from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight\postprocesseffects.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading WindLight settings from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\ 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D12AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D12AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D12PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D12PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D3AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D3AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D3PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D3PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D6AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D6AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D6PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D6PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D9AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D9AM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: A%2D9PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\A%2D9PM.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Barcelona.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Barcelona.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Blizzard.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Blizzard.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Blue%20Midday.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Blue%20Midday.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Coastal%20Afternoon.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Coastal%20Afternoon.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Coastal%20Sunset.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Coastal%20Sunset.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Default.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Default.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Desert%20Sunset.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Desert%20Sunset.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Fine%20Day.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Fine%20Day.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Fluffy%20Big%20Clouds.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Fluffy%20Big%20Clouds.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Foggy.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Foggy.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Funky%20Funky%20Funky.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Funky%20Funky%20Funky.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Funky%20Funky.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Funky%20Funky.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Gelatto.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Gelatto.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Ghost.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Ghost.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Incongruent%20Truths.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Incongruent%20Truths.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Midday%201.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Midday%201.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Midday%202.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Midday%202.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Midday%203.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Midday%203.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Midday%204.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Midday%204.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Night.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Night.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Pirate.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Pirate.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Purple.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Purple.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Sailor%27s%20Delight.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Sailor%27s%20Delight.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: Sheer%20Surreality.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: Loading sky from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/skies\Sheer%20Surreality.xml 2008-04-06T08:35:06Z INFO: LLWLParamManager::loadPresets: name: 2008-04-06T08:35:06Z INFO: LLWLDayCycle::loadDayCycle: Loading DayCycle settings from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/days\Default.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water settings from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\ 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Default.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Default.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Glassy.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Glassy.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Murky.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Murky.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Pond.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Pond.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Second%20Plague.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Second%20Plague.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: SNAKE%21%21%21.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\SNAKE%21%21%21.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: Valdez.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: Loading water from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight/water\Valdez.xml 2008-04-06T08:35:06Z INFO: LLWaterParamManager::loadAllPresets: name: 2008-04-06T08:35:06Z INFO: LLViewerObject::initVOClasses: Viewer Object size: 416 2008-04-06T08:35:06Z INFO: LLWorld::addRegion: Adding new region (1138:1085) 2008-04-06T08:35:06Z INFO: LLWorld::addRegion: Host: 216.82.20.185:13005 2008-04-06T08:35:06Z INFO: idle_startup: Adding initial simulator { 291328, 277760, 0 } 2008-04-06T08:35:06Z INFO: LLStartUp::setStartupState: Startup state changing from 11 to 12 2008-04-06T08:35:06Z INFO: LLViewerRegion::setSeedCapability: posting to seed https://sim3196.agni.lindenlab.com:12043/cap/f848bd85-9840-1da8-fa79-65927037edbd 2008-04-06T08:35:06Z INFO: idle_startup: Waiting for seed grant .... 2008-04-06T08:35:06Z INFO: LLAgent::setRegion: Moving agent into region: located at 216.82.20.185:13005 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:06Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: cce0f112-878f-4586-a2e2-a8f104bba271 Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: cce0f112-878f-4586-a2e2-a8f104bba271 RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d07f6eed-b96a-47cd-b51d-400ad4a1c428 Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d07f6eed-b96a-47cd-b51d-400ad4a1c428 RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:07Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:08Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ChatSessionRequest 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for CopyInventoryFromNotecard 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for DispatchRegionInfo 2008-04-06T08:35:08Z INFO: `anonymous-namespace'::LLEventPollResponder::LLEventPollResponder: LLEventPoll initialized with sender 216.82.20.185:13005 2008-04-06T08:35:08Z INFO: LLEventPollResponder::start <1> https://sim3196.agni.lindenlab.com:12043/cap/f85e0c6b-7df6-3146-03ad-06cdf6de69eb 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for EventQueueGet 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for GroupProposalBallot 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for MapLayer 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for MapLayerGod 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for NewFileAgentInventory 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ParcelPropertiesUpdate 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ParcelVoiceInfoRequest 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ProvisionVoiceAccountRequest 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for RemoteParcelRequest 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatRequest 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatTracking 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for SendPostcard 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReport 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReportWithScreenshot 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ServerReleaseNotes 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for StartGroupProposal 2008-04-06T08:35:08Z INFO: LLHTTPSender::setSender 216.82.20.185:13005 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for UntrustedSimulatorMessage 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureAgentInventory 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureTaskInventory 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for UpdateNotecardAgentInventory 2008-04-06T08:35:08Z INFO: BaseCapabilitiesComplete::result got capability for ViewerStats 2008-04-06T08:35:08Z INFO: LLStartUp::setStartupState: Startup state changing from 12 to 13 2008-04-06T08:35:08Z INFO: idle_startup: Initializing communications... 2008-04-06T08:35:08Z INFO: idle_startup: Initializing camera... 2008-04-06T08:35:08Z INFO: idle_startup: Initializing sky... 2008-04-06T08:35:08Z INFO: LLDrawPoolWLSky::LLDrawPoolWLSky: loading WindLight cloud noise from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\windlight\clouds2.tga 2008-04-06T08:35:09Z INFO: idle_startup: Decoding images... 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: cce0f112-878f-4586-a2e2-a8f104bba271 Discard: 0 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: cce0f112-878f-4586-a2e2-a8f104bba271 RETRIES: 0 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d07f6eed-b96a-47cd-b51d-400ad4a1c428 Discard: 0 2008-04-06T08:35:09Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d07f6eed-b96a-47cd-b51d-400ad4a1c428 RETRIES: 0 2008-04-06T08:35:10Z INFO: decodeAllImages() took 1.00379 seconds. fetch_pending 47 create_time 0.00116719 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: cce0f112-878f-4586-a2e2-a8f104bba271 Discard: 0 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: cce0f112-878f-4586-a2e2-a8f104bba271 RETRIES: 0 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d07f6eed-b96a-47cd-b51d-400ad4a1c428 Discard: 0 2008-04-06T08:35:10Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d07f6eed-b96a-47cd-b51d-400ad4a1c428 RETRIES: 0 2008-04-06T08:35:11Z INFO: decodeAllImages() took 1.00476 seconds. fetch_pending 47 create_time 0.00197763 2008-04-06T08:35:11Z INFO: LLStartUp::setStartupState: Startup state changing from 13 to 14 2008-04-06T08:35:11Z INFO: idle_startup: viewer: UserLoginLocationReply() Enabling 216.82.20.185:13005 with code 362796726 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: cce0f112-878f-4586-a2e2-a8f104bba271 Discard: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: cce0f112-878f-4586-a2e2-a8f104bba271 RETRIES: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 2008-04-06T08:35:11Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 2008-04-06T08:35:11Z INFO: LLStartUp::setStartupState: Startup state changing from 14 to 15 2008-04-06T08:35:11Z INFO: idle_startup: Connecting to region... 2008-04-06T08:35:11Z INFO: LLAssetStorage::setUpstream: AssetStorage: Setting upstream provider to 216.82.20.185:13005 2008-04-06T08:35:11Z INFO: LLStartUp::setStartupState: Startup state changing from 15 to 16 2008-04-06T08:35:11Z INFO: LLVoiceClient::parcelChanged: not logged in yet, deferring 2008-04-06T08:35:11Z INFO: process_agent_movement_complete() 2008-04-06T08:35:11Z WARNING: process_agent_movement_complete: agent_movement_complete() with NULL avatarp. 2008-04-06T08:35:11Z INFO: process_agent_movement_complete: Changing home region to 291328:277760 2008-04-06T08:35:11Z INFO: LLAssetStorage::setUpstream: AssetStorage: Setting upstream provider to 216.82.20.185:13005 2008-04-06T08:35:11Z INFO: LLViewerThrottleGroup::sendToSim: Sending throttle settings, total BW 1500 2008-04-06T08:35:11Z INFO: LLStartUp::setStartupState: Startup state changing from 16 to 17 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadFromFile(C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\ba2a564a-f0f1-4b82-9c61-b7520bfcd09f.inv) 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadFromFile: unable to load inventory from: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\ba2a564a-f0f1-4b82-9c61-b7520bfcd09f.inv 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadSkeleton: Successfully loaded 0 categories and 0 items from cache. 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadFromFile(C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\5745af52-9d2e-4f0b-90c5-be7decaabfd7.inv) 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadFromFile: unable to load inventory from: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\5745af52-9d2e-4f0b-90c5-be7decaabfd7.inv 2008-04-06T08:35:11Z INFO: LLInventoryModel::loadSkeleton: Successfully loaded 0 categories and 0 items from cache. 2008-04-06T08:35:11Z INFO: LLInventoryModel::buildParentChildMap() 2008-04-06T08:35:11Z INFO: LLViewerInventoryCategory::fetchDescendents: FetchInventoryDescendents capability not found. Using deprecated UDP message. 2008-04-06T08:35:12Z INFO: LLInventoryView::init: reading from 0012F77C 2008-04-06T08:35:12Z INFO: LLStartUp::setStartupState: Startup state changing from 17 to 18 2008-04-06T08:35:12Z INFO: idle_startup: Gesture Manager loading 40 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for af2b8320-e579-2c41-b717-969759aeb3ca 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for b5ea617e-47cf-612b-2d99-8c6f6dcac218 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0a3336cf-3ad1-012a-91c2-5b5620aaaef3 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for fc3de4b8-bd3e-662b-934c-b72714dab5bf 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for c63ac707-6325-14c8-d681-54b81d0dff77 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for ba38eeb2-d35f-0a07-0c04-0eb42fcc6010 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 76f7ced2-4f91-31c8-ff7d-e76b19abfa40 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for f2483d55-bc31-38c0-65b2-9f7e87fce5c4 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 865c5fe0-aafb-671a-8ad5-778beb24b6f8 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for e7584536-86f2-c962-405d-d14adff71f38 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 1910ffbd-096c-5eb7-19f5-8c99ab6a748c 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0247dbfa-f37e-64ab-d09f-2678884c7f4a 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 40b92916-8055-2562-008f-58924bd0e03c 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 6212ffdd-d447-a92f-18f3-8cb94a799d83 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 66ecd9bd-22e1-2633-f41e-ad1a38205662 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 76d30ee1-c369-12ec-8dbc-9cf2f51120ff 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0813d01a-d3d3-32a4-48a3-26b6e1e01e39 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for aca78492-0487-03ec-4eb5-5c8e76c837e1 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 44a87e64-2d78-14b7-1cde-ac0f5031621f 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for a6a09cb1-0845-5ec0-051e-16bb79b30ddf 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 97c5742d-1d74-9408-2bae-9738a9e9d084 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for ea9ab69b-c2c7-3e18-a50b-37a9cfe457cd 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for d918a0d8-7291-ce83-762f-3f68dcc7402d 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for fb262981-4295-f048-c280-629081bf3b6b 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 8868cfa3-5b82-97ab-dc38-ded906f7fd90 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0eeb5ef7-10dd-4e4a-11a5-d053011fcdf2 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0ce71257-7a07-257f-f023-fd68575a3a4e 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 0401dc30-0fdd-1fc3-3e51-c683fe117184 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 5ac79d32-d625-dc20-4584-d80fa524483a 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 04608b19-1668-399c-5790-b7df8d9dc9cf 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 15c961e7-5753-88a0-7a6c-26d58d3e2cfa 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 2c183d56-df0f-b585-892d-6c079d8cadbc 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 54f887d0-6326-626c-5808-5074908b7d22 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 5a68100b-e6ba-5170-649c-80beddc67035 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for fa743da9-7e6e-d88e-3e4f-143dcb4fc01b 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 52d9684f-2dcf-c252-2360-186b4236d07e 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for b6f560d1-e2ad-24df-344c-2943c47a6775 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 43417d10-a2f7-7727-6fd4-dd7f04ad7a13 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for a927812a-535b-f5ad-2c70-60c24f1c3be7 2008-04-06T08:35:12Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 8b753e16-bd7d-2bb3-7765-671b7b31e77c 2008-04-06T08:35:12Z INFO: idle_startup: Initialization complete 2008-04-06T08:35:12Z INFO: LLStartUp::setStartupState: Startup state changing from 18 to 19 2008-04-06T08:35:12Z INFO: LLAppViewer::idle: Transmitting sessions stats 2008-04-06T08:35:12Z INFO: LLViewerStats::addToMessage: STAT: Version: 0 2008-04-06T08:35:12Z INFO: LLViewerStats::addToMessage: STAT: Vertex Buffers Enabled: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 86c6fb77-efb3-b2ba-61d6-dd9360cba22b, size 68 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 1863a44e-ecdd-eae4-92e7-8229b01f3fdf, size 122 bytes 2008-04-06T08:35:12Z INFO: process_money_balance_reply: L$, credit, committed: 19197 0 0 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 2c10a552-6857-f7d0-bcf4-b95d9219fd22, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 023500e3-a091-1993-1a93-1272f15dd899, size 122 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving b9321638-3bd0-3bfe-3f86-0f38f6284e9d, size 76 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving e7f47fd8-aa08-2ae4-64c5-4a458ef2bce2, size 132 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 90f1a142-78b7-da2d-f89b-6f3b1a4182fe, size 71 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving c9f7cbc3-de9d-29f4-2da0-5dd86461a9ad, size 130 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 83b3cf88-4dc9-7db0-8a63-c40104f53254, size 74 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 7a22dea4-92c7-b1e8-15e6-a33f076576e9, size 122 bytes 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 93216b66-9f1c-24f2-89fc-340fd4c56037, size 123 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving ffe43d1a-5d73-de86-c1aa-b1e32be42fa7, size 82 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving db5dcf61-9bb8-b169-3d70-756acce1609e, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving a5169eca-856f-e16e-3e99-060a8ec83487, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 5e4eb0b4-1a8b-be83-113a-a5846eb5eefc, size 65 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 586e1836-514a-7977-9042-4c454fd17ef6, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 21a6176d-7bde-cb0c-5582-cf94f4be5b46, size 139 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 62a21583-d1e0-dbea-2a37-fc46c59f89a3, size 71 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 62e9818a-73eb-3b46-487b-eefa51efb5e2, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 08d84e28-0271-45ad-e7ec-1eb32ad56c26, size 70 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving ad792fd2-bf6a-ee55-cada-20b326eace0d, size 78 bytes 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 5b878c3f-577f-8be3-cbf7-948741819e77, size 120 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving df6569d3-7bd6-41db-ec9b-258ff3ec70be, size 129 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving d89abc56-dc0b-9d41-0b22-335b913722b6, size 123 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving b3434729-312d-600d-5e72-570c18fc2da9, size 75 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving b0ed0ed0-13bd-c464-4497-6bf528ab8bb0, size 71 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 3aa355e9-c473-7fd7-9453-4fb1c2cf46de, size 116 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving cf438057-ff24-d54e-df51-2ebfccfcf820, size 60 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving c0d8968d-a298-7337-76fc-2a8f321dbab9, size 112 bytes 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 21b01ac5-67ff-610c-a377-40e4bd111a78, size 73 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 2d0f9d91-99d7-7ac2-a5fa-e50fc7e32d4b, size 125 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving b750dba7-57d3-e065-d07f-e367d14d4758, size 74 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 3231f2b8-1b8c-c1f6-d4bc-90b1f139b5c7, size 124 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving efcd2e8a-5280-b6a6-40bf-d679ed4ada73, size 62 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 02387371-5ab5-ba49-46a6-6d79be88f53e, size 127 bytes 2008-04-06T08:35:12Z INFO: LLTransferManager::processTransferInfo: Receiving 71cf7e09-f0fc-02be-2d8e-90493ef14a75, size 70 bytes 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z INFO: LLCircuit::addCircuitData for 63.210.158.212:13004 2008-04-06T08:35:12Z INFO: LLWorld::addRegion: Adding new region (1137:1085) 2008-04-06T08:35:12Z INFO: LLWorld::addRegion: Host: 63.210.158.212:13004 2008-04-06T08:35:12Z INFO: process_enable_simulator: simulator_enable() Enabling 63.210.158.212:13004 with code 362796726 2008-04-06T08:35:12Z INFO: LLCircuit::addCircuitData for 8.2.35.152:13004 2008-04-06T08:35:12Z INFO: LLWorld::addRegion: Adding new region (1138:1084) 2008-04-06T08:35:12Z INFO: LLWorld::addRegion: Host: 8.2.35.152:13004 2008-04-06T08:35:12Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.35.152:13004 with code 362796726 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:12Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTransferManager::processTransferInfo: bf5bf4d3-46a0-ce52-2c8d-f4e0a266a713: Non-ok status, cleaning up 2008-04-06T08:35:13Z WARNING: LLTransferTargetVFile::completionCallback: Aborting vfile transfer for 54f887d0-6326-626c-5808-5074908b7d22 2008-04-06T08:35:13Z WARNING: LLGestureManager::onLoadComplete: Problem loading gesture: -4 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/AgentDropGroup 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/AgentGroupDataUpdate 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ChatterBoxInvitation 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ChatterBoxSessionAgentListUpdates 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ChatterBoxSessionEventReply 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ChatterBoxSessionStartReply 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ChatterBoxSessionUpdate 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/CoarseLocationUpdate 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/EstablishAgentCommunication 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ForceCloseChatterBoxSession 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/ParcelVoiceInfo 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /message/RequiredVoiceVersion 2008-04-06T08:35:13Z INFO: LLHTTPRegistrar::buildAllServices adding node for path /trusted-message/ 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 0bc58228-74a0-7e83-89bc-5c23464bcec5 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 0bc58228-74a0-7e83-89bc-5c23464bcec5 RETRIES: 0 2008-04-06T08:35:13Z INFO: LLVoiceClient::parcelChanged: not logged in yet, deferring 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTransferManager::processTransferInfo: 4d815795-bb44-d50f-50d9-ea265e61148c: Non-ok status, cleaning up 2008-04-06T08:35:13Z WARNING: LLTransferTargetVFile::completionCallback: Aborting vfile transfer for 2c183d56-df0f-b585-892d-6c079d8cadbc 2008-04-06T08:35:13Z WARNING: LLGestureManager::onLoadComplete: Problem loading gesture: -4 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z INFO: process_enable_simulator: simulator_enable() Enabling 63.210.158.212:13004 with code 362796726 2008-04-06T08:35:13Z INFO: process_enable_simulator: simulator_enable() Enabling 8.2.35.152:13004 with code 362796726 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:13Z WARNING: LLTransferManager::processTransferInfo: e0c43bbd-3808-d7b4-7222-0375ab28de55: Non-ok status, cleaning up 2008-04-06T08:35:13Z WARNING: LLTransferTargetVFile::completionCallback: Aborting vfile transfer for 15c961e7-5753-88a0-7a6c-26d58d3e2cfa 2008-04-06T08:35:13Z WARNING: LLGestureManager::onLoadComplete: Problem loading gesture: -4 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:13Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z INFO: LLMuteList::processMuteListUpdate() 2008-04-06T08:35:14Z INFO: LLXfer_File::initializeRequest: Requesting xfer from 216.82.20.185:13005 for file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\mute_5745af52-9d2e-4f0b-90c5-be7decaabfd7.tmp 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z INFO: LLXfer::processEOF: xfer from 216.82.20.185:13005 complete: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\mute_5745af52-9d2e-4f0b-90c5-be7decaabfd7.tmp 2008-04-06T08:35:14Z INFO: LLMuteList::onFileMuteList: LLMuteList::processMuteListFile() 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTransferManager::processTransferInfo: a699a471-9bd1-e00e-409c-f2e8dd34cda0: Non-ok status, cleaning up 2008-04-06T08:35:14Z WARNING: LLTransferTargetVFile::completionCallback: Aborting vfile transfer for 5ac79d32-d625-dc20-4584-d80fa524483a 2008-04-06T08:35:14Z WARNING: LLGestureManager::onLoadComplete: Problem loading gesture: -4 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z INFO: ViewerStatsResponder::result 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z INFO: LLCircuit::addCircuitData for 216.82.18.65:12035 2008-04-06T08:35:14Z INFO: LLWorld::addRegion: Adding new region (1137:1084) 2008-04-06T08:35:14Z INFO: LLWorld::addRegion: Host: 216.82.18.65:12035 2008-04-06T08:35:14Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.18.65:12035 with code 362796726 2008-04-06T08:35:14Z WARNING: LLWorld::addRegion exists, but isn't alive 2008-04-06T08:35:14Z INFO: LLWorld::removeRegion: Removing region 291072:277504 2008-04-06T08:35:14Z INFO: LLWorld::addRegion: Adding new region (1137:1084) 2008-04-06T08:35:14Z INFO: LLWorld::addRegion: Host: 216.82.18.65:12035 2008-04-06T08:35:14Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.18.65:12035 with code 362796726 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:14Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z INFO: LLViewerRegion::setSeedCapability: posting to seed https://sim4562.agni.lindenlab.com:12043/cap/b3a5f312-0a70-2560-86bd-775e2c1671bb 2008-04-06T08:35:15Z INFO: LLViewerRegion::setSeedCapability: posting to seed https://sim5850.agni.lindenlab.com:12043/cap/1ddf3740-68b7-4f97-5e97-26dbb664e9d9 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.18.65:12035 with code 362796726 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:15Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:16Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:18Z INFO: LLMessageSystem::dumpReceiveCounts: Dump: 1 messages processed in 1.55657 seconds 2008-04-06T08:35:18Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 63338ede-0037-c4fd-855b-015d77112fc8 Discard: 0 2008-04-06T08:35:18Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 63338ede-0037-c4fd-855b-015d77112fc8 RETRIES: 0 2008-04-06T08:35:18Z INFO: LLStartUp::setStartupState: Startup state changing from 19 to 20 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 51a0d63a-ffd7-0dc7-1b40-5fda561c36f2 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 75813e92-710f-3df9-9d7d-f4fb39adf074 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 4e72a9e9-696e-3f01-9583-be9c4790b1d4 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 9b8aa1ba-6d44-a711-f906-ebbb5b856781 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 418bb80b-d762-06d8-3482-4dce15f7d0ad 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for fd08a3f2-34db-12aa-733f-4ba7b5dc2f14 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 50d5af74-2dd4-3d18-cfe8-ee5c88435787 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for dfceb329-05f0-c555-c014-076123459aa7 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for f3cc9255-9817-1dc8-63bc-848de89b1e59 2008-04-06T08:35:18Z INFO: LLAssetStorage::_queueDataRequest: Starting transfer for 509d8139-68cf-94d4-2434-966652b761fb 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 3b377c12-feb0-489a-503d-b770dc121c14, size 2902 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving a9f03a8a-e6fc-f5d2-0398-aeefbef9d096, size 1087 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 1c971522-b22b-ab9c-0571-5b31d637ecff, size 748 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 4a9d4320-0a98-6826-8d77-25e5384e1ade, size 761 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 9fb1d737-646f-5dc1-191b-3d42380cdc4a, size 514 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving faef8f8f-f55f-2cc8-0445-fa2cc623e538, size 567 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving bfa20d7c-80ab-1bff-9a92-c8656ba58c88, size 564 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 71dd2ab9-bf10-c3d6-99c4-ea07b82912d4, size 531 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving efb93097-b99f-53c8-9c1a-87a9b441a5bd, size 607 bytes 2008-04-06T08:35:18Z INFO: LLTransferManager::processTransferInfo: Receiving 3214283a-2412-6aaf-f5d9-9b938eae7a1e, size 553 bytes 2008-04-06T08:35:18Z INFO: LLAgent::sendAgentSetAppearance: TAT: Sent AgentSetAppearance: HEAD UPPER LOWER EYES 2008-04-06T08:35:18Z INFO: LLAgent::sendAgentSetAppearance: TAT: Sending cached texture data 2008-04-06T08:35:19Z INFO: LLStartUp::setStartupState: Startup state changing from 20 to 21 2008-04-06T08:35:19Z INFO: LLCircuit::addCircuitData for 63.210.158.111:12035 2008-04-06T08:35:19Z INFO: LLWorld::addRegion: Adding new region (1139:1085) 2008-04-06T08:35:19Z INFO: LLWorld::addRegion: Host: 63.210.158.111:12035 2008-04-06T08:35:19Z INFO: process_enable_simulator: simulator_enable() Enabling 63.210.158.111:12035 with code 362796726 2008-04-06T08:35:19Z INFO: LLCircuit::addCircuitData for 216.82.19.23:12035 2008-04-06T08:35:19Z INFO: LLWorld::addRegion: Adding new region (1138:1086) 2008-04-06T08:35:19Z INFO: LLWorld::addRegion: Host: 216.82.19.23:12035 2008-04-06T08:35:19Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.23:12035 with code 362796726 2008-04-06T08:35:19Z INFO: LLTexStaticImageList::deleteCachedImages: Clearing Static Textures KB GL:48KB TGA:0KB 2008-04-06T08:35:19Z INFO: LLStartUp::setStartupState: Startup state changing from 21 to 22 2008-04-06T08:35:19Z INFO: idle_startup: Doing first audio_update_volume... 2008-04-06T08:35:19Z INFO: idle_startup: Done first audio_update_volume. 2008-04-06T08:35:19Z INFO: LLVOWLSky::updateGeometry: WL Skydome strips in 3 batches. 2008-04-06T08:35:19Z INFO: LLPipeline::resizeScreenTexture: RESIZED SCREEN TEXTURE: 1920x1129 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ChatSessionRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for CopyInventoryFromNotecard 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for DispatchRegionInfo 2008-04-06T08:35:19Z INFO: `anonymous-namespace'::LLEventPollResponder::LLEventPollResponder: LLEventPoll initialized with sender 63.210.158.212:13004 2008-04-06T08:35:19Z INFO: LLEventPollResponder::start <2> https://sim4562.agni.lindenlab.com:12043/cap/c1023e9c-5557-96df-b2fc-a53d8dc19ff9 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for EventQueueGet 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for GroupProposalBallot 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for MapLayer 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for MapLayerGod 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for NewFileAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ParcelPropertiesUpdate 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ParcelVoiceInfoRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ProvisionVoiceAccountRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for RemoteParcelRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatTracking 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendPostcard 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReport 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReportWithScreenshot 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ServerReleaseNotes 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for StartGroupProposal 2008-04-06T08:35:19Z INFO: LLHTTPSender::setSender 63.210.158.212:13004 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UntrustedSimulatorMessage 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureTaskInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateNotecardAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ViewerStats 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ChatSessionRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for CopyInventoryFromNotecard 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for DispatchRegionInfo 2008-04-06T08:35:19Z INFO: `anonymous-namespace'::LLEventPollResponder::LLEventPollResponder: LLEventPoll initialized with sender 8.2.35.152:13004 2008-04-06T08:35:19Z INFO: LLEventPollResponder::start <3> https://sim5850.agni.lindenlab.com:12043/cap/6a749aee-e855-9784-7198-8b8d10d52fed 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for EventQueueGet 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for GroupProposalBallot 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for MapLayer 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for MapLayerGod 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for NewFileAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ParcelPropertiesUpdate 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ParcelVoiceInfoRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ProvisionVoiceAccountRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for RemoteParcelRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatRequest 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SearchStatTracking 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendPostcard 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReport 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for SendUserReportWithScreenshot 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ServerReleaseNotes 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for StartGroupProposal 2008-04-06T08:35:19Z INFO: LLHTTPSender::setSender 8.2.35.152:13004 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UntrustedSimulatorMessage 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateGestureTaskInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for UpdateNotecardAgentInventory 2008-04-06T08:35:19Z INFO: BaseCapabilitiesComplete::result got capability for ViewerStats 2008-04-06T08:35:20Z INFO: process_enable_simulator: simulator_enable() Enabling 63.210.158.111:12035 with code 362796726 2008-04-06T08:35:20Z INFO: process_enable_simulator: simulator_enable() Enabling 216.82.19.23:12035 with code 362796726 2008-04-06T08:35:21Z ./lltexturecache.cpp(1407) : error 2008-04-06T08:35:21Z ERROR: LLTextureCache::ReadResponder::setData: ASSERT (mFormattedImage->getCodec() == imageformat) From marinekelley at gmail.com Sun Apr 6 02:15:25 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 02:15:30 2008 Subject: [sldev] 1.19.1.4 RC - Crashes after successful build In-Reply-To: <47F893E5.2090801@gmx.net> References: <47F893E5.2090801@gmx.net> Message-ID: <9e52a8c10804060215j12ed77f0l4dcde2940699a931@mail.gmail.com> I got the exact same bug, I thought it was just me. My logs are similar to yours. It seems the sources for the RC are not so close to the release client. 2008/4/6, Felix Duesenburg : > > Hi @, > > After getting the latest source to build without error, the resulting > viewer keeps crashing at various states. It can be at the very beginning, > yet before the main window is created, or shortly after login. Sometimes I > can perform a few actions like creating a prim, sometimes it fails upon the > first mouse click, or just after staying idle for a little. I cannot > reproduce whatever causes the crash, the only thing in common is that it > always crashes without exception within less than 3 minutes. > > This only happens with the self-compiled version (original source, not > done any hacking yet). The official release is stable here and has never > given me trouble. Thought they're supposed to be identical? I tried copying > the compiled viewer into the regular program directory to see if any > differences in the resource or settings files could cause problems, but the > behaviour stays the same. It also doesn't make a difference whether I use > the '-purge' option. > > Sometimes the logs show an assert failure like the one attached, sometimes > it doesn't seem to have had the time to write anything anymore before going > to byte nirvana, and the log ends without any indication of an error. Only > one thing in common I noticed: See the multiple 'UNABLE TO LOAD TEXTURE' > lines in the log, sometimes over a hundred for the same file, but the > retries counter never increases. Is that something to worry about? > > Like to make sure I didn't miss any available info about running the > viewer after a successful compile before filing a JIRA. TIA for any > pointers. > > Felix > > 2008-04-06T08:34:17Z INFO: LLAppViewer::purgeCache: Purging Texture > Cache... > 2008-04-06T08:34:17Z WARNING: ll_apr_warn_status: APR: Das System kann die > angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die > angegebene Datei nicht finden. > 2008-04-06T08:34:18Z INFO: LLAppViewer::purgeCache: Purging Cache... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking > marker file for lock... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker > file isn't locked. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Checking marker > file for lock... > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die > angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die > angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die > angegebene Datei nicht finden. > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking > marker file for lock... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker > file isn't locked. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Exec marker found: > program froze on previous execution > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file > created. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file > locked. > 2008-04-06T08:34:18Z INFO: Exiting initMarkerFile(). > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Second Life > version 1.19.1 > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Local time: > 2008-04-06T04:34:18 Eastern Sommerzeit > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: CPU info: > // CPU General Information > ////////////////////////// > Processor name: Intel Core 2 Series Processor > Frequency: 2194.50 MHz > > Vendor: GenuineIntel > Family: Intel Pentium Pro/2/3, Core > Extended family: 0 > Model: Intel Core 2 Series Processor > Extended model: 0 > Type: > Brand ID: > Processor Serial: Disabled > > > // CPU Configuration > //////////////////// > L1 instruction cache: Not present > L1 data cache: Not present > L2 cache: Not present > L3 cache: Not present > Trace cache: Not present > Instruction TLB: Not present > Data TLB: Not present > Max Supported CPUID-Level: 0x0000000A > Max Supported Ext. CPUID-Level: 0x80000008 > > > // CPU Extensions > ///////////////// > AA64 AMD 64-bit Architecture: No > ACPI Thermal Monitor And Clock Control: Yes > APIC Advanced Programmable Interrupt Controller: Yes > APIC-ID: 0 > CLFSH CLFLUSH Instruction Presence: Yes > CLFLUSH Instruction Cache Line Size: 8 > CMOV Conditional Move And Compare Instructions: Yes > CX8 COMPXCHG8B Instruction: Yes > DE Debugging Extensions: Yes > DS Debug Store: Yes > FGPAT Page Attribute Table: Yes > FPU Floating Point Unit: Yes > FXSR Fast Streaming SIMD Extensions Save/Restore: Yes > HT Hyper Threading: Yes > IA64 Intel 64-Bit Architecture: No > MCA Machine Check Architecture: Yes > MCE Machine Check Exception: Yes > MMX Multimedia Extensions: Yes > MMX+ Multimedia Extensions: No > MSR Model Specific Registers: Yes > MTRR Memory Type Range Registers: Yes > PAE Physical Address Extension: Yes > PGE PTE Global Flag: Yes > PN Processor Serial Number: Disabled > PSE Page Size Extensions: Yes > PSE36 36-bit Page Size Extension: Yes > SEP Fast System Call: Yes > SS Self Snoop: Yes > SSE Streaming SIMD Extensions: Yes > SSE2 Streaming SIMD 2 Extensions: Yes > ALTVEC Altivec Extensions: No > TM Thermal Monitor: Yes > TSC Time Stamp Counter: Yes > VME Virtual 8086 Mode Enhancements: Yes > 3DNow! Instructions: No > Enhanced 3DNow! Instructions: No > ->mHasSSE: 1 > ->mHasSSE2: 1 > ->mHasAltivec: 0 > ->mCPUMhz: 2194 > ->mCPUString: Intel Core 2 Series Processor (2194 MHz) > > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Memory info: > Percent Memory use: 51% > Total Physical KB: 2062564 > Avail Physical KB: 992572 > Total page KB: 3999448 > Avail page KB: 3029844 > Total Virtual KB: 2097024 > Avail Virtual KB: 1990832 > > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS: Microsoft > Windows XP > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS info: > Microsoft Windows XP Service Pack 2 (Build 2600) > 2008-04-06T08:34:18Z INFO: LLAppViewer::init: Loading configuration file > C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\viewerart.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from > C:\SL\1.19.1.4\workspace\linden\indra\newview\skins\textures\textures.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading base colors from > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors_base.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading user colors from > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Failed to load user colors > from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading legacy colors from > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.ini > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorization > : DISABLED > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vector Processor > : COMPILER DEFAULT > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorized Skinning > : DISABLED > 2008-04-06T08:34:19Z INFO: LLAppViewerWin32::initHardwareTest: Attempting > to poll DirectX for hardware info > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: CoCreateInstance > IID_IDxDiagProvider > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: > dx_diag_providerp->Initialize > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: > dx_diag_providerp->GetRootContainer > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: > dx_diag_rootp->GetChildContainer > 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: > devices_containerp->GetChildContainer > 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: VRAM Detected: 512 DX9 > string: 512.0 MB > 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Done > polling DirectX for hardware info > 2008-04-06T08:34:20Z WARNING: LLWinDebug::setupExceptionHandler: Our > exception handler (007D9FD0) replaced with 4F666ADA! > 2008-04-06T08:34:20Z WARNING: LLAppViewerWin32::initHardwareTest: Someone > took over my exception handler (post hardware probe)! > 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Detected > VRAM: 512 > 2008-04-06T08:34:20Z INFO: LLTextureCache::initCache: TEXTURE CACHE: > Headers: 139810 Textures size: 320 MB > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: VFS CACHE SIZE: 100 MB > 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Bad or missing vfx > index file C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 > 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Removing old vfs > data file C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente > und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 to > C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente > und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 to > C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLVFS::presizeDataFile: Pre-sized VFS data file > to 104857600 bytes > 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file > C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 and > data file C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_index.db2 > and data file > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_data.db2 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initWindow: Initializing window... > 2008-04-06T08:34:21Z WARNING: LLGLManager::initWGL: No ARB WGL render > texture extensions > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Swap Method: > Exchange > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: GL buffer: Color > Bits 32 Alpha Bits 8 Depth Bits 24 > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: Couldn't > initialize GL_EXT_paletted_texture > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Getting > symbols > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Got > symbols > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Disabling > vertical sync > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Previous gamma: 1 > 2008-04-06T08:34:21Z INFO: LLViewerWindow::LLViewerWindow: Loading feature > tables. > 2008-04-06T08:34:21Z INFO: LLFeatureManager::loadGPUClass: GPU is NVIDIA > Quadro FX > 2008-04-06T08:34:21Z INFO: LLFeatureManager::applyBaseMasks: Setting GPU > Class to Class1 > 2008-04-06T08:34:21Z INFO: LLFeatureManager::maskFeatures: Applying > Feature Mask: Class1 > 2008-04-06T08:34:21Z INFO: LLViewerImageList::doPreloadImages: Preloading > images... > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 1eddba75-b682-110a-104e-6cdcce616a25 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 1eddba75-b682-110a-104e-6cdcce616a25 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: bf0a8779-689b-48c3-bb9a-6af546366ef4 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: bf0a8779-689b-48c3-bb9a-6af546366ef4 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: bea77041-5835-1661-f298-47e2d32b7a70 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: bea77041-5835-1661-f298-47e2d32b7a70 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 > 2008-04-06T08:34:22Z INFO: decodeAllImages() took 1.33474 seconds. > fetch_pending 0 create_time 0.0295445 > 2008-04-06T08:34:24Z INFO: LLControlGroup::saveToFile: Saving settings to > file: C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:24Z INFO: LLShaderMgr::setShaders: > ~~~~~~~~~~~~~~~~~~ > Loading Shaders: > ~~~~~~~~~~~~~~~~~~ > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/atmosphericsVarsV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/atmosphericsHelpersV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsHelpersV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightFuncV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/sumLightsV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightFuncSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/sumLightsSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/atmosphericsV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarSkinV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarSkinV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/atmosphericsVarsF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/gammaF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/gammaF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/atmosphericsF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: windlight/transportF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/transportF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/waterFogF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterFogF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightFullbrightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightFullbrightWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightShinyF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightFullbrightShinyF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightShinyF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: lighting/lightShinyWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/waterV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/waterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 1 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/waterV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/underWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/underWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/terrainV.glsl class 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file > not found: environment/terrainV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: environment/terrainWaterF.glsl class 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file > not found: environment/terrainWaterF.glsl > 2008-04-06T08:34:24Z WARNING: LLGLSLShader::createShader: Failed to link > shader: Terrain Water Shader > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: effects/glowV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: effects/glowF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: effects/glowExtractV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: effects/glowExtractF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: interface/highlightV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: interface/highlightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: objects/simpleWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/pickAvatarV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/pickAvatarF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/eyeballV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/eyeballF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: objects/simpleWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/pickAvatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/pickAvatarF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/eyeballV.glsl class 1 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballV.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader > file: avatar/eyeballF.glsl class 1 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: > Assigned to texture channel 0 > 2008-04-06T08:34:25Z INFO: LLControlGroup::saveToFile: Saving settings to > file: C:\Dokumente und > Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:25Z INFO: GL_VENDOR NVIDIA Corporation > GL_RENDERER Quadro FX 570M/PCI/SSE2 > GL_VERSION 2.1.1 > GL_EXTENSIONS: > GL_ARB_color_buffer_float > GL_ARB_depth_texture > GL_ARB_draw_buffers > GL_ARB_fragment_program > GL_ARB_fragment_program_shadow > GL_ARB_fragment_shader > GL_ARB_half_float_pixel > GL_ARB_imaging > GL_ARB_multisample > GL_ARB_multitexture > GL_ARB_occlusion_query > GL_ARB_pixel_buffer_object > GL_ARB_point_parameters > GL_ARB_point_sprite > GL_ARB_shadow > GL_ARB_shader_objects > GL_ARB_shading_language_100 > GL_ARB_texture_border_clamp > GL_ARB_texture_compression > GL_ARB_texture_cube_map > GL_ARB_texture_env_add > GL_ARB_texture_env_combine > GL_ARB_texture_env_dot3 > GL_ARB_texture_float > GL_ARB_texture_mirrored_repeat > GL_ARB_texture_non_power_of_two > GL_ARB_texture_rectangle > GL_ARB_transpose_matrix > GL_ARB_vertex_buffer_object > GL_ARB_vertex_program > GL_ARB_vertex_shader > GL_ARB_window_pos > GL_ATI_draw_buffers > GL_ATI_texture_float > GL_ATI_texture_mirror_once > GL_S3_s3tc > GL_EXT_texture_env_add > GL_EXT_abgr > GL_EXT_bgra > GL_EXT_blend_color > GL_EXT_blend_equation_separate > GL_EXT_blend_func_separate > GL_EXT_blend_minmax > GL_EXT_blend_subtract > GL_EXT_compiled_vertex_array > GL_EXT_Cg_shader > GL_EXT_bindable_uniform > GL_EXT_depth_bounds_test > GL_EXT_draw_buffers2 > GL_EXT_draw_instanced > GL_EXT_draw_range_elements > GL_EXT_fog_coord > GL_EXT_framebuffer_blit > GL_EXT_framebuffer_multisample > GL_EXT_framebuffer_object > GL_EXTX_framebuffer_mixed_formats > GL_EXT_framebuffer_sRGB > GL_EXT_geometry_shader4 > GL_EXT_gpu_program_parameters > GL_EXT_gpu_shader4 > GL_EXT_multi_draw_arrays > GL_EXT_packed_depth_stencil > GL_EXT_packed_float > GL_EXT_packed_pixels > GL_EXT_pixel_buffer_object > GL_EXT_point_parameters > GL_EXT_rescale_normal > GL_EXT_secondary_color > GL_EXT_separate_specular_color > GL_EXT_shadow_funcs > GL_EXT_stencil_two_side > GL_EXT_stencil_wrap > GL_EXT_texture3D > GL_EXT_texture_array > GL_EXT_texture_buffer_object > GL_EXT_texture_compression_latc > GL_EXT_texture_compression_rgtc > GL_EXT_texture_compression_s3tc > GL_EXT_texture_cube_map > GL_EXT_texture_edge_clamp > GL_EXT_texture_env_combine > GL_EXT_texture_env_dot3 > GL_EXT_texture_filter_anisotropic > GL_EXT_texture_integer > GL_EXT_texture_lod > GL_EXT_texture_lod_bias > GL_EXT_texture_mirror_clamp > GL_EXT_texture_object > GL_EXT_texture_sRGB > GL_EXT_texture_shared_exponent > GL_EXT_timer_query > GL_EXT_vertex_array > GL_IBM_rasterpos_clip > GL_IBM_texture_mirrored_repeat > GL_KTX_buffer_region > GL_NV_blend_square > GL_NV_copy_depth_to_color > GL_NV_depth_buffer_float > GL_NV_conditional_render > GL_NV_depth_clamp > GL_NV_fence > GL_NV_float_buffer > GL_NV_fog_distance > GL_NV_fragment_program > GL_NV_fragment_program_option > GL_NV_fragment_program2 > GL_NV_framebuffer_multisample_coverage > GL_NV_geometry_shader4 > GL_NV_gpu_program4 > GL_NV_half_float > GL_NV_light_max_exponent > GL_NV_multisample_filter_hint > GL_NV_occlusion_query > GL_NV_packed_depth_stencil > GL_NV_parameter_buffer_object > GL_NV_pixel_data_range > GL_NV_point_sprite > GL_NV_primitive_restart > GL_NV_register_combiners > GL_NV_register_combiners2 > GL_NV_texgen_reflection > GL_NV_texture_compression_vtc > GL_NV_texture_env_combine4 > GL_NV_texture_expand_normal > GL_NV_texture_rectangle > GL_NV_texture_shader > GL_NV_texture_shader2 > GL_NV_texture_shader3 > GL_NV_transform_feedback > GL_NV_vertex_array_range > GL_NV_vertex_array_range2 > GL_NV_vertex_program > GL_NV_vertex_program1_1 > GL_NV_vertex_program2 > GL_NV_vertex_program2_option > GL_NV_vertex_program3 > GL_NVX_conditional_render > GL_SGIS_generate_mipmap > GL_SGIS_texture_lod > GL_SGIX_depth_texture > GL_SGIX_shadow > GL_SUN_slice_accum > GL_WIN_swap_hint > WGL_EXT_swap_control > GL_Autodesk_valid_back_buffer_hint > > WGL_ARB_buffer_region > WGL_ARB_extensions_string > WGL_ARB_make_current_read > WGL_ARB_multisample > WGL_ARB_pbuffer > WGL_ARB_pixel_format > WGL_ARB_pixel_format_float > WGL_ARB_render_texture > WGL_ATI_pixel_format_float > WGL_EXT_extensions_string > WGL_EXT_framebuffer_sRGB > WGL_EXT_pixel_format_packed_float > WGL_EXT_swap_control > WGL_I3D_genlock > WGL_NV_float_buffer > WGL_NV_gpu_affinity > WGL_NV_render_depth_texture > WGL_NV_render_texture_rectangle > WGL_NV_swap_group > > > > 2008-04-06T08:34:25Z INFO: LLAppViewer::init: Viewer Digest: > 335acf7c-1908-df4d-b05f-bc0574e907e4 > 2008-04-06T08:34:25Z INFO: LLVoiceClient::setState: entering state > stateDisabled > 2008-04-06T08:34:25Z INFO: LLVoiceClient::switchChannel: called in state > stateDisabled with uri "" > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Resend: 150 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Land: 130 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Wind: 26 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Cloud: 26 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Task: 484 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Texture: 484 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Asset: 200 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Total: 1500 > 2008-04-06T08:34:26Z INFO: idle_startup: Initializing messaging system... > 2008-04-06T08:34:26Z INFO: LLTemplateParser::LLTemplateParser: ### Message > template version 2 ### > 2008-04-06T08:34:26Z INFO: start_net: attempting to connect on port 0 > 2008-04-06T08:34:26Z INFO: start_net: connected on port 1503 > 2008-04-06T08:34:26Z INFO: start_net: startNet - receive buffer size : > 400000 > 2008-04-06T08:34:26Z INFO: start_net: startNet - send buffer size : > 400000 > 2008-04-06T08:34:26Z INFO: start_messaging_system: Message template > version matches prehash version number > 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadFile: Loading > message.xml file at > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml > 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadCapBans: 25 ban tests > 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: > 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: no > messages banned > 2008-04-06T08:34:26Z INFO: LLMessageConfig::initClass config file > C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager > ack throttle min rate: 2.66667e+006 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager > ack throttle actual rate: 2.93333e+006 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager > ack throttle min rate: 8000 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager > ack throttle actual rate: 150000 > 2008-04-06T08:34:26Z INFO: LLAssetStorage::setUpstream: AssetStorage: > Setting upstream provider to 0.0.0.0:0 > 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() initializing FMOD > 2008-04-06T08:34:26Z WARNING: LLAudioEngine_FMOD::init: Error : You are > using the wrong FMOD version (3.74)! You should be using FMOD 3.75 > 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() FMOD initialized > correctly > 2008-04-06T08:34:26Z INFO: LLStartUp::setStartupState: Startup state > changing from 0 to 1 > 2008-04-06T08:34:26Z INFO: idle_startup: Initializing Multimedia.... > 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state > changing from 1 to 2 > 2008-04-06T08:34:29Z WARNING: LLWinDebug::setupExceptionHandler: Our > exception handler (007D9FD0) replaced with 6681F570! > 2008-04-06T08:34:29Z WARNING: LLAppViewer::mainLoop: Someone took over my > exception handler (post messagehandling)! > 2008-04-06T08:34:29Z INFO: idle_startup: Initializing Window > 2008-04-06T08:34:29Z WARNING: Attempted getFields with no login view shown > 2008-04-06T08:34:29Z INFO: login_show: Initializing Login Screen > 2008-04-06T08:34:29Z WARNING: LLWebBrowserCtrl::navigateToLocalPage: File > loading\loading.htmlnot found > 2008-04-06T08:34:29Z INFO: login_show: Setting Servers > 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state > changing from 2 to 3 > 2008-04-06T08:34:30Z INFO: LLAudioEngine::startNextTransfer: Getting asset > data for: c80260ba-41fd-8a46-768a-6bf236360e3a > 2008-04-06T08:34:30Z WARNING: LLAssetStorage::_queueDataRequest: Attempt > to move asset data request upstream w/o valid upstream provider > 2008-04-06T08:34:30Z INFO: LLAudioEngine::assetCallback: Boom, error in > audio file transfer: Circuit gone (-23017) > 2008-04-06T08:34:38Z INFO: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR > parsing:HTTP/1.0 200 OK > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD > TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:47Z WARNING: LLTextureFetchWorker::decodeImage: DECODE > FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/cdee3b6e/attachment-0001.htm From kfa at gmx.net Sun Apr 6 02:33:51 2008 From: kfa at gmx.net (Klaus F. Abel) Date: Sun Apr 6 02:34:03 2008 Subject: [sldev] 1.19.1.4 RC - Crashes after successful build In-Reply-To: <9e52a8c10804060215j12ed77f0l4dcde2940699a931@mail.gmail.com> References: <47F893E5.2090801@gmx.net> <9e52a8c10804060215j12ed77f0l4dcde2940699a931@mail.gmail.com> Message-ID: <47F898FF.1010001@gmx.net> I ran a diff to compare the release download with the OS version, and got the attached result after stripping any intermediate build files. There are some differences in the supporting libraries and the artwork. As for the source, that would have to be verified by a Linden, but didn't Rob mention already they were identical with one little exception given in his 1-19-1-Viewer-RC-to-gold.patch. Btw, forgot to mention I also applied this patch but it had no influence on the crash behaviour either. Marine Kelley wrote: > I got the exact same bug, I thought it was just me. My logs are > similar to yours. It seems the sources for the RC are not so close to > the release client. > > > > 2008/4/6, Felix Duesenburg >: > > ... > -------------- next part -------------- Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: AutoUpdater-Info.plist Only in C:\Programme\SecondLife: Client Security Solution Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: CrashReporter.nib Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: English.lproj Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: Info-SecondLife.plist Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: Info-SecondLifeVorbis.plist Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: OpenJPEG.dll Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: ReleaseForDownload Only in C:\Programme\SecondLife: Second Life.lnk Files C:\Programme\SecondLife/SecondLife.exe and C:\SL\1.19.1.4\workspace\linden\indra\newview/SecondLife.exe differ Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: SecondLife.nib Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: SecondLife.pdb Only in C:\Programme\SecondLife: Uninstall Second Life.lnk Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: Verkn?pfung mit SecondLife.exe.lnk Only in C:\Programme\SecondLife/app_settings: colors_base.ini Only in C:\SL\1.19.1.4\workspace\linden\indra\newview/app_settings: mozilla_debug Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: crashreporter-Info.plist Only in C:\Programme\SecondLife: dbghelp.dll Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: diff Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: featuretable_linux.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: featuretable_mac.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: featuretable_solaris.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: files.lst Files C:\Programme\SecondLife/fmod.dll and C:\SL\1.19.1.4\workspace\linden\indra\newview/fmod.dll differ Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: fmod_hidden_symbols.exp Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: installers Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: licenses-linux.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: licenses-mac.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: licenses-solaris.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: licenses-win32.txt Only in C:\Programme\SecondLife: licenses.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: linux_tools Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: llface.inl Files C:\Programme\SecondLife/llkdu.dll and C:\SL\1.19.1.4\workspace\linden\indra\newview/llkdu.dll differ Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: macview.xcodeproj Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: mozilla-powerpc-darwin-readme.txt Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: mozilla-theme Only in C:\Programme\SecondLife: msvcp71.dll Only in C:\Programme\SecondLife: msvcr71.dll Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: newViewRes.res Only in C:\Programme\SecondLife: openjpeg.dll Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: postbuild.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: prebuild.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: res Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: res-sdl Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build A08T01.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build B08T01.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build aditi.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build agni.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build aruna.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build dmz.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build durga.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build firstlookwindlight.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build ganga.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build mitra.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build mohini.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build nandi.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build radha.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build ravi.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build release candidate.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build shakti.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build siva.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build soma.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build uma.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build vaak.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build voicebeta.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build voicefirstlook.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build yami.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife setup build.bat Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: secondlife-i686.supp Only in C:\Programme\SecondLife/skins: html Only in C:\Programme\SecondLife/skins/textures: .BridgeLabelsAndRatings Only in C:\Programme\SecondLife/skins/textures: 07d1f523-e327-4d10-20d6-8bc22a6e8f56.tga Only in C:\Programme\SecondLife/skins/textures: 0e058115-5b8f-c3d7-dcaa-9623d92885d1.tga Only in C:\Programme\SecondLife/skins/textures: 175a6b75-45c9-c2c2-4765-bf37a3909b53.tga Only in C:\Programme\SecondLife/skins/textures: 4cc1afcd-04dd-178f-e074-0f9dc730ab45.tga Only in C:\Programme\SecondLife/skins/textures: 5863eb7a-1546-6501-533a-6061f73a36b7.tga Only in C:\Programme\SecondLife/skins/textures: beb0d821-6725-abdf-032d-1f70cdabde82.tga Only in C:\Programme\SecondLife/skins/textures: c49b0b3b-fe04-46ee-abab-777fa0b462b6.tga Only in C:\Programme\SecondLife/skins/textures: eb510e2b-3815-4434-b502-b18712db65cc.tga Only in C:\Programme\SecondLife/skins/xui/de: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui/en-us: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui/en-us: panel_preferences_graphics2.xml Only in C:\Programme\SecondLife/skins/xui/en-us: panel_preferences_graphics3.xml Only in C:\Programme\SecondLife/skins/xui/es: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui/fr: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui/ja: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui/ko: floater_html_help.xml Only in C:\Programme\SecondLife/skins/xui: pt Only in C:\Programme\SecondLife/skins/xui/zh: floater_html_help.xml Only in C:\Programme\SecondLife: uninst.exe Only in C:\Programme\SecondLife: updater.exe Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: viewer_manifest.py Only in C:\SL\1.19.1.4\workspace\linden\indra\newview: vivox-runtime Only in C:\Programme\SecondLife: win_crash_logger.exe From kaleajinkya at gmail.com Sun Apr 6 03:18:55 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 03:19:01 2008 Subject: [sldev] lscript_compile error Message-ID: Hi, Can anyone please suggest me any work around for the llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to compile the viewer due to these errors. On Sun, Apr 6, 2008 at 2:12 AM, wrote: > Send SLDev mailing list submissions to > sldev@lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > or, via email, send a message with subject or body 'help' to > sldev-request@lists.secondlife.com > > You can reach the person managing the list at > sldev-owner@lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SLDev digest..." > > > Today's Topics: > > 1. Re: 1.19.1 release source (Felix Duesenburg) > 2. Re: 1.19.1 release source (Soft) > 3. RE: 1.19.1 release source (Matthew Dowd) > 4. llcompilequeue.obj and llpreviewscript.obj errors (Ajinkya Kale) > 5. 1.19.1.4 RC - Crashes after successful build (Felix Duesenburg) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 05 Apr 2008 15:09:08 -0400 > From: Felix Duesenburg > Subject: Re: [sldev] 1.19.1 release source > To: Soft > Cc: sldev > Message-ID: <47F7CE54.1080403@gmx.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Soft wrote: > > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd wrote: > > > >> There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. > >> > > > > Could you provide a link on that, or encourage the poster to file it > > as a JIRA patch to clear licensing concerns? > > _______________________________________________ > > > That reminds me to ask - sorry if I overlooked this was covered already > - is it still needed to submit the source code contribution agreement > before sending anything as explained on the wiki, or has this become > obsolete with the remark there on the JIRA? > > Thanks > > > ------------------------------ > > Message: 2 > Date: Sat, 5 Apr 2008 14:19:12 -0500 > From: Soft > Subject: Re: [sldev] 1.19.1 release source > To: "Felix Duesenburg" > Cc: sldev > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > If it's a very simple change that strictly tweaks existing code or > assets, we may use the change without follow-up. If it's a substantial > change, we follow up privately with a contributor agreement. This is > needed not only to cover us, but to cover others who use the code > under a GPL license. The GPL nightmare scenario sees a patch with > improperly licensed code being integrated and polluting every viewer. > This puts not just us, but Henri, Marine, Dale, Nicholaz, Robin, and > many others in harm's way. > > On Sat, Apr 5, 2008 at 2:09 PM, Felix Duesenburg wrote: > > Soft wrote: > > > > > > > > > > > > > > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd > > wrote: > > > > > > > > > > There was a suitable "slate" scheme for the Dazzle firstlook posted in > > the forums. > > > > > > > > > > > > > > Could you provide a link on that, or encourage the poster to file it > > > as a JIRA patch to clear licensing concerns? > > > _______________________________________________ > > > > > > > > That reminds me to ask - sorry if I overlooked this was covered already - > > is it still needed to submit the source code contribution agreement before > > sending anything as explained on the wiki, or has this become obsolete with > > the remark there on the JIRA? > > > > Thanks > > > > > ------------------------------ > > Message: 3 > Date: Sat, 5 Apr 2008 21:07:35 +0000 > From: Matthew Dowd > Subject: RE: [sldev] 1.19.1 release source > To: Soft > Cc: sldev > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > > OK, I've tracked the forum thread down: > > http://forums.secondlife.com/showthread.php?t=242483 > > Matthew > > ---------------------------------------- > > Date: Sat, 5 Apr 2008 13:49:23 -0500 > > From: soft@lindenlab.com > > To: matthew.dowd@hotmail.co.uk > > Subject: Re: [sldev] 1.19.1 release source > > CC: sldev@lists.secondlife.com > > > > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd wrote: > >> > >> There was a suitable "slate" scheme for the Dazzle firstlook posted in the forums. > > > > Could you provide a link on that, or encourage the poster to file it > > as a JIRA patch to clear licensing concerns? > > _________________________________________________________________ > Welcome to the next generation of Windows Live > http://www.windowslive.co.uk/get-live > > ------------------------------ > > Message: 4 > Date: Sat, 5 Apr 2008 22:59:51 -0700 > From: "Ajinkya Kale" > Subject: [sldev] llcompilequeue.obj and llpreviewscript.obj errors > To: sldev@lists.secondlife.com > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > I am getting the following llcompilequeue.obj and llpreviewscript.obj > errors. I being a bit desparate ! Can anyone please let me know a > solution for resolving these errors ? > > 1>------ Build started: Project: newview, Configuration: > ReleaseForDownload Win32 ------ > 1>Executing pre-build batch file > 1>PREBUILD SUCCESSFUL > 1>Linking... > 1>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void __thiscall LLFloaterCompileQueue::compile(char const *,class > LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > 1>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > 1>ReleaseForDownload/SecondLife.exe : fatal error LNK1120: 1 > unresolved externals > 1>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > 1>newview - 3 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== > > Thanks a lot. > > -- > Ajinkya > > > ------------------------------ > > Message: 5 > Date: Sun, 06 Apr 2008 05:12:05 -0400 > From: Felix Duesenburg > Subject: [sldev] 1.19.1.4 RC - Crashes after successful build > To: sldev@lists.secondlife.com > Message-ID: <47F893E5.2090801@gmx.net> > Content-Type: text/plain; charset="iso-8859-1" > > Hi @, > > After getting the latest source to build without error, the resulting > viewer keeps crashing at various states. It can be at the very > beginning, yet before the main window is created, or shortly after > login. Sometimes I can perform a few actions like creating a prim, > sometimes it fails upon the first mouse click, or just after staying > idle for a little. I cannot reproduce whatever causes the crash, the > only thing in common is that it always crashes without exception within > less than 3 minutes. > > This only happens with the self-compiled version (original source, not > done any hacking yet). The official release is stable here and has never > given me trouble. Thought they're supposed to be identical? I tried > copying the compiled viewer into the regular program directory to see if > any differences in the resource or settings files could cause problems, > but the behaviour stays the same. It also doesn't make a difference > whether I use the '-purge' option. > > Sometimes the logs show an assert failure like the one attached, > sometimes it doesn't seem to have had the time to write anything anymore > before going to byte nirvana, and the log ends without any indication of > an error. Only one thing in common I noticed: See the multiple 'UNABLE > TO LOAD TEXTURE' lines in the log, sometimes over a hundred for the same > file, but the retries counter never increases. Is that something to > worry about? > > Like to make sure I didn't miss any available info about running the > viewer after a successful compile before filing a JIRA. TIA for any > pointers. > > Felix > -------------- next part -------------- > 2008-04-06T08:34:17Z INFO: LLAppViewer::purgeCache: Purging Texture Cache... > 2008-04-06T08:34:17Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. > 2008-04-06T08:34:18Z INFO: LLAppViewer::purgeCache: Purging Cache... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Checking marker file for lock... > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. > 2008-04-06T08:34:18Z WARNING: ll_apr_warn_status: APR: Das System kann die angegebene Datei nicht finden. > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... > 2008-04-06T08:34:18Z INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Exec marker found: program froze on previous execution > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file created. > 2008-04-06T08:34:18Z INFO: LLAppViewer::initMarkerFile: Marker file locked. > 2008-04-06T08:34:18Z INFO: Exiting initMarkerFile(). > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Second Life version 1.19.1 > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Local time: 2008-04-06T04:34:18 Eastern Sommerzeit > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: CPU info: > // CPU General Information > ////////////////////////// > Processor name: Intel Core 2 Series Processor > Frequency: 2194.50 MHz > > Vendor: GenuineIntel > Family: Intel Pentium Pro/2/3, Core > Extended family: 0 > Model: Intel Core 2 Series Processor > Extended model: 0 > Type: > Brand ID: > Processor Serial: Disabled > > > // CPU Configuration > //////////////////// > L1 instruction cache: Not present > L1 data cache: Not present > L2 cache: Not present > L3 cache: Not present > Trace cache: Not present > Instruction TLB: Not present > Data TLB: Not present > Max Supported CPUID-Level: 0x0000000A > Max Supported Ext. CPUID-Level: 0x80000008 > > > // CPU Extensions > ///////////////// > AA64 AMD 64-bit Architecture: No > ACPI Thermal Monitor And Clock Control: Yes > APIC Advanced Programmable Interrupt Controller: Yes > APIC-ID: 0 > CLFSH CLFLUSH Instruction Presence: Yes > CLFLUSH Instruction Cache Line Size: 8 > CMOV Conditional Move And Compare Instructions: Yes > CX8 COMPXCHG8B Instruction: Yes > DE Debugging Extensions: Yes > DS Debug Store: Yes > FGPAT Page Attribute Table: Yes > FPU Floating Point Unit: Yes > FXSR Fast Streaming SIMD Extensions Save/Restore: Yes > HT Hyper Threading: Yes > IA64 Intel 64-Bit Architecture: No > MCA Machine Check Architecture: Yes > MCE Machine Check Exception: Yes > MMX Multimedia Extensions: Yes > MMX+ Multimedia Extensions: No > MSR Model Specific Registers: Yes > MTRR Memory Type Range Registers: Yes > PAE Physical Address Extension: Yes > PGE PTE Global Flag: Yes > PN Processor Serial Number: Disabled > PSE Page Size Extensions: Yes > PSE36 36-bit Page Size Extension: Yes > SEP Fast System Call: Yes > SS Self Snoop: Yes > SSE Streaming SIMD Extensions: Yes > SSE2 Streaming SIMD 2 Extensions: Yes > ALTVEC Altivec Extensions: No > TM Thermal Monitor: Yes > TSC Time Stamp Counter: Yes > VME Virtual 8086 Mode Enhancements: Yes > 3DNow! Instructions: No > Enhanced 3DNow! Instructions: No > ->mHasSSE: 1 > ->mHasSSE2: 1 > ->mHasAltivec: 0 > ->mCPUMhz: 2194 > ->mCPUString: Intel Core 2 Series Processor (2194 MHz) > > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: Memory info: > Percent Memory use: 51% > Total Physical KB: 2062564 > Avail Physical KB: 992572 > Total page KB: 3999448 > Avail page KB: 3029844 > Total Virtual KB: 2097024 > Avail Virtual KB: 1990832 > > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS: Microsoft Windows XP > 2008-04-06T08:34:18Z INFO: LLAppViewer::writeSystemInfo: OS info: Microsoft Windows XP Service Pack 2 (Build 2600) > 2008-04-06T08:34:18Z INFO: LLAppViewer::init: Loading configuration file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\viewerart.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading art table from C:\SL\1.19.1.4\workspace\linden\indra\newview\skins\textures\textures.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading base colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors_base.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading user colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Failed to load user colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.xml > 2008-04-06T08:34:19Z INFO: LLAppViewer::init: Loading legacy colors from C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\colors.ini > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorization : DISABLED > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT > 2008-04-06T08:34:19Z INFO: update_vector_performances: Vectorized Skinning : DISABLED > 2008-04-06T08:34:19Z INFO: LLAppViewerWin32::initHardwareTest: Attempting to poll DirectX for hardware info > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: CoCreateInstance IID_IDxDiagProvider > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_providerp->Initialize > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_providerp->GetRootContainer > 2008-04-06T08:34:19Z INFO: LLDXHardware::getInfo: dx_diag_rootp->GetChildContainer > 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: devices_containerp->GetChildContainer > 2008-04-06T08:34:20Z INFO: LLDXHardware::getInfo: VRAM Detected: 512 DX9 string: 512.0 MB > 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Done polling DirectX for hardware info > 2008-04-06T08:34:20Z WARNING: LLWinDebug::setupExceptionHandler: Our exception handler (007D9FD0) replaced with 4F666ADA! > 2008-04-06T08:34:20Z WARNING: LLAppViewerWin32::initHardwareTest: Someone took over my exception handler (post hardware probe)! > 2008-04-06T08:34:20Z INFO: LLAppViewerWin32::initHardwareTest: Detected VRAM: 512 > 2008-04-06T08:34:20Z INFO: LLTextureCache::initCache: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: VFS CACHE SIZE: 100 MB > 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Bad or missing vfx index file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 > 2008-04-06T08:34:20Z WARNING: LLAppViewer::initCache: Removing old vfs data file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.14594 to C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initCache: Renaming C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.14594 to C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLVFS::presizeDataFile: Pre-sized VFS data file to 104857600 bytes > 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\index.db2.x.20048 and data file C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\cache\data.db2.x.20048 > 2008-04-06T08:34:20Z INFO: LLVFS::LLVFS: VFS: Using index file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_index.db2 and data file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\static_data.db2 > 2008-04-06T08:34:20Z INFO: LLAppViewer::initWindow: Initializing window... > 2008-04-06T08:34:21Z WARNING: LLGLManager::initWGL: No ARB WGL render texture extensions > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Swap Method: Exchange > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: GL buffer: Color Bits 32 Alpha Bits 8 Depth Bits 24 > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: Couldn't initialize GL_EXT_paletted_texture > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Getting symbols > 2008-04-06T08:34:21Z INFO: LLGLManager::initExtensions: GL Probe: Got symbols > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Disabling vertical sync > 2008-04-06T08:34:21Z INFO: LLWindowWin32::LLWindowWin32: Previous gamma: 1 > 2008-04-06T08:34:21Z INFO: LLViewerWindow::LLViewerWindow: Loading feature tables. > 2008-04-06T08:34:21Z INFO: LLFeatureManager::loadGPUClass: GPU is NVIDIA Quadro FX > 2008-04-06T08:34:21Z INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class1 > 2008-04-06T08:34:21Z INFO: LLFeatureManager::maskFeatures: Applying Feature Mask: Class1 > 2008-04-06T08:34:21Z INFO: LLViewerImageList::doPreloadImages: Preloading images... > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1eddba75-b682-110a-104e-6cdcce616a25 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1eddba75-b682-110a-104e-6cdcce616a25 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: bf0a8779-689b-48c3-bb9a-6af546366ef4 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: bf0a8779-689b-48c3-bb9a-6af546366ef4 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c001d8fd-a869-4b6f-86a1-fdcb106df9c7 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: bea77041-5835-1661-f298-47e2d32b7a70 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: bea77041-5835-1661-f298-47e2d32b7a70 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 > 2008-04-06T08:34:22Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 > 2008-04-06T08:34:22Z INFO: decodeAllImages() took 1.33474 seconds. fetch_pending 0 create_time 0.0295445 > 2008-04-06T08:34:24Z INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:24Z INFO: LLShaderMgr::setShaders: > ~~~~~~~~~~~~~~~~~~ > Loading Shaders: > ~~~~~~~~~~~~~~~~~~ > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsVarsV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsHelpersV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsHelpersV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFuncV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/sumLightsV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFuncSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFuncSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/lighting/lightFuncSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/sumLightsSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/sumLightsSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightSpecularV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightSpecularV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarSkinV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarSkinV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsVarsF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsVarsF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/gammaF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/gammaF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/atmosphericsF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/atmosphericsF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: windlight/transportF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/windlight/transportF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterFogF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterFogF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightShinyF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightFullbrightShinyF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightFullbrightShinyF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: lighting/lightShinyWaterF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/lighting/lightShinyWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 1 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/waterV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/waterV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/underWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/environment/underWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/terrainV.glsl class 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file not found: environment/terrainV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: environment/terrainWaterF.glsl class 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: GLSL Shader file not found: environment/terrainWaterF.glsl > 2008-04-06T08:34:24Z WARNING: LLGLSLShader::createShader: Failed to link shader: Terrain Water Shader > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowExtractV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: effects/glowExtractF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/effects/glowExtractF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: interface/highlightV.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: interface/highlightF.glsl class 2 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/interface/highlightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/interface/highlightF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: objects/simpleWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballV.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballF.glsl class 3 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class3/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class2/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/avatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/avatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: objects/simpleWaterF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/objects/simpleWaterF.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:24Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarV.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarV.glsl > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/pickAvatarF.glsl class 1 > 2008-04-06T08:34:24Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/pickAvatarF.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballV.glsl class 1 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballV.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Loading shader file: avatar/eyeballF.glsl class 1 > 2008-04-06T08:34:25Z INFO: LLShaderMgr::loadShaderFile: Looking in C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings\shaders/class1/avatar/eyeballF.glsl > 2008-04-06T08:34:25Z INFO: LLShaderMgr::dumpObjectLog: > 2008-04-06T08:34:25Z INFO: LLGLSLShader::mapUniformTextureChannel: Assigned to texture channel 0 > 2008-04-06T08:34:25Z INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Dokumente und Einstellungen\User\Anwendungsdaten\SecondLife\user_settings\settings.xml > 2008-04-06T08:34:25Z INFO: GL_VENDOR NVIDIA Corporation > GL_RENDERER Quadro FX 570M/PCI/SSE2 > GL_VERSION 2.1.1 > GL_EXTENSIONS: > GL_ARB_color_buffer_float > GL_ARB_depth_texture > GL_ARB_draw_buffers > GL_ARB_fragment_program > GL_ARB_fragment_program_shadow > GL_ARB_fragment_shader > GL_ARB_half_float_pixel > GL_ARB_imaging > GL_ARB_multisample > GL_ARB_multitexture > GL_ARB_occlusion_query > GL_ARB_pixel_buffer_object > GL_ARB_point_parameters > GL_ARB_point_sprite > GL_ARB_shadow > GL_ARB_shader_objects > GL_ARB_shading_language_100 > GL_ARB_texture_border_clamp > GL_ARB_texture_compression > GL_ARB_texture_cube_map > GL_ARB_texture_env_add > GL_ARB_texture_env_combine > GL_ARB_texture_env_dot3 > GL_ARB_texture_float > GL_ARB_texture_mirrored_repeat > GL_ARB_texture_non_power_of_two > GL_ARB_texture_rectangle > GL_ARB_transpose_matrix > GL_ARB_vertex_buffer_object > GL_ARB_vertex_program > GL_ARB_vertex_shader > GL_ARB_window_pos > GL_ATI_draw_buffers > GL_ATI_texture_float > GL_ATI_texture_mirror_once > GL_S3_s3tc > GL_EXT_texture_env_add > GL_EXT_abgr > GL_EXT_bgra > GL_EXT_blend_color > GL_EXT_blend_equation_separate > GL_EXT_blend_func_separate > GL_EXT_blend_minmax > GL_EXT_blend_subtract > GL_EXT_compiled_vertex_array > GL_EXT_Cg_shader > GL_EXT_bindable_uniform > GL_EXT_depth_bounds_test > GL_EXT_draw_buffers2 > GL_EXT_draw_instanced > GL_EXT_draw_range_elements > GL_EXT_fog_coord > GL_EXT_framebuffer_blit > GL_EXT_framebuffer_multisample > GL_EXT_framebuffer_object > GL_EXTX_framebuffer_mixed_formats > GL_EXT_framebuffer_sRGB > GL_EXT_geometry_shader4 > GL_EXT_gpu_program_parameters > GL_EXT_gpu_shader4 > GL_EXT_multi_draw_arrays > GL_EXT_packed_depth_stencil > GL_EXT_packed_float > GL_EXT_packed_pixels > GL_EXT_pixel_buffer_object > GL_EXT_point_parameters > GL_EXT_rescale_normal > GL_EXT_secondary_color > GL_EXT_separate_specular_color > GL_EXT_shadow_funcs > GL_EXT_stencil_two_side > GL_EXT_stencil_wrap > GL_EXT_texture3D > GL_EXT_texture_array > GL_EXT_texture_buffer_object > GL_EXT_texture_compression_latc > GL_EXT_texture_compression_rgtc > GL_EXT_texture_compression_s3tc > GL_EXT_texture_cube_map > GL_EXT_texture_edge_clamp > GL_EXT_texture_env_combine > GL_EXT_texture_env_dot3 > GL_EXT_texture_filter_anisotropic > GL_EXT_texture_integer > GL_EXT_texture_lod > GL_EXT_texture_lod_bias > GL_EXT_texture_mirror_clamp > GL_EXT_texture_object > GL_EXT_texture_sRGB > GL_EXT_texture_shared_exponent > GL_EXT_timer_query > GL_EXT_vertex_array > GL_IBM_rasterpos_clip > GL_IBM_texture_mirrored_repeat > GL_KTX_buffer_region > GL_NV_blend_square > GL_NV_copy_depth_to_color > GL_NV_depth_buffer_float > GL_NV_conditional_render > GL_NV_depth_clamp > GL_NV_fence > GL_NV_float_buffer > GL_NV_fog_distance > GL_NV_fragment_program > GL_NV_fragment_program_option > GL_NV_fragment_program2 > GL_NV_framebuffer_multisample_coverage > GL_NV_geometry_shader4 > GL_NV_gpu_program4 > GL_NV_half_float > GL_NV_light_max_exponent > GL_NV_multisample_filter_hint > GL_NV_occlusion_query > GL_NV_packed_depth_stencil > GL_NV_parameter_buffer_object > GL_NV_pixel_data_range > GL_NV_point_sprite > GL_NV_primitive_restart > GL_NV_register_combiners > GL_NV_register_combiners2 > GL_NV_texgen_reflection > GL_NV_texture_compression_vtc > GL_NV_texture_env_combine4 > GL_NV_texture_expand_normal > GL_NV_texture_rectangle > GL_NV_texture_shader > GL_NV_texture_shader2 > GL_NV_texture_shader3 > GL_NV_transform_feedback > GL_NV_vertex_array_range > GL_NV_vertex_array_range2 > GL_NV_vertex_program > GL_NV_vertex_program1_1 > GL_NV_vertex_program2 > GL_NV_vertex_program2_option > GL_NV_vertex_program3 > GL_NVX_conditional_render > GL_SGIS_generate_mipmap > GL_SGIS_texture_lod > GL_SGIX_depth_texture > GL_SGIX_shadow > GL_SUN_slice_accum > GL_WIN_swap_hint > WGL_EXT_swap_control > GL_Autodesk_valid_back_buffer_hint > > WGL_ARB_buffer_region > WGL_ARB_extensions_string > WGL_ARB_make_current_read > WGL_ARB_multisample > WGL_ARB_pbuffer > WGL_ARB_pixel_format > WGL_ARB_pixel_format_float > WGL_ARB_render_texture > WGL_ATI_pixel_format_float > WGL_EXT_extensions_string > WGL_EXT_framebuffer_sRGB > WGL_EXT_pixel_format_packed_float > WGL_EXT_swap_control > WGL_I3D_genlock > WGL_NV_float_buffer > WGL_NV_gpu_affinity > WGL_NV_render_depth_texture > WGL_NV_render_texture_rectangle > WGL_NV_swap_group > > > > 2008-04-06T08:34:25Z INFO: LLAppViewer::init: Viewer Digest: 335acf7c-1908-df4d-b05f-bc0574e907e4 > 2008-04-06T08:34:25Z INFO: LLVoiceClient::setState: entering state stateDisabled > 2008-04-06T08:34:25Z INFO: LLVoiceClient::switchChannel: called in state stateDisabled with uri "" > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Resend: 150 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Land: 130 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Wind: 26 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Cloud: 26 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Task: 484 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Texture: 484 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Asset: 200 > 2008-04-06T08:34:26Z INFO: LLViewerThrottleGroup::dump: Total: 1500 > 2008-04-06T08:34:26Z INFO: idle_startup: Initializing messaging system... > 2008-04-06T08:34:26Z INFO: LLTemplateParser::LLTemplateParser: ### Message template version 2 ### > 2008-04-06T08:34:26Z INFO: start_net: attempting to connect on port 0 > 2008-04-06T08:34:26Z INFO: start_net: connected on port 1503 > 2008-04-06T08:34:26Z INFO: start_net: startNet - receive buffer size : 400000 > 2008-04-06T08:34:26Z INFO: start_net: startNet - send buffer size : 400000 > 2008-04-06T08:34:26Z INFO: start_messaging_system: Message template version matches prehash version number > 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadFile: Loading message.xml file at C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml > 2008-04-06T08:34:26Z INFO: LLMessageConfigFile::loadCapBans: 25 ban tests > 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: > 2008-04-06T08:34:26Z INFO: LLMessageSystem::setMessageBans: no messages banned > 2008-04-06T08:34:26Z INFO: LLMessageConfig::initClass config file C:\SL\1.19.1.4\workspace\linden\indra\newview\app_settings/message.xml > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle min rate: 2.66667e+006 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle actual rate: 2.93333e+006 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle min rate: 8000 > 2008-04-06T08:34:26Z INFO: LLXferManager::setAckThrottleBPS: LLXferManager ack throttle actual rate: 150000 > 2008-04-06T08:34:26Z INFO: LLAssetStorage::setUpstream: AssetStorage: Setting upstream provider to 0.0.0.0:0 > 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() initializing FMOD > 2008-04-06T08:34:26Z WARNING: LLAudioEngine_FMOD::init: Error : You are using the wrong FMOD version (3.74)! You should be using FMOD 3.75 > 2008-04-06T08:34:26Z INFO: LLAudioEngine_FMOD::init() FMOD initialized correctly > 2008-04-06T08:34:26Z INFO: LLStartUp::setStartupState: Startup state changing from 0 to 1 > 2008-04-06T08:34:26Z INFO: idle_startup: Initializing Multimedia.... > 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state changing from 1 to 2 > 2008-04-06T08:34:29Z WARNING: LLWinDebug::setupExceptionHandler: Our exception handler (007D9FD0) replaced with 6681F570! > 2008-04-06T08:34:29Z WARNING: LLAppViewer::mainLoop: Someone took over my exception handler (post messagehandling)! > 2008-04-06T08:34:29Z INFO: idle_startup: Initializing Window > 2008-04-06T08:34:29Z WARNING: Attempted getFields with no login view shown > 2008-04-06T08:34:29Z INFO: login_show: Initializing Login Screen > 2008-04-06T08:34:29Z WARNING: LLWebBrowserCtrl::navigateToLocalPage: File loading\loading.htmlnot found > 2008-04-06T08:34:29Z INFO: login_show: Setting Servers > 2008-04-06T08:34:29Z INFO: LLStartUp::setStartupState: Startup state changing from 2 to 3 > 2008-04-06T08:34:30Z INFO: LLAudioEngine::startNextTransfer: Getting asset data for: c80260ba-41fd-8a46-768a-6bf236360e3a > 2008-04-06T08:34:30Z WARNING: LLAssetStorage::_queueDataRequest: Attempt to move asset data request upstream w/o valid upstream provider > 2008-04-06T08:34:30Z INFO: LLAudioEngine::assetCallback: Boom, error in audio file transfer: Circuit gone (-23017) > 2008-04-06T08:34:38Z INFO: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing:HTTP/1.0 200 OK > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: f8124d60-2875-c358-7847-2acb63e5400c Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: f8124d60-2875-c358-7847-2acb63e5400c RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: d8faf8cb-ee6e-b0b5-abd9-bde873ad3461 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 38ce8b3c-fb30-5c59-9926-bd643613f606 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 38ce8b3c-fb30-5c59-9926-bd643613f606 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b28df901-6b8d-d31c-7903-4eb9676d4bfc Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b28df901-6b8d-d31c-7903-4eb9676d4bfc RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: c48c9e95-191b-96d3-08b2-6e8ada58b651 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: c48c9e95-191b-96d3-08b2-6e8ada58b651 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1097dcb3-aef9-8152-f471-431d840ea89e Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1097dcb3-aef9-8152-f471-431d840ea89e RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 1ed83f57-41cf-4052-a3b4-2e8bb78d8191 RETRIES: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 16d032e8-817b-4368-8a4e-b7b947ae3889 Discard: 0 > 2008-04-06T08:34:39Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 16d032e8-817b-4368-8a4e-b7b947ae3889 RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:40Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:41Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:42Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:43Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 66864f3c-e095-d9c8-058d-d6575e6ed1b8 RETRIES: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:44Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: ac8f8627-6a30-8da8-d4bd-958668eea7a0 Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: ac8f8627-6a30-8da8-d4bd-958668eea7a0 RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: b4ba225c-373f-446d-9f7e-6cb7b5cf9b3d RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: da5d4079-7819-6b53-d2a4-dc9929381d7d Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: da5d4079-7819-6b53-d2a4-dc9929381d7d RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: e5a0ec29-f59e-d29e-2c59-ed66c187c26c Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: e5a0ec29-f59e-d29e-2c59-ed66c187c26c RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:45Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 14e8a47d-1055-0a68-5d55-eafd9ad3da5b RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE: 4c95e6bc-fe77-9cb4-b58a-909848042c1e RETRIES: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::decodeImage: DECODE FAILED: 4c95e6bc-fe77-9cb4-b58a-909848042c1e Discard: 0 > 2008-04-06T08:34:46Z WARNING: LLTextureFetchWorker::doWork: UNABLE TO LOAD TEXTURE... > > [Message clipped] -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 03:25:42 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 03:25:44 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: Message-ID: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> Hi, I'm not sure but when I get link error from obj files I am sure I have already compile, I rebuild the projects they are issued from (or at least I recompile their cpp files). Most of the time it is due to a VC problem, corrupting obj files. Marine 2008/4/6, Ajinkya Kale : > > Hi, > > Can anyone please suggest me any work around for the > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to > compile the viewer due to these errors. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/c81aa38a/attachment.htm From lcc1967 at gmail.com Sun Apr 6 03:34:08 2008 From: lcc1967 at gmail.com (laurent cezanne) Date: Sun Apr 6 03:34:10 2008 Subject: [sldev] Re: 1.19.1.4 RC - Crashes after successful build Message-ID: Could it be related to that : QUOTE : Email From Henri Beauchamps Message: 2 Date: Sat, 5 Apr 2008 20:30:12 +0200 From: Henri Beauchamp Subject: Re: [sldev] 1.19.1 release source To: sldev@lists.secondlife.com Message-ID: <20080405203012.4ad3b0a0.sldev@free.fr> Content-Type: text/plain; charset=US-ASCII On Sat, 5 Apr 2008 12:03:21 -0500, Soft wrote: > A few people have pinged about 1.19.1 source. > > I'm currently unable to publish to svn.secondlife.com - I'll get > updates out when that's resolved. Good, thanks. > In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except > for some version strings. RC4 source will generate a functionally > identical binary. Not if we take into account Rob's message to this list. Citation: "There was one change that slipped in between RC and final release" And obviously, it's a potential crash fix: - delete iter->second->data; - delete iter->second; + if(iter->second != NULL) + { + delete iter->second->data; + delete iter->second; + } So it is not a neglectable change ! Question: why the guy (or gal) in charge for compiling the viewers at LL is not also in charge for releasing the sources ??? After all, (s)he needs the sources to produce the binaries and it would ensure that the published sources are -actually- the ones which were used for the official viewers... Regards, Henri. END OF QUOTE Sacha -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/5a289c4e/attachment.htm From kaleajinkya at gmail.com Sun Apr 6 03:48:20 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 03:48:22 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> Message-ID: When I try to recompile lscript_compile and lscript_compile_fb_vc8 I get the following errors : 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, Configuration: Release Win32 ------ 1>Deleting intermediate and output files for project 'lscript_compile_fb_vc8', configuration 'Release|Win32' 2>------ Rebuild All started: Project: lscript_library, Configuration: Release Win32 ------ 2>Deleting intermediate and output files for project 'lscript_library', configuration 'Release|Win32' 1>Building ytab.cpp 2>Compiling... 2>lscript_library.cpp 1>'bison.exe' is not recognized as an internal or external command, 1>operable program or batch file. 1>'mv.exe' is not recognized as an internal or external command, 1>operable program or batch file. 1>Project : error PRJ0019: A tool returned an error code from "Building ytab.cpp" 2>lscript_export.cpp 2>lscript_alloc.cpp 2>Generating Code... 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) 2>Creating library... 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" 2>lscript_library - 0 error(s), 0 warning(s) 3>------ Rebuild All started: Project: lscript_compile, Configuration: Release Win32 ------ 3>Deleting intermediate and output files for project 'lscript_compile', configuration 'Release|Win32' 3>Compiling... 3>lscript_typecheck.cpp 3>lscript_tree.cpp 3>lscript_scope.cpp 3>lscript_resource.cpp 3>lscript_heap.cpp 3>lscript_error.cpp 3>lscript_bytecode.cpp 3>lscript_alloc.cpp 3>Generating Code... 3>Creating library... 3>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" 3>lscript_compile - 0 error(s), 0 warning(s) ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== I have also separated the commanline in the properties of indra.y. Still no success :( Waiting for your suggestions. On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley wrote: > Hi, I'm not sure but when I get link error from obj files I am sure I have > already compile, I rebuild the projects they are issued from (or at least I > recompile their cpp files). Most of the time it is due to a VC problem, > corrupting obj files. > > Marine > > 2008/4/6, Ajinkya Kale : > > Hi, > > > > Can anyone please suggest me any work around for the > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to > > compile the viewer due to these errors. > > > > -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 03:57:59 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 03:58:02 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> Message-ID: <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> It seems your bison.exe and mv.exe files are not in any of the paths you've provided to VC. 2008/4/6, Ajinkya Kale : > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > get the following errors : > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > Configuration: Release Win32 ------ > 1>Deleting intermediate and output files for project > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > 2>------ Rebuild All started: Project: lscript_library, Configuration: > Release Win32 ------ > 2>Deleting intermediate and output files for project > 'lscript_library', configuration 'Release|Win32' > 1>Building ytab.cpp > 2>Compiling... > 2>lscript_library.cpp > 1>'bison.exe' is not recognized as an internal or external command, > 1>operable program or batch file. > 1>'mv.exe' is not recognized as an internal or external command, > 1>operable program or batch file. > 1>Project : error PRJ0019: A tool returned an error code from > "Building ytab.cpp" > 2>lscript_export.cpp > 2>lscript_alloc.cpp > 2>Generating Code... > > 1>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > 2>Creating library... > > 2>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > 2>lscript_library - 0 error(s), 0 warning(s) > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > Release Win32 ------ > 3>Deleting intermediate and output files for project > 'lscript_compile', configuration 'Release|Win32' > 3>Compiling... > 3>lscript_typecheck.cpp > 3>lscript_tree.cpp > 3>lscript_scope.cpp > 3>lscript_resource.cpp > 3>lscript_heap.cpp > 3>lscript_error.cpp > 3>lscript_bytecode.cpp > 3>lscript_alloc.cpp > 3>Generating Code... > 3>Creating library... > > 3>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > 3>lscript_compile - 0 error(s), 0 warning(s) > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > I have also separated the commanline in the properties of indra.y. > Still no success :( > > Waiting for your suggestions. > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > wrote: > > Hi, I'm not sure but when I get link error from obj files I am sure I > have > > already compile, I rebuild the projects they are issued from (or at > least I > > recompile their cpp files). Most of the time it is due to a VC problem, > > corrupting obj files. > > > > Marine > > > > 2008/4/6, Ajinkya Kale : > > > Hi, > > > > > > Can anyone please suggest me any work around for the > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to > > > compile the viewer due to these errors. > > > > > > > > > > > > -- > Ciao, > > Ajinkya > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/6507565c/attachment.htm From marinekelley at gmail.com Sun Apr 6 03:58:44 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 03:58:46 2008 Subject: [sldev] Re: 1.19.1.4 RC - Crashes after successful build In-Reply-To: References: Message-ID: <9e52a8c10804060358r798e1633gaa299b2aaf7f9b39@mail.gmail.com> I have applied this fix as soon as Henri posted it yesterday, unfortunately it does not do the trick. 2008/4/6, laurent cezanne : > > Could it be related to that : > > QUOTE : > Email From Henri Beauchamps > > Message: 2 > Date: Sat, 5 Apr 2008 20:30:12 +0200 > From: Henri Beauchamp > Subject: Re: [sldev] 1.19.1 release source > To: sldev@lists.secondlife.com > Message-ID: <20080405203012.4ad3b0a0.sldev@free.fr> > Content-Type: text/plain; charset=US-ASCII > > On Sat, 5 Apr 2008 12:03:21 -0500, Soft wrote: > > > A few people have pinged about 1.19.1 source. > > > > I'm currently unable to publish to svn.secondlife.com - I'll get > > updates out when that's resolved. > > Good, thanks. > > > In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except > > for some version strings. RC4 source will generate a functionally > > identical binary. > > Not if we take into account Rob's message to this list. Citation: > > "There was one change that slipped in between RC and final release" > > And obviously, it's a potential crash fix: > > - delete iter->second->data; > - delete iter->second; > + if(iter->second != NULL) > + { > + delete iter->second->data; > + delete iter->second; > + } > > So it is not a neglectable change ! > > Question: why the guy (or gal) in charge for compiling the viewers at > LL is not also in charge for releasing the sources ??? After all, > (s)he needs the sources to produce the binaries and it would ensure > that the published sources are -actually- the ones which were used > for the official viewers... > > Regards, > > Henri. > END OF QUOTE > > Sacha > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/2e153afd/attachment-0001.htm From kfa at gmx.net Sun Apr 6 04:04:08 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 04:04:16 2008 Subject: [sldev] Re: 1.19.1.4 RC - Crashes after successful build In-Reply-To: References: Message-ID: <47F8AE28.8060508@gmx.net> This was about Rob's patch which I also applied, but to no avail. laurent cezanne wrote: > Could it be related to that : > > QUOTE : > Email From Henri Beauchamps > > Message: 2 > Date: Sat, 5 Apr 2008 20:30:12 +0200 > From: Henri Beauchamp > > Subject: Re: [sldev] 1.19.1 release source > To: sldev@lists.secondlife.com > Message-ID: <20080405203012.4ad3b0a0.sldev@free.fr > > > Content-Type: text/plain; charset=US-ASCII > > On Sat, 5 Apr 2008 12:03:21 -0500, Soft wrote: > > > A few people have pinged about 1.19.1 source. > > > > I'm currently unable to publish to svn.secondlife.com > - I'll get > > updates out when that's resolved. > > Good, thanks. > > > In the meantime, 1.19.1 release is identical to 1.19.1 RC 4, except > > for some version strings. RC4 source will generate a functionally > > identical binary. > > Not if we take into account Rob's message to this list. Citation: > > "There was one change that slipped in between RC and final release" > > And obviously, it's a potential crash fix: > > - delete iter->second->data; > - delete iter->second; > + if(iter->second != NULL) > + { > + delete iter->second->data; > + delete iter->second; > + } > > So it is not a neglectable change ! > > Question: why the guy (or gal) in charge for compiling the viewers at > LL is not also in charge for releasing the sources ??? After all, > (s)he needs the sources to produce the binaries and it would ensure > that the published sources are -actually- the ones which were used > for the official viewers... > > Regards, > > Henri. > END OF QUOTE > > Sacha > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kaleajinkya at gmail.com Sun Apr 6 04:04:27 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 04:04:30 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> Message-ID: Ok. So now what i did is I added C:\cygwin\bin to the VC++ Directories\Executable Files\ list. And I rebuilt the lscript_compile and lscript_compile_fb_vc8 projects. They were built successfully without any errors. But now when i try to Build newview I get the following error : 1>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 1>Executing pre-build batch file 1>PREBUILD SUCCESSFUL 1>Linking... 1>link: extra operand `/ERRORREPORT:PROMPT' 1>Try `link --help' for more information. 1>Project : error PRJ0002 : Error result 1 returned from 'C:\cygwin\bin\link.exe'. 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 1>newview - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== Waiting for your suggestions. On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley wrote: > It seems your bison.exe and mv.exe files are not in any of the paths you've > provided to VC. > > > > 2008/4/6, Ajinkya Kale : > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > get the following errors : > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > Configuration: Release Win32 ------ > > 1>Deleting intermediate and output files for project > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > 2>------ Rebuild All started: Project: lscript_library, Configuration: > > Release Win32 ------ > > 2>Deleting intermediate and output files for project > > 'lscript_library', configuration 'Release|Win32' > > 1>Building ytab.cpp > > 2>Compiling... > > 2>lscript_library.cpp > > 1>'bison.exe' is not recognized as an internal or external command, > > 1>operable program or batch file. > > 1>'mv.exe' is not recognized as an internal or external command, > > 1>operable program or batch file. > > 1>Project : error PRJ0019: A tool returned an error code from > > "Building ytab.cpp" > > 2>lscript_export.cpp > > 2>lscript_alloc.cpp > > 2>Generating Code... > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > 2>Creating library... > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > 2>lscript_library - 0 error(s), 0 warning(s) > > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > > Release Win32 ------ > > 3>Deleting intermediate and output files for project > > 'lscript_compile', configuration 'Release|Win32' > > 3>Compiling... > > 3>lscript_typecheck.cpp > > 3>lscript_tree.cpp > > 3>lscript_scope.cpp > > 3>lscript_resource.cpp > > 3>lscript_heap.cpp > > 3>lscript_error.cpp > > 3>lscript_bytecode.cpp > > 3>lscript_alloc.cpp > > 3>Generating Code... > > 3>Creating library... > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > 3>lscript_compile - 0 error(s), 0 warning(s) > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > I have also separated the commanline in the properties of indra.y. > > Still no success :( > > > > Waiting for your suggestions. > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > wrote: > > > Hi, I'm not sure but when I get link error from obj files I am sure I > have > > > already compile, I rebuild the projects they are issued from (or at > least I > > > recompile their cpp files). Most of the time it is due to a VC problem, > > > corrupting obj files. > > > > > > Marine > > > > > > 2008/4/6, Ajinkya Kale : > > > > Hi, > > > > > > > > Can anyone please suggest me any work around for the > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > -- > > Ciao, > > > > Ajinkya > > > > -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 04:09:26 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 04:09:30 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> Message-ID: <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Perhaps you have put C:\Cygwin\bin before the VC bin directory... which means VC tries to link using the cygwin link.exe instead of its own. Try to change the order of the paths in your Path variable in VC. Hope this helps 2008/4/6, Ajinkya Kale : > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > Directories\Executable Files\ list. And I rebuilt the > lscript_compile and lscript_compile_fb_vc8 projects. They were built > successfully without any errors. > > But now when i try to Build newview I get the following error : > > > 1>------ Build started: Project: newview, Configuration: > ReleaseForDownload Win32 ------ > 1>Executing pre-build batch file > 1>PREBUILD SUCCESSFUL > 1>Linking... > > 1>link: extra operand `/ERRORREPORT:PROMPT' > 1>Try `link --help' for more information. > 1>Project : error PRJ0002 : Error result 1 returned from > 'C:\cygwin\bin\link.exe'. > > 1>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > 1>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > ========== > > > > Waiting for your suggestions. > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > wrote: > > It seems your bison.exe and mv.exe files are not in any of the paths > you've > > provided to VC. > > > > > > > > 2008/4/6, Ajinkya Kale : > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > > get the following errors : > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > Configuration: Release Win32 ------ > > > 1>Deleting intermediate and output files for project > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > 2>------ Rebuild All started: Project: lscript_library, Configuration: > > > Release Win32 ------ > > > 2>Deleting intermediate and output files for project > > > 'lscript_library', configuration 'Release|Win32' > > > 1>Building ytab.cpp > > > 2>Compiling... > > > 2>lscript_library.cpp > > > 1>'bison.exe' is not recognized as an internal or external command, > > > 1>operable program or batch file. > > > 1>'mv.exe' is not recognized as an internal or external command, > > > 1>operable program or batch file. > > > 1>Project : error PRJ0019: A tool returned an error code from > > > "Building ytab.cpp" > > > 2>lscript_export.cpp > > > 2>lscript_alloc.cpp > > > 2>Generating Code... > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > 2>Creating library... > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > > > Release Win32 ------ > > > 3>Deleting intermediate and output files for project > > > 'lscript_compile', configuration 'Release|Win32' > > > 3>Compiling... > > > 3>lscript_typecheck.cpp > > > 3>lscript_tree.cpp > > > 3>lscript_scope.cpp > > > 3>lscript_resource.cpp > > > 3>lscript_heap.cpp > > > 3>lscript_error.cpp > > > 3>lscript_bytecode.cpp > > > 3>lscript_alloc.cpp > > > 3>Generating Code... > > > 3>Creating library... > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > > > I have also separated the commanline in the properties of indra.y. > > > Still no success :( > > > > > > Waiting for your suggestions. > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > wrote: > > > > Hi, I'm not sure but when I get link error from obj files I am sure > I > > have > > > > already compile, I rebuild the projects they are issued from (or at > > least I > > > > recompile their cpp files). Most of the time it is due to a VC > problem, > > > > corrupting obj files. > > > > > > > > Marine > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > Hi, > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able > to > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > > -- > Ciao, > > Ajinkya > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/5a6caec3/attachment.htm From kfa at gmx.net Sun Apr 6 04:20:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 04:20:11 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> Message-ID: <47F8B1E3.9050405@gmx.net> Maybe try a clean rebuild of the entire solution. I too had a slur of these errors before being able to build the application, bedazzling because I'm not too familiar with compiling under Windows yet. After going over the instructions on the wiki several times, making absolutely sure everything's in place and the project files ironed out, I decided to try a complete rebuild. Since then the problems have just vanished. I posted a patch for the project files to VWR-1151. HTH, Felix Ajinkya Kale wrote: > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > Directories\Executable Files\ list. And I rebuilt the > lscript_compile and lscript_compile_fb_vc8 projects. They were built > successfully without any errors. > > But now when i try to Build newview I get the following error : > > 1>------ Build started: Project: newview, Configuration: > ReleaseForDownload Win32 ------ > 1>Executing pre-build batch file > 1>PREBUILD SUCCESSFUL > 1>Linking... > 1>link: extra operand `/ERRORREPORT:PROMPT' > 1>Try `link --help' for more information. > 1>Project : error PRJ0002 : Error result 1 returned from > 'C:\cygwin\bin\link.exe'. > 1>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > 1>newview - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== > > > Waiting for your suggestions. > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley wrote: > >> It seems your bison.exe and mv.exe files are not in any of the paths you've >> provided to VC. >> >> >> >> 2008/4/6, Ajinkya Kale : >> >>> When I try to recompile lscript_compile and lscript_compile_fb_vc8 I >>> get the following errors : >>> >>> 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, >>> Configuration: Release Win32 ------ >>> 1>Deleting intermediate and output files for project >>> 'lscript_compile_fb_vc8', configuration 'Release|Win32' >>> 2>------ Rebuild All started: Project: lscript_library, Configuration: >>> Release Win32 ------ >>> 2>Deleting intermediate and output files for project >>> 'lscript_library', configuration 'Release|Win32' >>> 1>Building ytab.cpp >>> 2>Compiling... >>> 2>lscript_library.cpp >>> 1>'bison.exe' is not recognized as an internal or external command, >>> 1>operable program or batch file. >>> 1>'mv.exe' is not recognized as an internal or external command, >>> 1>operable program or batch file. >>> 1>Project : error PRJ0019: A tool returned an error code from >>> "Building ytab.cpp" >>> 2>lscript_export.cpp >>> 2>lscript_alloc.cpp >>> 2>Generating Code... >>> >>> 1>Build log was saved at "file://h:\SL Open source >>> >>> >>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" >> >>> 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) >>> 2>Creating library... >>> >>> 2>Build log was saved at "file://h:\SL Open source >>> >>> >>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" >> >>> 2>lscript_library - 0 error(s), 0 warning(s) >>> 3>------ Rebuild All started: Project: lscript_compile, Configuration: >>> Release Win32 ------ >>> 3>Deleting intermediate and output files for project >>> 'lscript_compile', configuration 'Release|Win32' >>> 3>Compiling... >>> 3>lscript_typecheck.cpp >>> 3>lscript_tree.cpp >>> 3>lscript_scope.cpp >>> 3>lscript_resource.cpp >>> 3>lscript_heap.cpp >>> 3>lscript_error.cpp >>> 3>lscript_bytecode.cpp >>> 3>lscript_alloc.cpp >>> 3>Generating Code... >>> 3>Creating library... >>> >>> 3>Build log was saved at "file://h:\SL Open source >>> >>> >>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" >> >>> 3>lscript_compile - 0 error(s), 0 warning(s) >>> ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== >>> >>> I have also separated the commanline in the properties of indra.y. >>> Still no success :( >>> >>> Waiting for your suggestions. >>> >>> >>> On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley >>> >> wrote: >> >>>> Hi, I'm not sure but when I get link error from obj files I am sure I >>>> >> have >> >>>> already compile, I rebuild the projects they are issued from (or at >>>> >> least I >> >>>> recompile their cpp files). Most of the time it is due to a VC problem, >>>> corrupting obj files. >>>> >>>> Marine >>>> >>>> 2008/4/6, Ajinkya Kale : >>>> >>>>> Hi, >>>>> >>>>> Can anyone please suggest me any work around for the >>>>> llcompilequeue.obj and llpreviewscript.obj errors ? I am not able to >>>>> compile the viewer due to these errors. >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ciao, >>> >>> Ajinkya >>> >>> >> > > > > From marinekelley at gmail.com Sun Apr 6 04:22:43 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 04:22:50 2008 Subject: [sldev] lscript_compile error In-Reply-To: <47F8B1E3.9050405@gmx.net> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <47F8B1E3.9050405@gmx.net> Message-ID: <9e52a8c10804060422m4379f3cbi67c10c4b95041070@mail.gmail.com> Good point. That's usually due to moving the whole linden folder to another place while it has already been compiled. VC doesn't complain about paths, it just fails to compile for silly reasons. A cleanup-build generally takes care of this problem for me. 2008/4/6, Felix Duesenburg : > > Maybe try a clean rebuild of the entire solution. I too had a slur of > these errors before being able to build the application, bedazzling because > I'm not too familiar with compiling under Windows yet. After going over the > instructions on the wiki several times, making absolutely sure everything's > in place and the project files ironed out, I decided to try a complete > rebuild. Since then the problems have just vanished. I posted a patch for > the project files to VWR-1151. > > HTH, > Felix > > Ajinkya Kale wrote: > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > Directories\Executable Files\ list. And I rebuilt the > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > successfully without any errors. > > > > But now when i try to Build newview I get the following error : > > > > 1>------ Build started: Project: newview, Configuration: > > ReleaseForDownload Win32 ------ > > 1>Executing pre-build batch file > > 1>PREBUILD SUCCESSFUL > > 1>Linking... > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > 1>Try `link --help' for more information. > > 1>Project : error PRJ0002 : Error result 1 returned from > > 'C:\cygwin\bin\link.exe'. > > 1>Build log was saved at "file://h:\SL Open source > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > 1>newview - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > ========== > > > > > > Waiting for your suggestions. > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > wrote: > > > > > > > It seems your bison.exe and mv.exe files are not in any of the paths > > > you've > > > provided to VC. > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > > > get the following errors : > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > Configuration: Release Win32 ------ > > > > 1>Deleting intermediate and output files for project > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > 2>------ Rebuild All started: Project: lscript_library, > > > > Configuration: > > > > Release Win32 ------ > > > > 2>Deleting intermediate and output files for project > > > > 'lscript_library', configuration 'Release|Win32' > > > > 1>Building ytab.cpp > > > > 2>Compiling... > > > > 2>lscript_library.cpp > > > > 1>'bison.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > "Building ytab.cpp" > > > > 2>lscript_export.cpp > > > > 2>lscript_alloc.cpp > > > > 2>Generating Code... > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > 2>Creating library... > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > 3>------ Rebuild All started: Project: lscript_compile, > > > > Configuration: > > > > Release Win32 ------ > > > > 3>Deleting intermediate and output files for project > > > > 'lscript_compile', configuration 'Release|Win32' > > > > 3>Compiling... > > > > 3>lscript_typecheck.cpp > > > > 3>lscript_tree.cpp > > > > 3>lscript_scope.cpp > > > > 3>lscript_resource.cpp > > > > 3>lscript_heap.cpp > > > > 3>lscript_error.cpp > > > > 3>lscript_bytecode.cpp > > > > 3>lscript_alloc.cpp > > > > 3>Generating Code... > > > > 3>Creating library... > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > Still no success :( > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley < > > > > marinekelley@gmail.com> > > > > > > > > > > > wrote: > > > > > > > > > > Hi, I'm not sure but when I get link error from obj files I am sure > > > > > I > > > > > > > > > > > > > > have > > > > > > > > > > already compile, I rebuild the projects they are issued from (or at > > > > > > > > > > > > > > least I > > > > > > > > > > recompile their cpp files). Most of the time it is due to a VC > > > > > problem, > > > > > corrupting obj files. > > > > > > > > > > Marine > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not > > > > > > able to > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/27b36447/attachment.htm From kaleajinkya at gmail.com Sun Apr 6 04:23:03 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 04:23:09 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: Yes I changed the order and it worked. But when I build newview I get the same old llcompilequeue.obj and llpreviewscript.obj errors. I am fed up due to these same errors evrytime :( I also rebuilt lscript_comiple and lscript_compile_fb_vc8. They were built without any errors ! So why the errors on building newview ? 1>------ Skipped Build: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Project not selected to build for this solution configuration 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 2>Executing pre-build batch file 2>PREBUILD SUCCESSFUL 2>Linking... 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved externals 2>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 2>newview - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped ========== On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley wrote: > Perhaps you have put C:\Cygwin\bin before the VC bin directory... which > means VC tries to link using the cygwin link.exe instead of its own. Try to > change the order of the paths in your Path variable in VC. > > Hope this helps > > > > 2008/4/6, Ajinkya Kale : > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > Directories\Executable Files\ list. And I rebuilt the > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > successfully without any errors. > > > > But now when i try to Build newview I get the following error : > > > > > > 1>------ Build started: Project: newview, Configuration: > > ReleaseForDownload Win32 ------ > > 1>Executing pre-build batch file > > 1>PREBUILD SUCCESSFUL > > 1>Linking... > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > 1>Try `link --help' for more information. > > 1>Project : error PRJ0002 : Error result 1 returned from > > 'C:\cygwin\bin\link.exe'. > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > 1>newview - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > ========== > > > > > > > > Waiting for your suggestions. > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > wrote: > > > It seems your bison.exe and mv.exe files are not in any of the paths > you've > > > provided to VC. > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > > > get the following errors : > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > Configuration: Release Win32 ------ > > > > 1>Deleting intermediate and output files for project > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > 2>------ Rebuild All started: Project: lscript_library, Configuration: > > > > Release Win32 ------ > > > > 2>Deleting intermediate and output files for project > > > > 'lscript_library', configuration 'Release|Win32' > > > > 1>Building ytab.cpp > > > > 2>Compiling... > > > > 2>lscript_library.cpp > > > > 1>'bison.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > "Building ytab.cpp" > > > > 2>lscript_export.cpp > > > > 2>lscript_alloc.cpp > > > > 2>Generating Code... > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > 2>Creating library... > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > > > > Release Win32 ------ > > > > 3>Deleting intermediate and output files for project > > > > 'lscript_compile', configuration 'Release|Win32' > > > > 3>Compiling... > > > > 3>lscript_typecheck.cpp > > > > 3>lscript_tree.cpp > > > > 3>lscript_scope.cpp > > > > 3>lscript_resource.cpp > > > > 3>lscript_heap.cpp > > > > 3>lscript_error.cpp > > > > 3>lscript_bytecode.cpp > > > > 3>lscript_alloc.cpp > > > > 3>Generating Code... > > > > 3>Creating library... > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > Still no success :( > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > wrote: > > > > > Hi, I'm not sure but when I get link error from obj files I am sure > I > > > have > > > > > already compile, I rebuild the projects they are issued from (or at > > > least I > > > > > recompile their cpp files). Most of the time it is due to a VC > problem, > > > > > corrupting obj files. > > > > > > > > > > Marine > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > Hi, > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able > to > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > -- > > Ciao, > > > > Ajinkya > > > > -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 04:24:52 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 04:24:55 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: <9e52a8c10804060424i4100fa30ufc09add3f97adf2e@mail.gmail.com> I'm not sure, but perhaps this link will help : http://wiki.secondlife.com/wiki/Common_compilation_problems#Unresolved_external_symbol_.22int___cdecl_lscript_compile.22_.28VS2005.29 Also you're still building ReleaseNoOpt. 2008/4/6, Ajinkya Kale : > > Yes I changed the order and it worked. > But when I build newview I get the same old llcompilequeue.obj and > llpreviewscript.obj errors. I am fed up due to these same errors > evrytime :( I also rebuilt lscript_comiple and > lscript_compile_fb_vc8. They were built without any errors ! So why > the errors on building newview ? > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > Win32 ------ > 2>Executing pre-build batch file > > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void __thiscall LLFloaterCompileQueue::compile(char const *,class > LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved > externals > > 2>Build log was saved at "file://h:\SL Open source > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > 2>newview - 3 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped > ========== > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > wrote: > > Perhaps you have put C:\Cygwin\bin before the VC bin directory... which > > means VC tries to link using the cygwin link.exe instead of its own. Try > to > > change the order of the paths in your Path variable in VC. > > > > Hope this helps > > > > > > > > 2008/4/6, Ajinkya Kale : > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > Directories\Executable Files\ list. And I rebuilt the > > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > > successfully without any errors. > > > > > > But now when i try to Build newview I get the following error : > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > ReleaseForDownload Win32 ------ > > > 1>Executing pre-build batch file > > > 1>PREBUILD SUCCESSFUL > > > 1>Linking... > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > 1>Try `link --help' for more information. > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > 'C:\cygwin\bin\link.exe'. > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > 1>newview - 1 error(s), 0 warning(s) > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > ========== > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > wrote: > > > > It seems your bison.exe and mv.exe files are not in any of the paths > > you've > > > > provided to VC. > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 > I > > > > > get the following errors : > > > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > > Configuration: Release Win32 ------ > > > > > 1>Deleting intermediate and output files for project > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > 2>------ Rebuild All started: Project: lscript_library, > Configuration: > > > > > Release Win32 ------ > > > > > 2>Deleting intermediate and output files for project > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > 1>Building ytab.cpp > > > > > 2>Compiling... > > > > > 2>lscript_library.cpp > > > > > 1>'bison.exe' is not recognized as an internal or external > command, > > > > > 1>operable program or batch file. > > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > > 1>operable program or batch file. > > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > > "Building ytab.cpp" > > > > > 2>lscript_export.cpp > > > > > 2>lscript_alloc.cpp > > > > > 2>Generating Code... > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > 2>Creating library... > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > 3>------ Rebuild All started: Project: lscript_compile, > Configuration: > > > > > Release Win32 ------ > > > > > 3>Deleting intermediate and output files for project > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > 3>Compiling... > > > > > 3>lscript_typecheck.cpp > > > > > 3>lscript_tree.cpp > > > > > 3>lscript_scope.cpp > > > > > 3>lscript_resource.cpp > > > > > 3>lscript_heap.cpp > > > > > 3>lscript_error.cpp > > > > > 3>lscript_bytecode.cpp > > > > > 3>lscript_alloc.cpp > > > > > 3>Generating Code... > > > > > 3>Creating library... > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > ========== > > > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > > Still no success :( > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley < > marinekelley@gmail.com> > > > > wrote: > > > > > > Hi, I'm not sure but when I get link error from obj files I am > sure > > I > > > > have > > > > > > already compile, I rebuild the projects they are issued from (or > at > > > > least I > > > > > > recompile their cpp files). Most of the time it is due to a VC > > problem, > > > > > > corrupting obj files. > > > > > > > > > > > > Marine > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > Hi, > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not > able > > to > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ciao, > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > > -- > Ciao, > > Ajinkya > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/c06e03a7/attachment-0001.htm From kfa at gmx.net Sun Apr 6 04:28:31 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 04:28:40 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: <47F8B3DF.4010401@gmx.net> I meant, try a clean rebuild of the *entire* solution, not just a single project. Then go walk the dog, or have icecream with someone... Ajinkya Kale wrote: > Yes I changed the order and it worked. > But when I build newview I get the same old llcompilequeue.obj and > llpreviewscript.obj errors. I am fed up due to these same errors > evrytime :( I also rebuilt lscript_comiple and > lscript_compile_fb_vc8. They were built without any errors ! So why > the errors on building newview ? > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > ReleaseNoOpt Win32 ------ > 1>Project not selected to build for this solution configuration > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > Win32 ------ > 2>Executing pre-build batch file > 2>PREBUILD SUCCESSFUL > 2>Linking... > 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > void __thiscall LLFloaterCompileQueue::compile(char const *,class > LLUUID const &)" > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > __cdecl lscript_compile(char const *,char const *,char const *,int)" > (?lscript_compile@@YAHPBD00H@Z) > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved externals > 2>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 2>newview - 3 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped ========== > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley wrote: > >> Perhaps you have put C:\Cygwin\bin before the VC bin directory... which >> means VC tries to link using the cygwin link.exe instead of its own. Try to >> change the order of the paths in your Path variable in VC. >> >> Hope this helps >> >> >> >> 2008/4/6, Ajinkya Kale : >> >>> Ok. So now what i did is I added C:\cygwin\bin to the VC++ >>> Directories\Executable Files\ list. And I rebuilt the >>> lscript_compile and lscript_compile_fb_vc8 projects. They were built >>> successfully without any errors. >>> >>> But now when i try to Build newview I get the following error : >>> >>> >>> 1>------ Build started: Project: newview, Configuration: >>> ReleaseForDownload Win32 ------ >>> 1>Executing pre-build batch file >>> 1>PREBUILD SUCCESSFUL >>> 1>Linking... >>> >>> 1>link: extra operand `/ERRORREPORT:PROMPT' >>> 1>Try `link --help' for more information. >>> 1>Project : error PRJ0002 : Error result 1 returned from >>> 'C:\cygwin\bin\link.exe'. >>> >>> 1>Build log was saved at "file://h:\SL Open source >>> >>> >>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" >> >>> 1>newview - 1 error(s), 0 warning(s) >>> ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped >>> >> ========== >> >>> >>> Waiting for your suggestions. >>> >>> >>> On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley >>> >> wrote: >> >>>> It seems your bison.exe and mv.exe files are not in any of the paths >>>> >> you've >> >>>> provided to VC. >>>> >>>> >>>> >>>> 2008/4/6, Ajinkya Kale : >>>> >>>>> When I try to recompile lscript_compile and lscript_compile_fb_vc8 I >>>>> get the following errors : >>>>> >>>>> 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, >>>>> Configuration: Release Win32 ------ >>>>> 1>Deleting intermediate and output files for project >>>>> 'lscript_compile_fb_vc8', configuration 'Release|Win32' >>>>> 2>------ Rebuild All started: Project: lscript_library, Configuration: >>>>> Release Win32 ------ >>>>> 2>Deleting intermediate and output files for project >>>>> 'lscript_library', configuration 'Release|Win32' >>>>> 1>Building ytab.cpp >>>>> 2>Compiling... >>>>> 2>lscript_library.cpp >>>>> 1>'bison.exe' is not recognized as an internal or external command, >>>>> 1>operable program or batch file. >>>>> 1>'mv.exe' is not recognized as an internal or external command, >>>>> 1>operable program or batch file. >>>>> 1>Project : error PRJ0019: A tool returned an error code from >>>>> "Building ytab.cpp" >>>>> 2>lscript_export.cpp >>>>> 2>lscript_alloc.cpp >>>>> 2>Generating Code... >>>>> >>>>> 1>Build log was saved at "file://h:\SL Open source >>>>> >>>>> >>>>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" >> >>>>> 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) >>>>> 2>Creating library... >>>>> >>>>> 2>Build log was saved at "file://h:\SL Open source >>>>> >>>>> >>>>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" >> >>>>> 2>lscript_library - 0 error(s), 0 warning(s) >>>>> 3>------ Rebuild All started: Project: lscript_compile, Configuration: >>>>> Release Win32 ------ >>>>> 3>Deleting intermediate and output files for project >>>>> 'lscript_compile', configuration 'Release|Win32' >>>>> 3>Compiling... >>>>> 3>lscript_typecheck.cpp >>>>> 3>lscript_tree.cpp >>>>> 3>lscript_scope.cpp >>>>> 3>lscript_resource.cpp >>>>> 3>lscript_heap.cpp >>>>> 3>lscript_error.cpp >>>>> 3>lscript_bytecode.cpp >>>>> 3>lscript_alloc.cpp >>>>> 3>Generating Code... >>>>> 3>Creating library... >>>>> >>>>> 3>Build log was saved at "file://h:\SL Open source >>>>> >>>>> >>>>> >> codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" >> >>>>> 3>lscript_compile - 0 error(s), 0 warning(s) >>>>> ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== >>>>> >>>>> I have also separated the commanline in the properties of indra.y. >>>>> Still no success :( >>>>> >>>>> Waiting for your suggestions. >>>>> >>>>> >>>>> On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley >>>>> >>>> wrote: >>>> >>>>>> Hi, I'm not sure but when I get link error from obj files I am sure >>>>>> >> I >> >>>> have >>>> >>>>>> already compile, I rebuild the projects they are issued from (or at >>>>>> >>>> least I >>>> >>>>>> recompile their cpp files). Most of the time it is due to a VC >>>>>> >> problem, >> >>>>>> corrupting obj files. >>>>>> >>>>>> Marine >>>>>> >>>>>> 2008/4/6, Ajinkya Kale : >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Can anyone please suggest me any work around for the >>>>>>> llcompilequeue.obj and llpreviewscript.obj errors ? I am not able >>>>>>> >> to >> >>>>>>> compile the viewer due to these errors. >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ciao, >>>>> >>>>> Ajinkya >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ciao, >>> >>> Ajinkya >>> >>> >> > > > > From kaleajinkya at gmail.com Sun Apr 6 04:36:45 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 04:36:50 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060424i4100fa30ufc09add3f97adf2e@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <9e52a8c10804060424i4100fa30ufc09add3f97adf2e@mail.gmail.com> Message-ID: I have already seen the wiki. But no help from that solution. I am getting the same errors on ReleaseForDownload too. On Sun, Apr 6, 2008 at 4:24 AM, Marine Kelley wrote: > I'm not sure, but perhaps this link will help : > http://wiki.secondlife.com/wiki/Common_compilation_problems#Unresolved_external_symbol_.22int___cdecl_lscript_compile.22_.28VS2005.29 > > Also you're still building ReleaseNoOpt. > > > > > > 2008/4/6, Ajinkya Kale : > > Yes I changed the order and it worked. > > But when I build newview I get the same old llcompilequeue.obj and > > llpreviewscript.obj errors. I am fed up due to these same errors > > evrytime :( I also rebuilt lscript_comiple and > > lscript_compile_fb_vc8. They were built without any errors ! So why > > the errors on building newview ? > > > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > > ReleaseNoOpt Win32 ------ > > 1>Project not selected to build for this solution configuration > > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > > > Win32 ------ > > 2>Executing pre-build batch file > > > > 2>PREBUILD SUCCESSFUL > > 2>Linking... > > 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > > __cdecl lscript_compile(char const *,char const *,char const *,int)" > > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > > void __thiscall LLFloaterCompileQueue::compile(char const *,class > > LLUUID const &)" > > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > > 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > > __cdecl lscript_compile(char const *,char const *,char const *,int)" > > (?lscript_compile@@YAHPBD00H@Z) > > > > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved > externals > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > > > 2>newview - 3 error(s), 0 warning(s) > > > > ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped > ========== > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > wrote: > > > Perhaps you have put C:\Cygwin\bin before the VC bin directory... which > > > means VC tries to link using the cygwin link.exe instead of its own. Try > to > > > change the order of the paths in your Path variable in VC. > > > > > > Hope this helps > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > Directories\Executable Files\ list. And I rebuilt the > > > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > > > successfully without any errors. > > > > > > > > But now when i try to Build newview I get the following error : > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > ReleaseForDownload Win32 ------ > > > > 1>Executing pre-build batch file > > > > 1>PREBUILD SUCCESSFUL > > > > 1>Linking... > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > 1>Try `link --help' for more information. > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > 1>newview - 1 error(s), 0 warning(s) > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > > ========== > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > > wrote: > > > > > It seems your bison.exe and mv.exe files are not in any of the paths > > > you've > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 > I > > > > > > get the following errors : > > > > > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > > > Configuration: Release Win32 ------ > > > > > > 1>Deleting intermediate and output files for project > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > 2>------ Rebuild All started: Project: lscript_library, > Configuration: > > > > > > Release Win32 ------ > > > > > > 2>Deleting intermediate and output files for project > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > 1>Building ytab.cpp > > > > > > 2>Compiling... > > > > > > 2>lscript_library.cpp > > > > > > 1>'bison.exe' is not recognized as an internal or external > command, > > > > > > 1>operable program or batch file. > > > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > > > 1>operable program or batch file. > > > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > > > "Building ytab.cpp" > > > > > > 2>lscript_export.cpp > > > > > > 2>lscript_alloc.cpp > > > > > > 2>Generating Code... > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > 2>Creating library... > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > Configuration: > > > > > > Release Win32 ------ > > > > > > 3>Deleting intermediate and output files for project > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > 3>Compiling... > > > > > > 3>lscript_typecheck.cpp > > > > > > 3>lscript_tree.cpp > > > > > > 3>lscript_scope.cpp > > > > > > 3>lscript_resource.cpp > > > > > > 3>lscript_heap.cpp > > > > > > 3>lscript_error.cpp > > > > > > 3>lscript_bytecode.cpp > > > > > > 3>lscript_alloc.cpp > > > > > > 3>Generating Code... > > > > > > 3>Creating library... > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > ========== > > > > > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > > > Still no success :( > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > wrote: > > > > > > > Hi, I'm not sure but when I get link error from obj files I am > sure > > > I > > > > > have > > > > > > > already compile, I rebuild the projects they are issued from (or > at > > > > > least I > > > > > > > recompile their cpp files). Most of the time it is due to a VC > > > problem, > > > > > > > corrupting obj files. > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > Hi, > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not > able > > > to > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ciao, > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > -- > > Ciao, > > > > Ajinkya > > > > -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 04:38:24 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 04:38:28 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <9e52a8c10804060424i4100fa30ufc09add3f97adf2e@mail.gmail.com> Message-ID: <9e52a8c10804060438i223bafa0o95638ed983799291@mail.gmail.com> Well then I must apologize, I'm pretty much out of ideas here. 2008/4/6, Ajinkya Kale : > > I have already seen the wiki. But no help from that solution. > I am getting the same errors on ReleaseForDownload too. > > > On Sun, Apr 6, 2008 at 4:24 AM, Marine Kelley > wrote: > > I'm not sure, but perhaps this link will help : > > > http://wiki.secondlife.com/wiki/Common_compilation_problems#Unresolved_external_symbol_.22int___cdecl_lscript_compile.22_.28VS2005.29 > > > > Also you're still building ReleaseNoOpt. > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > Yes I changed the order and it worked. > > > But when I build newview I get the same old llcompilequeue.obj and > > > llpreviewscript.obj errors. I am fed up due to these same errors > > > evrytime :( I also rebuilt lscript_comiple and > > > lscript_compile_fb_vc8. They were built without any errors ! So why > > > the errors on building newview ? > > > > > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > > > ReleaseNoOpt Win32 ------ > > > 1>Project not selected to build for this solution configuration > > > 2>------ Build started: Project: newview, Configuration: ReleaseNoOpt > > > > > > Win32 ------ > > > 2>Executing pre-build batch file > > > > > > 2>PREBUILD SUCCESSFUL > > > 2>Linking... > > > 2>llcompilequeue.obj : error LNK2019: unresolved external symbol "int > > > __cdecl lscript_compile(char const *,char const *,char const *,int)" > > > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > > > void __thiscall LLFloaterCompileQueue::compile(char const *,class > > > LLUUID const &)" > > > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > > > 2>llpreviewscript.obj : error LNK2001: unresolved external symbol "int > > > __cdecl lscript_compile(char const *,char const *,char const *,int)" > > > (?lscript_compile@@YAHPBD00H@Z) > > > > > > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 unresolved > > externals > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > > > > > 2>newview - 3 error(s), 0 warning(s) > > > > > > ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped > > ========== > > > > > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > > wrote: > > > > Perhaps you have put C:\Cygwin\bin before the VC bin directory... > which > > > > means VC tries to link using the cygwin link.exe instead of its own. > Try > > to > > > > change the order of the paths in your Path variable in VC. > > > > > > > > Hope this helps > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > > Directories\Executable Files\ list. And I rebuilt the > > > > > lscript_compile and lscript_compile_fb_vc8 projects. They were > built > > > > > successfully without any errors. > > > > > > > > > > But now when i try to Build newview I get the following error : > > > > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > > ReleaseForDownload Win32 ------ > > > > > 1>Executing pre-build batch file > > > > > 1>PREBUILD SUCCESSFUL > > > > > 1>Linking... > > > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > > 1>Try `link --help' for more information. > > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > > 1>newview - 1 error(s), 0 warning(s) > > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > > > ========== > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley < > marinekelley@gmail.com> > > > > wrote: > > > > > > It seems your bison.exe and mv.exe files are not in any of the > paths > > > > you've > > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > When I try to recompile lscript_compile and > lscript_compile_fb_vc8 > > I > > > > > > > get the following errors : > > > > > > > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > > > > Configuration: Release Win32 ------ > > > > > > > 1>Deleting intermediate and output files for project > > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > > 2>------ Rebuild All started: Project: lscript_library, > > Configuration: > > > > > > > Release Win32 ------ > > > > > > > 2>Deleting intermediate and output files for project > > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > > 1>Building ytab.cpp > > > > > > > 2>Compiling... > > > > > > > 2>lscript_library.cpp > > > > > > > 1>'bison.exe' is not recognized as an internal or external > > command, > > > > > > > 1>operable program or batch file. > > > > > > > 1>'mv.exe' is not recognized as an internal or external > command, > > > > > > > 1>operable program or batch file. > > > > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > > > > "Building ytab.cpp" > > > > > > > 2>lscript_export.cpp > > > > > > > 2>lscript_alloc.cpp > > > > > > > 2>Generating Code... > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > > 2>Creating library... > > > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > > Configuration: > > > > > > > Release Win32 ------ > > > > > > > 3>Deleting intermediate and output files for project > > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > > 3>Compiling... > > > > > > > 3>lscript_typecheck.cpp > > > > > > > 3>lscript_tree.cpp > > > > > > > 3>lscript_scope.cpp > > > > > > > 3>lscript_resource.cpp > > > > > > > 3>lscript_heap.cpp > > > > > > > 3>lscript_error.cpp > > > > > > > 3>lscript_bytecode.cpp > > > > > > > 3>lscript_alloc.cpp > > > > > > > 3>Generating Code... > > > > > > > 3>Creating library... > > > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > > ========== > > > > > > > > > > > > > > I have also separated the commanline in the properties of > indra.y. > > > > > > > Still no success :( > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > > > wrote: > > > > > > > > Hi, I'm not sure but when I get link error from obj files I > am > > sure > > > > I > > > > > > have > > > > > > > > already compile, I rebuild the projects they are issued from > (or > > at > > > > > > least I > > > > > > > > recompile their cpp files). Most of the time it is due to a > VC > > > > problem, > > > > > > > > corrupting obj files. > > > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am > not > > able > > > > to > > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ciao, > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ciao, > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > > -- > Ciao, > > Ajinkya > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/4844a0f6/attachment-0001.htm From kfa at gmx.net Sun Apr 6 04:47:44 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 04:47:52 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060438i223bafa0o95638ed983799291@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <9e52a8c10804060424i4100fa30ufc09add3f97adf2e@mail.gmail.com> <9e52a8c10804060438i223bafa0o95638ed983799291@mail.gmail.com> Message-ID: <47F8B860.9050807@gmx.net> I've adopted this approach expressed by the most common piece of advice given regarding SL: Clear cache and relog. Only if that doesn't work, we have a problem. Treating VC++ the same way has fixed this particular one for me. Marine Kelley wrote: > Well then I must apologize, I'm pretty much out of ideas here. > > 2008/4/6, Ajinkya Kale >: > > I have already seen the wiki. But no help from that solution. > I am getting the same errors on ReleaseForDownload too. > > > On Sun, Apr 6, 2008 at 4:24 AM, Marine Kelley > > wrote: > > I'm not sure, but perhaps this link will help : > > > http://wiki.secondlife.com/wiki/Common_compilation_problems#Unresolved_external_symbol_.22int___cdecl_lscript_compile.22_.28VS2005.29 > > > > Also you're still building ReleaseNoOpt. > > > > > > > > > > > > 2008/4/6, Ajinkya Kale >: > > > Yes I changed the order and it worked. > > > But when I build newview I get the same old > llcompilequeue.obj and > > > llpreviewscript.obj errors. I am fed up due to these same errors > > > evrytime :( I also rebuilt lscript_comiple and > > > lscript_compile_fb_vc8. They were built without any errors ! > So why > > > the errors on building newview ? > > > > > > 1>------ Skipped Build: Project: win_crash_logger, Configuration: > > > ReleaseNoOpt Win32 ------ > > > 1>Project not selected to build for this solution configuration > > > 2>------ Build started: Project: newview, Configuration: > ReleaseNoOpt > > > > > > Win32 ------ > > > 2>Executing pre-build batch file > > > > > > 2>PREBUILD SUCCESSFUL > > > 2>Linking... > > > 2>llcompilequeue.obj : error LNK2019: unresolved external > symbol "int > > > __cdecl lscript_compile(char const *,char const *,char const > *,int)" > > > (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: > > > void __thiscall LLFloaterCompileQueue::compile(char const *,class > > > LLUUID const &)" > > > (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) > > > 2>llpreviewscript.obj : error LNK2001: unresolved external > symbol "int > > > __cdecl lscript_compile(char const *,char const *,char const > *,int)" > > > (?lscript_compile@@YAHPBD00H@Z) > > > > > > 2>ReleaseNoOpt/newview_noopt.exe : fatal error LNK1120: 1 > unresolved > > externals > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > > > > > 2>newview - 3 error(s), 0 warning(s) > > > > > > ========== Build: 0 succeeded, 1 failed, 20 up-to-date, 1 skipped > > ========== > > > > > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > > > > wrote: > > > > Perhaps you have put C:\Cygwin\bin before the VC bin > directory... which > > > > means VC tries to link using the cygwin link.exe instead of > its own. Try > > to > > > > change the order of the paths in your Path variable in VC. > > > > > > > > Hope this helps > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale >: > > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > > Directories\Executable Files\ list. And I rebuilt the > > > > > lscript_compile and lscript_compile_fb_vc8 projects. They > were built > > > > > successfully without any errors. > > > > > > > > > > But now when i try to Build newview I get the following > error : > > > > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > > ReleaseForDownload Win32 ------ > > > > > 1>Executing pre-build batch file > > > > > 1>PREBUILD SUCCESSFUL > > > > > 1>Linking... > > > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > > 1>Try `link --help' for more information. > > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > > 1>newview - 1 error(s), 0 warning(s) > > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 > skipped > > > > ========== > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > > > > > wrote: > > > > > > It seems your bison.exe and mv.exe files are not in any > of the paths > > > > you've > > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale >: > > > > > > > When I try to recompile lscript_compile and > lscript_compile_fb_vc8 > > I > > > > > > > get the following errors : > > > > > > > > > > > > > > 1>------ Rebuild All started: Project: > lscript_compile_fb_vc8, > > > > > > > Configuration: Release Win32 ------ > > > > > > > 1>Deleting intermediate and output files for project > > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > > 2>------ Rebuild All started: Project: lscript_library, > > Configuration: > > > > > > > Release Win32 ------ > > > > > > > 2>Deleting intermediate and output files for project > > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > > 1>Building ytab.cpp > > > > > > > 2>Compiling... > > > > > > > 2>lscript_library.cpp > > > > > > > 1>'bison.exe' is not recognized as an internal or external > > command, > > > > > > > 1>operable program or batch file. > > > > > > > 1>'mv.exe' is not recognized as an internal or > external command, > > > > > > > 1>operable program or batch file. > > > > > > > 1>Project : error PRJ0019: A tool returned an error > code from > > > > > > > "Building ytab.cpp" > > > > > > > 2>lscript_export.cpp > > > > > > > 2>lscript_alloc.cpp > > > > > > > 2>Generating Code... > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > > 2>Creating library... > > > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > > Configuration: > > > > > > > Release Win32 ------ > > > > > > > 3>Deleting intermediate and output files for project > > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > > 3>Compiling... > > > > > > > 3>lscript_typecheck.cpp > > > > > > > 3>lscript_tree.cpp > > > > > > > 3>lscript_scope.cpp > > > > > > > 3>lscript_resource.cpp > > > > > > > 3>lscript_heap.cpp > > > > > > > 3>lscript_error.cpp > > > > > > > 3>lscript_bytecode.cpp > > > > > > > 3>lscript_alloc.cpp > > > > > > > 3>Generating Code... > > > > > > > 3>Creating library... > > > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > > ========== > > > > > > > > > > > > > > I have also separated the commanline in the properties > of indra.y. > > > > > > > Still no success :( > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > > > > wrote: > > > > > > > > Hi, I'm not sure but when I get link error from obj > files I am > > sure > > > > I > > > > > > have > > > > > > > > already compile, I rebuild the projects they are > issued from (or > > at > > > > > > least I > > > > > > > > recompile their cpp files). Most of the time it is > due to a VC > > > > problem, > > > > > > > > corrupting obj files. > > > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale >: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors > ? I am not > > able > > > > to > > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ciao, > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ciao, > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > > -- > Ciao, > > Ajinkya > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kaleajinkya at gmail.com Sun Apr 6 05:02:03 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 05:02:05 2008 Subject: [sldev] lscript_compile error In-Reply-To: <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: I didnt understand which cache and relog are you talking of ? Can you clarify a bit more ? Thanks. On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley wrote: > Perhaps you have put C:\Cygwin\bin before the VC bin directory... which > means VC tries to link using the cygwin link.exe instead of its own. Try to > change the order of the paths in your Path variable in VC. > > Hope this helps > > > > 2008/4/6, Ajinkya Kale : > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > Directories\Executable Files\ list. And I rebuilt the > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > successfully without any errors. > > > > But now when i try to Build newview I get the following error : > > > > > > 1>------ Build started: Project: newview, Configuration: > > ReleaseForDownload Win32 ------ > > 1>Executing pre-build batch file > > 1>PREBUILD SUCCESSFUL > > 1>Linking... > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > 1>Try `link --help' for more information. > > 1>Project : error PRJ0002 : Error result 1 returned from > > 'C:\cygwin\bin\link.exe'. > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > 1>newview - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > ========== > > > > > > > > Waiting for your suggestions. > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > wrote: > > > It seems your bison.exe and mv.exe files are not in any of the paths > you've > > > provided to VC. > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > > > get the following errors : > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > Configuration: Release Win32 ------ > > > > 1>Deleting intermediate and output files for project > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > 2>------ Rebuild All started: Project: lscript_library, Configuration: > > > > Release Win32 ------ > > > > 2>Deleting intermediate and output files for project > > > > 'lscript_library', configuration 'Release|Win32' > > > > 1>Building ytab.cpp > > > > 2>Compiling... > > > > 2>lscript_library.cpp > > > > 1>'bison.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > 1>operable program or batch file. > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > "Building ytab.cpp" > > > > 2>lscript_export.cpp > > > > 2>lscript_alloc.cpp > > > > 2>Generating Code... > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > 2>Creating library... > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > > > > Release Win32 ------ > > > > 3>Deleting intermediate and output files for project > > > > 'lscript_compile', configuration 'Release|Win32' > > > > 3>Compiling... > > > > 3>lscript_typecheck.cpp > > > > 3>lscript_tree.cpp > > > > 3>lscript_scope.cpp > > > > 3>lscript_resource.cpp > > > > 3>lscript_heap.cpp > > > > 3>lscript_error.cpp > > > > 3>lscript_bytecode.cpp > > > > 3>lscript_alloc.cpp > > > > 3>Generating Code... > > > > 3>Creating library... > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > Still no success :( > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > wrote: > > > > > Hi, I'm not sure but when I get link error from obj files I am sure > I > > > have > > > > > already compile, I rebuild the projects they are issued from (or at > > > least I > > > > > recompile their cpp files). Most of the time it is due to a VC > problem, > > > > > corrupting obj files. > > > > > > > > > > Marine > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > Hi, > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able > to > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > -- > > Ciao, > > > > Ajinkya > > > > -- Ciao, Ajinkya From open at autistici.org Sun Apr 6 05:45:58 2008 From: open at autistici.org (Opensource Obscure) Date: Sun Apr 6 05:46:04 2008 Subject: [sldev] Missing files in 1.19.1.4 + crash when uploading a texture In-Reply-To: References: <9e52a8c10804040041w5da34382g74dfa2ef5774765e@mail.gmail.com> Message-ID: <20080406124558.6FCCA98906@latitanza.investici.org> <47F6069A.90809@gmail.com> Message-ID: X-Sender: open@autistici.org Received: from localhost [127.0.0.1] with HTTP/1.0 (POST); Sun, 06 Apr 2008 12:45:58 +0000 User-Agent: A/I Webmail (roundcube 0.1rc2) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I am experiencing some issues while trying to upload images with both 1.19.1 and 1.19.1.4-RC on Linux. I sometimes get a "file is empty" message error; I still didn't find a way to reproduce it consistently; apparently, I manage to succesfully upload the same file using a slightly older client. Do you think it may be related to what you're talking about here? If yes, how may I provide more useful feedback about this? Opensource Obscure From evan.wong at ieee.org Sun Apr 6 06:08:06 2008 From: evan.wong at ieee.org (Evan Wong) Date: Sun Apr 6 06:08:12 2008 Subject: [sldev] Crash during startup Message-ID: <2e9f48970804060608y136018eds153341f933df1b29@mail.gmail.com> Hi, I'm new here and I'm trying to build and run the viewer (1.19.1.4.RC). After successfully building the viewer, I try to run it in Visual Studio 2008 but I get the an error. It crashes when it says "Initializing texture cache". Does anyone know why this is happening? I've attached the log up until it crashes. Thanks, Evan 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\newview_noopt.exe', Symbols loaded. 'newview_noopt.exe': Loaded 'C:\Windows\System32\ntdll.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\kernel32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\comdlg32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msvcrt.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\shlwapi.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\gdi32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\user32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\advapi32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\rpcrt4.dll' 'newview_noopt.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.6000.16386_none_87e0cb09378714f1\comctl32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\shell32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dinput8.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\glu32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\opengl32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ddraw.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dciman32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\setupapi.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\oleaut32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ole32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dwmapi.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\psapi.dll' 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\xul.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\js3250.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\nspr4.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Windows\System32\wsock32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ws2_32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\nsi.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\winmm.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\oleacc.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msvcr71.dll' 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\plc4.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\plds4.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Windows\System32\version.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\winspool.drv' 'newview_noopt.exe': Loaded 'C:\Windows\System32\mswsock.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\netapi32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\avifil32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msacm32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msvfw32.dll' 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\fmod.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\OpenJPEG.dll', Binary was not built with debug information. 'newview_noopt.exe': Loaded 'C:\Windows\System32\shimeng.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\apphelp.dll' 'newview_noopt.exe': Loaded 'C:\Windows\AppPatch\AcLayers.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\userenv.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\secur32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\mpr.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\imm32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msctf.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\lpk.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\usp10.dll' 'newview_noopt.exe': Loaded 'C:\Program Files\Google\Google Desktop Search\GoogleDesktopNetwork3.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ntmarta.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\Wldap32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\samlib.dll' 'newview_noopt.exe': Unloaded 'C:\Program Files\Google\Google Desktop Search\GoogleDesktopNetwork3.dll' 'newview_noopt.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6000.16386_none_5d07289e07e1d100\comctl32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\uxtheme.dll' 'newview_noopt.exe': Loaded 'C:\Program Files\FlashGet\fgmgr.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\wininet.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\normaliz.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\iertutil.dll' 'newview_noopt.exe': Loaded 'C:\Program Files\Logitech\SetPoint\lgscroll.dll' 'newview_noopt.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_10b2f55f9bffb8f8\msvcr80.dll' 'newview_noopt.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.762_none_10b2f55f9bffb8f8\msvcp80.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dbghelp.dll' 'newview_noopt.exe': Loaded 'C:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\ReleaseNoOpt\llkdu.dll', Binary was not built with debug information. INFO: LLControlGroup::saveToFile: Saving settings to file: C:\Users\Evan\AppData\Roaming\SecondLife\user_settings\settings_default.xml INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. INFO: LLAppViewer::initMarkerFile: Checking marker file for lock... WARNING: ll_apr_warn_status: APR: The system cannot find the file specified. WARNING: ll_apr_warn_status: APR: The system cannot find the file specified. WARNING: ll_apr_warn_status: APR: The system cannot find the file specified. INFO: LLAppViewer::anotherInstanceRunning: Checking marker file for lock... INFO: LLAppViewer::anotherInstanceRunning: Marker file isn't locked. INFO: LLAppViewer::initMarkerFile: Exec marker found: program froze on previous execution INFO: LLAppViewer::initMarkerFile: Marker file created. INFO: LLAppViewer::initMarkerFile: Marker file locked. INFO: Exiting initMarkerFile(). INFO: LLAppViewer::writeSystemInfo: Second Life version 1.19.1 INFO: LLAppViewer::writeSystemInfo: Local time: 2008-04-06T20:27:18 W. Australia Standard Time INFO: LLAppViewer::writeSystemInfo: CPU info: // CPU General Information ////////////////////////// Processor name: Intel Core 2 Series Processor Frequency: 2194.50 MHz Vendor: GenuineIntel Family: Intel Pentium Pro/2/3, Core Extended family: 0 Model: Intel Core 2 Series Processor Extended model: 0 Type: Brand ID: Processor Serial: Disabled // CPU Configuration //////////////////// L1 instruction cache: Not present L1 data cache: Not present L2 cache: Not present L3 cache: Not present Trace cache: Not present Instruction TLB: Not present Data TLB: Not present Max Supported CPUID-Level: 0x0000000A Max Supported Ext. CPUID-Level: 0x80000008 // CPU Extensions ///////////////// AA64 AMD 64-bit Architecture: No ACPI Thermal Monitor And Clock Control: Yes APIC Advanced Programmable Interrupt Controller: Yes APIC-ID: 1 CLFSH CLFLUSH Instruction Presence: Yes CLFLUSH Instruction Cache Line Size: 8 CMOV Conditional Move And Compare Instructions: Yes CX8 COMPXCHG8B Instruction: Yes DE Debugging Extensions: Yes DS Debug Store: Yes FGPAT Page Attribute Table: Yes FPU Floating Point Unit: Yes FXSR Fast Streaming SIMD Extensions Save/Restore: Yes HT Hyper Threading: Yes IA64 Intel 64-Bit Architecture: No MCA Machine Check Architecture: Yes MCE Machine Check Exception: Yes MMX Multimedia Extensions: Yes MMX+ Multimedia Extensions: No MSR Model Specific Registers: Yes MTRR Memory Type Range Registers: Yes PAE Physical Address Extension: Yes PGE PTE Global Flag: Yes PN Processor Serial Number: Disabled PSE Page Size Extensions: Yes PSE36 36-bit Page Size Extension: Yes SEP Fast System Call: Yes SS Self Snoop: Yes SSE Streaming SIMD Extensions: Yes SSE2 Streaming SIMD 2 Extensions: Yes ALTVEC Altivec Extensions: No TM Thermal Monitor: Yes TSC Time Stamp Counter: Yes VME Virtual 8086 Mode Enhancements: Yes 3DNow! Instructions: No Enhanced 3DNow! Instructions: No ->mHasSSE: 1 ->mHasSSE2: 1 ->mHasAltivec: 0 ->mCPUMhz: 2194 ->mCPUString: Intel Core 2 Series Processor (2194 MHz) INFO: LLAppViewer::writeSystemInfo: Memory info: Percent Memory use: 64% Total Physical KB: 2094664 Avail Physical KB: 734644 Total page KB: 4403844 Avail page KB: 1432532 Total Virtual KB: 2097024 Avail Virtual KB: 1961260 INFO: LLAppViewer::writeSystemInfo: OS: Microsoft Windows Vista INFO: LLAppViewer::writeSystemInfo: OS info: Microsoft Windows Vista (Build 6000) INFO: LLAppViewer::init: Loading configuration file C:\Users\Evan\AppData\Roaming\SecondLife\user_settings\settings.xml WARNING: LLControlGroup::loadFromFile() : Trying to set "FloaterMapRect", setting doesn't exist. WARNING: LLControlGroup::loadFromFile() : Trying to set "FloaterWorldMapRect", setting doesn't exist. WARNING: LLControlGroup::loadFromFile() : Trying to set "GraphicsCardMemorySetting", setting doesn't exist. WARNING: LLControlGroup::loadFromFile() : Trying to set "RenderAvatarMode", setting doesn't exist. INFO: LLAppViewer::init: Loading art table from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\viewerart.xml INFO: LLAppViewer::init: Loading art table from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\skins\textures\textures.xml INFO: LLAppViewer::init: Loading base colors from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\colors_base.xml INFO: LLAppViewer::init: Loading user colors from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\colors.xml INFO: LLAppViewer::init: Failed to load user colors from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\colors.xml INFO: LLAppViewer::init: Loading legacy colors from c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\colors.ini INFO: update_vector_performances: Vectorization : DISABLED INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT INFO: update_vector_performances: Vectorized Skinning : DISABLED INFO: LLAppViewerWin32::initHardwareTest: Attempting to poll DirectX for hardware info INFO: LLDXHardware::getInfo: CoCreateInstance IID_IDxDiagProvider 'newview_noopt.exe': Loaded 'C:\Windows\System32\clbcatq.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dxdiagn.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dxgi.dll' INFO: LLDXHardware::getInfo: dx_diag_providerp->Initialize 'newview_noopt.exe': Loaded 'C:\Windows\System32\wbem\wbemprox.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\wbem\wbemcomn.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\rsaenh.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\wbem\wbemsvc.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\wbem\fastprox.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ntdsapi.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dnsapi.dll' INFO: LLDXHardware::getInfo: dx_diag_providerp->GetRootContainer INFO: LLDXHardware::getInfo: dx_diag_rootp->GetChildContainer 'newview_noopt.exe': Loaded 'C:\Windows\System32\winbrand.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\dsound.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\powrprof.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\d3d9.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\d3d8thk.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\nvd3dum.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\wintrust.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\crypt32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\msasn1.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\imagehlp.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\mscat32.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\ncrypt.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\bcrypt.dll' 'newview_noopt.exe': Unloaded 'C:\Windows\System32\nvd3dum.dll' 'newview_noopt.exe': Unloaded 'C:\Windows\System32\d3d9.dll' 'newview_noopt.exe': Unloaded 'C:\Windows\System32\d3d8thk.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\nvd3dum.dll' 'newview_noopt.exe': Unloaded 'C:\Windows\System32\nvd3dum.dll' 'newview_noopt.exe': Loaded 'C:\Windows\System32\nvd3dum.dll' 'newview_noopt.exe': Unloaded 'C:\Windows\System32\nvd3dum.dll' INFO: LLDXHardware::getInfo: devices_containerp->GetChildContainer INFO: LLDXHardware::getInfo: VRAM Detected: 128 DX9 string: 128 MB 'newview_noopt.exe': Unloaded 'C:\Windows\System32\mscat32.dll' INFO: LLAppViewerWin32::initHardwareTest: Done polling DirectX for hardware info WARNING: LLWinDebug::setupExceptionHandler: Our exception handler (00419F24) replaced with 03744B98! WARNING: LLAppViewerWin32::initHardwareTest: Someone took over my exception handler (post hardware probe)! INFO: LLAppViewerWin32::initHardwareTest: Detected VRAM: 128 INFO: LLTextureCache::initCache: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB INFO: LLTextureCache::purgeTextures: TEXTURE CACHE: Reading Entries... INFO: LLTextureCache::purgeTextures: TEXTURE CACHE: Validating: 2 INFO: LLTextureCache::purgeTextures: TEXTURE CACHE: Writing Entries: 1969 INFO: LLTextureCache::purgeTextures: TEXTURE CACHE: PURGED: 0 ENTRIES: 1969 CACHE SIZE: 45358080 MB INFO: LLAppViewer::initCache: VFS CACHE SIZE: 100 MB INFO: LLVFS::LLVFS: VFS: Using index file C:\Users\Evan\AppData\Roaming\SecondLife\cache\index.db2.x.9303 and data file C:\Users\Evan\AppData\Roaming\SecondLife\cache\data.db2.x.9303 INFO: LLVFS::LLVFS: VFS: Using index file c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\static_index.db2 and data file c:\Users\Evan\Documents\Uni\Year 4\Project\linden\indra\newview\app_settings\static_data.db2 INFO: LLAppViewer::initWindow: Initializing window... 'newview_noopt.exe': Loaded 'C:\Windows\System32\nvoglv32.dll' The thread 'Win32 Thread' (0xa04) has exited with code 0 (0x0). WARNING: LLGLManager::initWGL: No ARB WGL render texture extensions INFO: LLWindowWin32::LLWindowWin32: Swap Method: Exchange INFO: LLWindowWin32::LLWindowWin32: GL buffer: Color Bits 32 Alpha Bits 8 Depth Bits 24 INFO: LLGLManager::initExtensions: Couldn't initialize GL_EXT_paletted_texture INFO: LLGLManager::initExtensions: GL Probe: Getting symbols INFO: LLGLManager::initExtensions: GL Probe: Got symbols INFO: LLWindowWin32::LLWindowWin32: Disabling vertical sync INFO: LLWindowWin32::LLWindowWin32: Previous gamma: 1 'newview_noopt.exe': Loaded 'C:\Windows\System32\hid.dll' INFO: LLViewerWindow::LLViewerWindow: Loading feature tables. INFO: LLFeatureManager::loadGPUClass: GPU is NVIDIA GeForce 8400 INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class1 INFO: LLFeatureManager::maskFeatures: Applying Feature Mask: Class1 INFO: LLFeatureList::maskList: Feature mask Class1 Feature RenderVBOEnable Mask: 1 Now: 1 INFO: LLFeatureManager::applyRecommendedSettings: Applying Recommended Features INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class1 INFO: LLFeatureManager::maskFeatures: Applying Feature Mask: Class1 INFO: LLFeatureList::maskList: Feature mask Class1 Feature RenderVBOEnable Mask: 1 Now: 1 INFO: LLFeatureManager::maskFeatures: Applying Feature Mask: Mid INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderAnisotropic Mask: 0 Now: 0 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderAvatarCloth Mask: 0 Now: 0 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderAvatarLODFactor Mask: 0.5 Now: 0.5 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderAvatarVP Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderFarClip Mask: 96 Now: 96 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderFlexTimeFactor Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderGlowResolutionPow Mask: 8 Now: 8 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderLightingDetail Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderMaxPartCount Mask: 2048 Now: 2048 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderObjectBump Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderReflectionDetail Mask: 0 Now: 0 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderTerrainDetail Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderTerrainLODFactor Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderTreeLODFactor Mask: 0.5 Now: 0.5 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderUseImpostors Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderVolumeLODFactor Mask: 1.125 Now: 1.125 INFO: LLFeatureList::maskList: Feature mask Mid Feature RenderWaterReflections Mask: 0 Now: 0 INFO: LLFeatureList::maskList: Feature mask Mid Feature VertexShaderEnable Mask: 1 Now: 1 INFO: LLFeatureList::maskList: Feature mask Mid Feature WLSkyDetail Mask: 48 Now: 48 INFO: LLFeatureList::maskList: Feature mask Mid Feature WindLightUseAtmosShaders Mask: 0 Now: 0 INFO: LLFeatureList::dump: Feature list: default INFO: LLFeatureList::dump: -------------- INFO: LLFeatureList::dump: Disregard128DefaultDrawDistance 1:1 INFO: LLFeatureList::dump: Disregard96DefaultDrawDistance 1:1 INFO: LLFeatureList::dump: RenderAnisotropic 1:0 INFO: LLFeatureList::dump: RenderAvatarCloth 1:0 INFO: LLFeatureList::dump: RenderAvatarLODFactor 1:0.5 INFO: LLFeatureList::dump: RenderAvatarVP 1:1 INFO: LLFeatureList::dump: RenderCubeMap 1:1 INFO: LLFeatureList::dump: RenderFarClip 1:96 INFO: LLFeatureList::dump: RenderFlexTimeFactor 1:1 INFO: LLFeatureList::dump: RenderFogRatio 1:4 INFO: LLFeatureList::dump: RenderGamma 1:0 INFO: LLFeatureList::dump: RenderGlowResolutionPow 1:8 INFO: LLFeatureList::dump: RenderLightingDetail 1:1 INFO: LLFeatureList::dump: RenderMaxPartCount 1:2048 INFO: LLFeatureList::dump: RenderNightBrightness 1:1 INFO: LLFeatureList::dump: RenderObjectBump 1:1 INFO: LLFeatureList::dump: RenderReflectionDetail 1:0 INFO: LLFeatureList::dump: RenderTerrainDetail 1:1 INFO: LLFeatureList::dump: RenderTerrainLODFactor 1:1 INFO: LLFeatureList::dump: RenderTreeLODFactor 1:0.5 INFO: LLFeatureList::dump: RenderUseImpostors 1:1 INFO: LLFeatureList::dump: RenderVBOEnable 1:1 INFO: LLFeatureList::dump: RenderVolumeLODFactor 1:1.125 INFO: LLFeatureList::dump: RenderWaterReflections 1:0 INFO: LLFeatureList::dump: UseOcclusion 1:1 INFO: LLFeatureList::dump: UseStartScreen 1:1 INFO: LLFeatureList::dump: VertexShaderEnable 1:1 INFO: LLFeatureList::dump: WLSkyDetail 1:48 INFO: LLFeatureList::dump: WindLightUseAtmosShaders 1:0 INFO: LLFeatureList::dump: WARNING: LLFeatureManager::applyFeatures: AHHH! Control setting RenderNightBrightness does not exist! INFO: LLViewerImageList::doPreloadImages: Preloading images... First-chance exception at 0x03700948 in newview_noopt.exe: 0xC0000005: Access violation writing location 0x08b46000. First-chance exception at 0x76bab09e in newview_noopt.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0545f3e0.. Unhandled exception at 0x76bab09e in newview_noopt.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0545f3e0.. newview_noopt.exe has triggered a breakpoint First-chance exception at 0x00000094 in newview_noopt.exe: 0xC0000005: Access violation. Unhandled exception at 0x00000094 in newview_noopt.exe: 0xC0000005: Access violation. First-chance exception at 0x00000094 in newview_noopt.exe: 0xC0000005: Access violation. Unhandled exception at 0x00000094 in newview_noopt.exe: 0xC0000005: Access violation. The program '[156] newview_noopt.exe: Native' has exited with code 0 (0x0). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/0f091e92/attachment-0001.htm From carjay at gmx.net Sun Apr 6 06:20:10 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Apr 6 06:20:07 2008 Subject: [sldev] 1.19.1.4 RC - Crashes after successful build In-Reply-To: <47F893E5.2090801@gmx.net> References: <47F893E5.2090801@gmx.net> Message-ID: <47F8CE0A.9000301@gmx.net> Hallo Felix, Felix Duesenburg wrote: > Sometimes the logs show an assert failure like the one attached, > sometimes it doesn't seem to have had the time to write anything > anymore before going to byte nirvana, and the log ends without any > indication of an error. Only one thing in common I noticed: See the > multiple 'UNABLE TO LOAD TEXTURE' lines in the log, sometimes over a > hundred for the same file, but the retries counter never increases. Is > that something to worry about? The dozens of decode failures are definitely not ok, especially since they occur with images that are always present on your system (in skins/textures). I think the retrycount only increases if the texture not locally available (it only retries to read it from cache/network). Did you try building a debug version to get a better idea why the crash occurred? These are also images necessary to draw the GUI so if they miss you should notice that when looking at various menus. What puzzles me is that you use the viewer in place of the official one and if that works with the same set of textures it is a bit mystifying. The final assert also points in the direction of the image fetch worker. Regards, Carsten From kaleajinkya at gmail.com Sun Apr 6 12:13:32 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 12:13:34 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: Finally finally finally.....The viewer was built successfully !! The "Converting files for MSVS2005" link ( https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 ) helped. Phew !! But when I try to run the newview.exe it gives me an error prompt : " This application has failed to start because fmod.dll was not found. Re-installing the application may fix this problem. " Any suggestions ? On Sun, Apr 6, 2008 at 5:02 AM, Ajinkya Kale wrote: > I didnt understand which cache and relog are you talking of ? Can you > clarify a bit more ? > > Thanks. > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley wrote: > > Perhaps you have put C:\Cygwin\bin before the VC bin directory... which > > means VC tries to link using the cygwin link.exe instead of its own. Try to > > change the order of the paths in your Path variable in VC. > > > > Hope this helps > > > > > > > > 2008/4/6, Ajinkya Kale : > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > Directories\Executable Files\ list. And I rebuilt the > > > lscript_compile and lscript_compile_fb_vc8 projects. They were built > > > successfully without any errors. > > > > > > But now when i try to Build newview I get the following error : > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > ReleaseForDownload Win32 ------ > > > 1>Executing pre-build batch file > > > 1>PREBUILD SUCCESSFUL > > > 1>Linking... > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > 1>Try `link --help' for more information. > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > 'C:\cygwin\bin\link.exe'. > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > 1>newview - 1 error(s), 0 warning(s) > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > ========== > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > wrote: > > > > It seems your bison.exe and mv.exe files are not in any of the paths > > you've > > > > provided to VC. > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > When I try to recompile lscript_compile and lscript_compile_fb_vc8 I > > > > > get the following errors : > > > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > > Configuration: Release Win32 ------ > > > > > 1>Deleting intermediate and output files for project > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > 2>------ Rebuild All started: Project: lscript_library, Configuration: > > > > > Release Win32 ------ > > > > > 2>Deleting intermediate and output files for project > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > 1>Building ytab.cpp > > > > > 2>Compiling... > > > > > 2>lscript_library.cpp > > > > > 1>'bison.exe' is not recognized as an internal or external command, > > > > > 1>operable program or batch file. > > > > > 1>'mv.exe' is not recognized as an internal or external command, > > > > > 1>operable program or batch file. > > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > > "Building ytab.cpp" > > > > > 2>lscript_export.cpp > > > > > 2>lscript_alloc.cpp > > > > > 2>Generating Code... > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > 2>Creating library... > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > 3>------ Rebuild All started: Project: lscript_compile, Configuration: > > > > > Release Win32 ------ > > > > > 3>Deleting intermediate and output files for project > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > 3>Compiling... > > > > > 3>lscript_typecheck.cpp > > > > > 3>lscript_tree.cpp > > > > > 3>lscript_scope.cpp > > > > > 3>lscript_resource.cpp > > > > > 3>lscript_heap.cpp > > > > > 3>lscript_error.cpp > > > > > 3>lscript_bytecode.cpp > > > > > 3>lscript_alloc.cpp > > > > > 3>Generating Code... > > > > > 3>Creating library... > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped ========== > > > > > > > > > > I have also separated the commanline in the properties of indra.y. > > > > > Still no success :( > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > wrote: > > > > > > Hi, I'm not sure but when I get link error from obj files I am sure > > I > > > > have > > > > > > already compile, I rebuild the projects they are issued from (or at > > > > least I > > > > > > recompile their cpp files). Most of the time it is due to a VC > > problem, > > > > > > corrupting obj files. > > > > > > > > > > > > Marine > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > Hi, > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am not able > > to > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ciao, > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > -- > Ciao, > Ajinkya > -- Ciao, Ajinkya From evan.wong at ieee.org Sun Apr 6 12:22:00 2008 From: evan.wong at ieee.org (Evan Wong) Date: Sun Apr 6 12:22:05 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060325o7ce69087wa5fff13d19aff2e7@mail.gmail.com> <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> Message-ID: <2e9f48970804061222u4f2396a5v719d03ab81123b76@mail.gmail.com> Hi Ajinkya, You probably need fmod copied to the directory. Refer to https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Fmod Regards, Evan On Mon, Apr 7, 2008 at 3:13 AM, Ajinkya Kale wrote: > Finally finally finally.....The viewer was built successfully !! The > "Converting files for MSVS2005" link ( > https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > ) helped. Phew !! > > But when I try to run the newview.exe it gives me an error prompt : > > " This application has failed to start because fmod.dll was not found. > Re-installing the application may fix this problem. " > > Any suggestions ? > > On Sun, Apr 6, 2008 at 5:02 AM, Ajinkya Kale > wrote: > > I didnt understand which cache and relog are you talking of ? Can you > > clarify a bit more ? > > > > Thanks. > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > wrote: > > > Perhaps you have put C:\Cygwin\bin before the VC bin directory... > which > > > means VC tries to link using the cygwin link.exe instead of its own. > Try to > > > change the order of the paths in your Path variable in VC. > > > > > > Hope this helps > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > Directories\Executable Files\ list. And I rebuilt the > > > > lscript_compile and lscript_compile_fb_vc8 projects. They were > built > > > > successfully without any errors. > > > > > > > > But now when i try to Build newview I get the following error : > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > ReleaseForDownload Win32 ------ > > > > 1>Executing pre-build batch file > > > > 1>PREBUILD SUCCESSFUL > > > > 1>Linking... > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > 1>Try `link --help' for more information. > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > 1>newview - 1 error(s), 0 warning(s) > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped > > > ========== > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley < > marinekelley@gmail.com> > > > wrote: > > > > > It seems your bison.exe and mv.exe files are not in any of the > paths > > > you've > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > When I try to recompile lscript_compile and > lscript_compile_fb_vc8 I > > > > > > get the following errors : > > > > > > > > > > > > 1>------ Rebuild All started: Project: lscript_compile_fb_vc8, > > > > > > Configuration: Release Win32 ------ > > > > > > 1>Deleting intermediate and output files for project > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > 2>------ Rebuild All started: Project: lscript_library, > Configuration: > > > > > > Release Win32 ------ > > > > > > 2>Deleting intermediate and output files for project > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > 1>Building ytab.cpp > > > > > > 2>Compiling... > > > > > > 2>lscript_library.cpp > > > > > > 1>'bison.exe' is not recognized as an internal or external > command, > > > > > > 1>operable program or batch file. > > > > > > 1>'mv.exe' is not recognized as an internal or external > command, > > > > > > 1>operable program or batch file. > > > > > > 1>Project : error PRJ0019: A tool returned an error code from > > > > > > "Building ytab.cpp" > > > > > > 2>lscript_export.cpp > > > > > > 2>lscript_alloc.cpp > > > > > > 2>Generating Code... > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > 2>Creating library... > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > Configuration: > > > > > > Release Win32 ------ > > > > > > 3>Deleting intermediate and output files for project > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > 3>Compiling... > > > > > > 3>lscript_typecheck.cpp > > > > > > 3>lscript_tree.cpp > > > > > > 3>lscript_scope.cpp > > > > > > 3>lscript_resource.cpp > > > > > > 3>lscript_heap.cpp > > > > > > 3>lscript_error.cpp > > > > > > 3>lscript_bytecode.cpp > > > > > > 3>lscript_alloc.cpp > > > > > > 3>Generating Code... > > > > > > 3>Creating library... > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > ========== > > > > > > > > > > > > I have also separated the commanline in the properties of > indra.y. > > > > > > Still no success :( > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley < > marinekelley@gmail.com> > > > > > wrote: > > > > > > > Hi, I'm not sure but when I get link error from obj files I > am sure > > > I > > > > > have > > > > > > > already compile, I rebuild the projects they are issued from > (or at > > > > > least I > > > > > > > recompile their cpp files). Most of the time it is due to a > VC > > > problem, > > > > > > > corrupting obj files. > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > Hi, > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? I am > not able > > > to > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ciao, > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > -- > > Ciao, > > Ajinkya > > > > > > -- > Ciao, > Ajinkya > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/ab0dd281/attachment-0001.htm From kaleajinkya at gmail.com Sun Apr 6 12:37:06 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 12:37:11 2008 Subject: [sldev] lscript_compile error In-Reply-To: <2e9f48970804061233q23350ddax9eab24740cde6c0d@mail.gmail.com> References: <9e52a8c10804060357o3ef21338i5125ce20f143ac58@mail.gmail.com> <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <2e9f48970804061222u4f2396a5v719d03ab81123b76@mail.gmail.com> <2e9f48970804061233q23350ddax9eab24740cde6c0d@mail.gmail.com> Message-ID: I did copy fmod.dll to the ReleaseNoOpt and ReleaseForDownload directories . It gives me the following error message box : ERROR: LLAlertDialogue::parseAlerts:Problem reading UI Alerts file: alerts.xml On Sun, Apr 6, 2008 at 12:33 PM, Evan Wong wrote: > fmod.dll was copied for me automatically into the newview\ReleaseNoOpt > directory when I built it on Visual Studio with ReleaseNoOpt configuration. > If it didn't for you, try copying it into the newview\ReleaseNoOpt > directory. > > Regards, > Evan > > > > On Mon, Apr 7, 2008 at 3:30 AM, Ajinkya Kale wrote: > > Do I need the fmod.dll in the newview\ReleaseNoOpt or > > newview\ReleaseForDownload Directories too ? > > > > > > > > > > On Sun, Apr 6, 2008 at 12:25 PM, Ajinkya Kale > wrote: > > > I have already copied fmod.dll to the newview directory. > > > > > > > > > > > > On Sun, Apr 6, 2008 at 12:22 PM, Evan Wong wrote: > > > > Hi Ajinkya, > > > > > > > > You probably need fmod copied to the directory. Refer to > > > > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Fmod > > > > > > > > Regards, > > > > Evan > > > > > > > > > > > > > > > > On Mon, Apr 7, 2008 at 3:13 AM, Ajinkya Kale > wrote: > > > > > > > > > > > > > > > > > > > > Finally finally finally.....The viewer was built successfully !! > The > > > > > "Converting files for MSVS2005" link ( > > > > > > https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > > > > > ) helped. Phew !! > > > > > > > > > > But when I try to run the newview.exe it gives me an error prompt : > > > > > > > > > > " This application has failed to start because fmod.dll was not > found. > > > > > Re-installing the application may fix this problem. " > > > > > > > > > > Any suggestions ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 5:02 AM, Ajinkya Kale > > > > > wrote: > > > > > > I didnt understand which cache and relog are you talking of ? Can > you > > > > > > clarify a bit more ? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > > > > > wrote: > > > > > > > Perhaps you have put C:\Cygwin\bin before the VC bin > directory... > > > > which > > > > > > > means VC tries to link using the cygwin link.exe instead of > its own. > > > > Try to > > > > > > > change the order of the paths in your Path variable in VC. > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > > > > > Directories\Executable Files\ list. And I rebuilt the > > > > > > > > lscript_compile and lscript_compile_fb_vc8 projects. They > were > > > > built > > > > > > > > successfully without any errors. > > > > > > > > > > > > > > > > But now when i try to Build newview I get the following > error : > > > > > > > > > > > > > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > > > > > ReleaseForDownload Win32 ------ > > > > > > > > 1>Executing pre-build batch file > > > > > > > > 1>PREBUILD SUCCESSFUL > > > > > > > > 1>Linking... > > > > > > > > > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > > > > > 1>Try `link --help' for more information. > > > > > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > > > > > 1>newview - 1 error(s), 0 warning(s) > > > > > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 > skipped > > > > > > > ========== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > > > > > > > > > > wrote: > > > > > > > > > It seems your bison.exe and mv.exe files are not in any of > the > > > > paths > > > > > > > you've > > > > > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > When I try to recompile lscript_compile and > > > > lscript_compile_fb_vc8 I > > > > > > > > > > get the following errors : > > > > > > > > > > > > > > > > > > > > 1>------ Rebuild All started: Project: > lscript_compile_fb_vc8, > > > > > > > > > > Configuration: Release Win32 ------ > > > > > > > > > > 1>Deleting intermediate and output files for project > > > > > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > > > > > 2>------ Rebuild All started: Project: lscript_library, > > > > Configuration: > > > > > > > > > > Release Win32 ------ > > > > > > > > > > 2>Deleting intermediate and output files for project > > > > > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > > > > > 1>Building ytab.cpp > > > > > > > > > > 2>Compiling... > > > > > > > > > > 2>lscript_library.cpp > > > > > > > > > > 1>'bison.exe' is not recognized as an internal or > external > > > > command, > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > 1>'mv.exe' is not recognized as an internal or external > > > > command, > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > 1>Project : error PRJ0019: A tool returned an error code > from > > > > > > > > > > "Building ytab.cpp" > > > > > > > > > > 2>lscript_export.cpp > > > > > > > > > > 2>lscript_alloc.cpp > > > > > > > > > > 2>Generating Code... > > > > > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > > > > > 2>Creating library... > > > > > > > > > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > > > > Configuration: > > > > > > > > > > Release Win32 ------ > > > > > > > > > > 3>Deleting intermediate and output files for project > > > > > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > > > > > 3>Compiling... > > > > > > > > > > 3>lscript_typecheck.cpp > > > > > > > > > > 3>lscript_tree.cpp > > > > > > > > > > 3>lscript_scope.cpp > > > > > > > > > > 3>lscript_resource.cpp > > > > > > > > > > 3>lscript_heap.cpp > > > > > > > > > > 3>lscript_error.cpp > > > > > > > > > > 3>lscript_bytecode.cpp > > > > > > > > > > 3>lscript_alloc.cpp > > > > > > > > > > 3>Generating Code... > > > > > > > > > > 3>Creating library... > > > > > > > > > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > > > > ========== > > > > > > > > > > > > > > > > > > > > I have also separated the commanline in the properties > of > > > > indra.y. > > > > > > > > > > Still no success :( > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > > > > > > > > wrote: > > > > > > > > > > > Hi, I'm not sure but when I get link error from obj > files I > > > > am sure > > > > > > > I > > > > > > > > > have > > > > > > > > > > > already compile, I rebuild the projects they are > issued from > > > > (or at > > > > > > > > > least I > > > > > > > > > > > recompile their cpp files). Most of the time it is due > to a > > > > VC > > > > > > > problem, > > > > > > > > > > > corrupting obj files. > > > > > > > > > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? > I am > > > > not able > > > > > > > to > > > > > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Ciao, > > > > > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Ciao, > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ciao, > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ciao, > > > > > Ajinkya > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > -- > > > Ciao, > > > Ajinkya > > > > > > > > > > > -- > > Ciao, > > Ajinkya > > > > -- Ciao, Ajinkya From kaleajinkya at gmail.com Sun Apr 6 12:53:55 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Apr 6 12:53:58 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <2e9f48970804061222u4f2396a5v719d03ab81123b76@mail.gmail.com> <2e9f48970804061233q23350ddax9eab24740cde6c0d@mail.gmail.com> Message-ID: Directly making the viewer run from Visual Studio solved the problem. Thank you everyone who helped me setup the viewer (especially Marine, Felix and Evan) On Sun, Apr 6, 2008 at 12:37 PM, Ajinkya Kale wrote: > I did copy fmod.dll to the ReleaseNoOpt and ReleaseForDownload > directories . It gives me the following error message box : > > ERROR: LLAlertDialogue::parseAlerts:Problem reading UI Alerts file: alerts.xml > > > > > On Sun, Apr 6, 2008 at 12:33 PM, Evan Wong wrote: > > fmod.dll was copied for me automatically into the newview\ReleaseNoOpt > > directory when I built it on Visual Studio with ReleaseNoOpt configuration. > > If it didn't for you, try copying it into the newview\ReleaseNoOpt > > directory. > > > > Regards, > > Evan > > > > > > > > On Mon, Apr 7, 2008 at 3:30 AM, Ajinkya Kale wrote: > > > Do I need the fmod.dll in the newview\ReleaseNoOpt or > > > newview\ReleaseForDownload Directories too ? > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 12:25 PM, Ajinkya Kale > > wrote: > > > > I have already copied fmod.dll to the newview directory. > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 12:22 PM, Evan Wong wrote: > > > > > Hi Ajinkya, > > > > > > > > > > You probably need fmod copied to the directory. Refer to > > > > > > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Fmod > > > > > > > > > > Regards, > > > > > Evan > > > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2008 at 3:13 AM, Ajinkya Kale > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Finally finally finally.....The viewer was built successfully !! > > The > > > > > > "Converting files for MSVS2005" link ( > > > > > > > > https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > > > > > > ) helped. Phew !! > > > > > > > > > > > > But when I try to run the newview.exe it gives me an error prompt : > > > > > > > > > > > > " This application has failed to start because fmod.dll was not > > found. > > > > > > Re-installing the application may fix this problem. " > > > > > > > > > > > > Any suggestions ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 5:02 AM, Ajinkya Kale > > > > > > > wrote: > > > > > > > I didnt understand which cache and relog are you talking of ? Can > > you > > > > > > > clarify a bit more ? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > > > > > > > wrote: > > > > > > > > Perhaps you have put C:\Cygwin\bin before the VC bin > > directory... > > > > > which > > > > > > > > means VC tries to link using the cygwin link.exe instead of > > its own. > > > > > Try to > > > > > > > > change the order of the paths in your Path variable in VC. > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > Ok. So now what i did is I added C:\cygwin\bin to the VC++ > > > > > > > > > Directories\Executable Files\ list. And I rebuilt the > > > > > > > > > lscript_compile and lscript_compile_fb_vc8 projects. They > > were > > > > > built > > > > > > > > > successfully without any errors. > > > > > > > > > > > > > > > > > > But now when i try to Build newview I get the following > > error : > > > > > > > > > > > > > > > > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > > > > > > ReleaseForDownload Win32 ------ > > > > > > > > > 1>Executing pre-build batch file > > > > > > > > > 1>PREBUILD SUCCESSFUL > > > > > > > > > 1>Linking... > > > > > > > > > > > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > > > > > > 1>Try `link --help' for more information. > > > > > > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > > > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > > > > > > 1>newview - 1 error(s), 0 warning(s) > > > > > > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 > > skipped > > > > > > > > ========== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > > > > > > > > > > > > wrote: > > > > > > > > > > It seems your bison.exe and mv.exe files are not in any of > > the > > > > > paths > > > > > > > > you've > > > > > > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > When I try to recompile lscript_compile and > > > > > lscript_compile_fb_vc8 I > > > > > > > > > > > get the following errors : > > > > > > > > > > > > > > > > > > > > > > 1>------ Rebuild All started: Project: > > lscript_compile_fb_vc8, > > > > > > > > > > > Configuration: Release Win32 ------ > > > > > > > > > > > 1>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_compile_fb_vc8', configuration 'Release|Win32' > > > > > > > > > > > 2>------ Rebuild All started: Project: lscript_library, > > > > > Configuration: > > > > > > > > > > > Release Win32 ------ > > > > > > > > > > > 2>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > > > > > > 1>Building ytab.cpp > > > > > > > > > > > 2>Compiling... > > > > > > > > > > > 2>lscript_library.cpp > > > > > > > > > > > 1>'bison.exe' is not recognized as an internal or > > external > > > > > command, > > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > > 1>'mv.exe' is not recognized as an internal or external > > > > > command, > > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > > 1>Project : error PRJ0019: A tool returned an error code > > from > > > > > > > > > > > "Building ytab.cpp" > > > > > > > > > > > 2>lscript_export.cpp > > > > > > > > > > > 2>lscript_alloc.cpp > > > > > > > > > > > 2>Generating Code... > > > > > > > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > > > > > > 2>Creating library... > > > > > > > > > > > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > > > > > > 3>------ Rebuild All started: Project: lscript_compile, > > > > > Configuration: > > > > > > > > > > > Release Win32 ------ > > > > > > > > > > > 3>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > > > > > > 3>Compiling... > > > > > > > > > > > 3>lscript_typecheck.cpp > > > > > > > > > > > 3>lscript_tree.cpp > > > > > > > > > > > 3>lscript_scope.cpp > > > > > > > > > > > 3>lscript_resource.cpp > > > > > > > > > > > 3>lscript_heap.cpp > > > > > > > > > > > 3>lscript_error.cpp > > > > > > > > > > > 3>lscript_bytecode.cpp > > > > > > > > > > > 3>lscript_alloc.cpp > > > > > > > > > > > 3>Generating Code... > > > > > > > > > > > 3>Creating library... > > > > > > > > > > > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 skipped > > > > > ========== > > > > > > > > > > > > > > > > > > > > > > I have also separated the commanline in the properties > > of > > > > > indra.y. > > > > > > > > > > > Still no success :( > > > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi, I'm not sure but when I get link error from obj > > files I > > > > > am sure > > > > > > > > I > > > > > > > > > > have > > > > > > > > > > > > already compile, I rebuild the projects they are > > issued from > > > > > (or at > > > > > > > > > > least I > > > > > > > > > > > > recompile their cpp files). Most of the time it is due > > to a > > > > > VC > > > > > > > > problem, > > > > > > > > > > > > corrupting obj files. > > > > > > > > > > > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for the > > > > > > > > > > > > > llcompilequeue.obj and llpreviewscript.obj errors ? > > I am > > > > > not able > > > > > > > > to > > > > > > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Ciao, > > > > > > > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ciao, > > > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ciao, > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ciao, > > > > > > Ajinkya > > > > > > _______________________________________________ > > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > Ajinkya > > > > > > > > > > > > > > > > -- > > > Ciao, > > > Ajinkya > > > > > > > > > > > -- > Ciao, > Ajinkya > -- Ciao, Ajinkya From marinekelley at gmail.com Sun Apr 6 12:56:20 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Apr 6 12:56:24 2008 Subject: [sldev] lscript_compile error In-Reply-To: References: <9e52a8c10804060409ub0222a2td5486bd124b4405f@mail.gmail.com> <2e9f48970804061222u4f2396a5v719d03ab81123b76@mail.gmail.com> <2e9f48970804061233q23350ddax9eab24740cde6c0d@mail.gmail.com> Message-ID: <9e52a8c10804061256x49106423iba4f8865ccb64f87@mail.gmail.com> hi, in order to run the viewer as standalone (ie not from VC2005 but by clicking the executable itself) you need to copy : - app_settings folder - characters folder - fonts folder - skins folder - fmod.dll - featuretable.txt - gpu_table.txt in your ReleaseForDownload or ReleaseNoOpt folder and you're all set. Marine 2008/4/6, Ajinkya Kale : > > I did copy fmod.dll to the ReleaseNoOpt and ReleaseForDownload > directories . It gives me the following error message box : > > ERROR: LLAlertDialogue::parseAlerts:Problem reading UI Alerts file: > alerts.xml > > > On Sun, Apr 6, 2008 at 12:33 PM, Evan Wong wrote: > > fmod.dll was copied for me automatically into the newview\ReleaseNoOpt > > directory when I built it on Visual Studio with ReleaseNoOpt > configuration. > > If it didn't for you, try copying it into the newview\ReleaseNoOpt > > directory. > > > > Regards, > > Evan > > > > > > > > On Mon, Apr 7, 2008 at 3:30 AM, Ajinkya Kale > wrote: > > > Do I need the fmod.dll in the newview\ReleaseNoOpt or > > > newview\ReleaseForDownload Directories too ? > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 12:25 PM, Ajinkya Kale > > wrote: > > > > I have already copied fmod.dll to the newview directory. > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 12:22 PM, Evan Wong > wrote: > > > > > Hi Ajinkya, > > > > > > > > > > You probably need fmod copied to the directory. Refer to > > > > > > > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Fmod > > > > > > > > > > Regards, > > > > > Evan > > > > > > > > > > > > > > > > > > > > On Mon, Apr 7, 2008 at 3:13 AM, Ajinkya Kale < > kaleajinkya@gmail.com> > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Finally finally finally.....The viewer was built successfully > !! > > The > > > > > > "Converting files for MSVS2005" link ( > > > > > > > > https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > > > > > > ) helped. Phew !! > > > > > > > > > > > > But when I try to run the newview.exe it gives me an error > prompt : > > > > > > > > > > > > " This application has failed to start because fmod.dll was not > > found. > > > > > > Re-installing the application may fix this problem. " > > > > > > > > > > > > Any suggestions ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 5:02 AM, Ajinkya Kale > > > > > > > wrote: > > > > > > > I didnt understand which cache and relog are you talking of ? > Can > > you > > > > > > > clarify a bit more ? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 4:09 AM, Marine Kelley > > > > > > > wrote: > > > > > > > > Perhaps you have put C:\Cygwin\bin before the VC bin > > directory... > > > > > which > > > > > > > > means VC tries to link using the cygwin link.exe instead > of > > its own. > > > > > Try to > > > > > > > > change the order of the paths in your Path variable in VC. > > > > > > > > > > > > > > > > Hope this helps > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > Ok. So now what i did is I added C:\cygwin\bin to the > VC++ > > > > > > > > > Directories\Executable Files\ list. And I rebuilt the > > > > > > > > > lscript_compile and lscript_compile_fb_vc8 projects. > They > > were > > > > > built > > > > > > > > > successfully without any errors. > > > > > > > > > > > > > > > > > > But now when i try to Build newview I get the following > > error : > > > > > > > > > > > > > > > > > > > > > > > > > > > 1>------ Build started: Project: newview, Configuration: > > > > > > > > > ReleaseForDownload Win32 ------ > > > > > > > > > 1>Executing pre-build batch file > > > > > > > > > 1>PREBUILD SUCCESSFUL > > > > > > > > > 1>Linking... > > > > > > > > > > > > > > > > > > 1>link: extra operand `/ERRORREPORT:PROMPT' > > > > > > > > > 1>Try `link --help' for more information. > > > > > > > > > 1>Project : error PRJ0002 : Error result 1 returned from > > > > > > > > > 'C:\cygwin\bin\link.exe'. > > > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\newview\ReleaseForDownload\BuildLog.htm" > > > > > > > > > 1>newview - 1 error(s), 0 warning(s) > > > > > > > > > ========== Build: 0 succeeded, 1 failed, 21 up-to-date, > 0 > > skipped > > > > > > > > ========== > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:57 AM, Marine Kelley > > > > > > > > > > > > > wrote: > > > > > > > > > > It seems your bison.exe and mv.exe files are not in > any of > > the > > > > > paths > > > > > > > > you've > > > > > > > > > > provided to VC. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > When I try to recompile lscript_compile and > > > > > lscript_compile_fb_vc8 I > > > > > > > > > > > get the following errors : > > > > > > > > > > > > > > > > > > > > > > 1>------ Rebuild All started: Project: > > lscript_compile_fb_vc8, > > > > > > > > > > > Configuration: Release Win32 ------ > > > > > > > > > > > 1>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_compile_fb_vc8', configuration > 'Release|Win32' > > > > > > > > > > > 2>------ Rebuild All started: Project: > lscript_library, > > > > > Configuration: > > > > > > > > > > > Release Win32 ------ > > > > > > > > > > > 2>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_library', configuration 'Release|Win32' > > > > > > > > > > > 1>Building ytab.cpp > > > > > > > > > > > 2>Compiling... > > > > > > > > > > > 2>lscript_library.cpp > > > > > > > > > > > 1>'bison.exe' is not recognized as an internal or > > external > > > > > command, > > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > > 1>'mv.exe' is not recognized as an internal or > external > > > > > command, > > > > > > > > > > > 1>operable program or batch file. > > > > > > > > > > > 1>Project : error PRJ0019: A tool returned an error > code > > from > > > > > > > > > > > "Building ytab.cpp" > > > > > > > > > > > 2>lscript_export.cpp > > > > > > > > > > > 2>lscript_alloc.cpp > > > > > > > > > > > 2>Generating Code... > > > > > > > > > > > > > > > > > > > > > > 1>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release_fb\BuildLog.htm" > > > > > > > > > > > 1>lscript_compile_fb_vc8 - 1 error(s), 0 warning(s) > > > > > > > > > > > 2>Creating library... > > > > > > > > > > > > > > > > > > > > > > 2>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_library\Release\BuildLog.htm" > > > > > > > > > > > 2>lscript_library - 0 error(s), 0 warning(s) > > > > > > > > > > > 3>------ Rebuild All started: Project: > lscript_compile, > > > > > Configuration: > > > > > > > > > > > Release Win32 ------ > > > > > > > > > > > 3>Deleting intermediate and output files for project > > > > > > > > > > > 'lscript_compile', configuration 'Release|Win32' > > > > > > > > > > > 3>Compiling... > > > > > > > > > > > 3>lscript_typecheck.cpp > > > > > > > > > > > 3>lscript_tree.cpp > > > > > > > > > > > 3>lscript_scope.cpp > > > > > > > > > > > 3>lscript_resource.cpp > > > > > > > > > > > 3>lscript_heap.cpp > > > > > > > > > > > 3>lscript_error.cpp > > > > > > > > > > > 3>lscript_bytecode.cpp > > > > > > > > > > > 3>lscript_alloc.cpp > > > > > > > > > > > 3>Generating Code... > > > > > > > > > > > 3>Creating library... > > > > > > > > > > > > > > > > > > > > > > 3>Build log was saved at "file://h:\SL Open source > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > codes\slviewer-src-Branch_1-19-0-Viewer-r80803\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" > > > > > > > > > > > 3>lscript_compile - 0 error(s), 0 warning(s) > > > > > > > > > > > ========== Rebuild All: 2 succeeded, 1 failed, 0 > skipped > > > > > ========== > > > > > > > > > > > > > > > > > > > > > > I have also separated the commanline in the > properties > > of > > > > > indra.y. > > > > > > > > > > > Still no success :( > > > > > > > > > > > > > > > > > > > > > > Waiting for your suggestions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Apr 6, 2008 at 3:25 AM, Marine Kelley > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi, I'm not sure but when I get link error from > obj > > files I > > > > > am sure > > > > > > > > I > > > > > > > > > > have > > > > > > > > > > > > already compile, I rebuild the projects they are > > issued from > > > > > (or at > > > > > > > > > > least I > > > > > > > > > > > > recompile their cpp files). Most of the time it is > due > > to a > > > > > VC > > > > > > > > problem, > > > > > > > > > > > > corrupting obj files. > > > > > > > > > > > > > > > > > > > > > > > > Marine > > > > > > > > > > > > > > > > > > > > > > > > 2008/4/6, Ajinkya Kale : > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > Can anyone please suggest me any work around for > the > > > > > > > > > > > > > llcompilequeue.obj and llpreviewscript.obj > errors ? > > I am > > > > > not able > > > > > > > > to > > > > > > > > > > > > > compile the viewer due to these errors. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Ciao, > > > > > > > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Ciao, > > > > > > > > > > > > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Ciao, > > > > > > > Ajinkya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Ciao, > > > > > > Ajinkya > > > > > > _______________________________________________ > > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Ciao, > > > > Ajinkya > > > > > > > > > > > > > > > > -- > > > Ciao, > > > Ajinkya > > > > > > > > > > > -- > Ciao, > Ajinkya > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080406/7c8cec93/attachment-0001.htm From kfa at gmx.net Sun Apr 6 15:46:34 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 6 15:46:41 2008 Subject: [sldev] 1.19.1.4 RC - Debug Build Message-ID: <47F952CA.5070007@gmx.net> Back to square one, I can't seem to get the Debug configuration to build. Whatever I try, the furthest I can reduce the number of errors is down to 1 as follows (in the newview project): LINK : fatal error LNK1104: cannot open file 'llmozlib-vc80.lib' Don't think I haven't checked every setting I could find that would provide include or library directories. Still, must have overlooked something. The wiki page about finding leaks with the special debug build instructions appears to be out of date. The patch given there doesn't work since the source has moved on too far, some of the files to patch don't exist anymore. And by now it should be possible to have llmozlib included there too, not? Before anyone bothers with details, who has done a successful debug build and could provide a set of solution/project files? I should be able to do a diff and figure it out. TIA, Felix From lenglish5 at cox.net Sun Apr 6 15:59:44 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Apr 6 15:59:47 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F6C53E.4070805@cox.net> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> <47F6C3B9.1000405@lindenlab.com> <47F6C53E.4070805@cox.net> Message-ID: <47F955E0.5030204@cox.net> Lawson English wrote: > Thanks Rob. I've been asking around and no-one else seems to notice a > definite change between RC and R, so I suspect Dahlia's correct: the > two are probably using different settings files. If I can't get rid of > it by fiddling with preferences, I'll definitely file it since its > annoying. I can "moonwalk" for up to 10-15 seconds in some sims and > suddenly jump ahead the distance I should have walked during that time > when using the release viewer, and walk normally in the same sim in > the same spot with the RC. > I deleted everything that looked like it had anything to do with being a preferences file and the problem went away. I'm a noob again though... Lawson From ts_ryuzo at hotmail.com Sun Apr 6 22:30:49 2008 From: ts_ryuzo at hotmail.com (Qian Hao ~) Date: Sun Apr 6 22:30:51 2008 Subject: [sldev] Requesting for texture Message-ID: I am currently studying the part on requesting for texture. Does the viewer only request for texture image that are in the viewing angle or does it request for every primitives in the island? Is the occlusion done before request for texture? I was looking through the lltexturefetch.cpp and I was wondering what is decodePriority? Does the client program use this to sort what texture image to request from the server first? Thank you, Qian Hao -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/102cf947/attachment.htm From bboomslang at googlemail.com Mon Apr 7 05:03:08 2008 From: bboomslang at googlemail.com (Barney Boomslang) Date: Mon Apr 7 05:03:12 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: Message-ID: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> > Can I make a plea that Dazzle does not go live (even in RC) until it supports different colour themes and that it comes with a "slate" scheme as well as the blue scheme? Now come on, that would be like asking them to release Windlight only when they actually don't store the f'ing windlight settings inside the application tree where they are eradicated with _every_ version upgrade. Next thing you ask is they actually _read_ the silly jira bug reports we make about that stuff. Or actually taking reports with several hundred votes on them and a proven-working patch attached to it and applying it to the release. I mean, come on, that would make _sense_! Really. *shakes head* - what's next, asking them to release the source that actually builds the clients they release around the same time they release the actual client? Don't be silly. bye, Barney (what, snarky? me? neva ...) From gigstaggart at gmail.com Mon Apr 7 06:34:24 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Apr 7 06:34:37 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> Message-ID: <47FA22E0.4050204@gmail.com> Barney Boomslang wrote: >> Can I make a plea that Dazzle does not go live (even in RC) until it suppor > > Now come on, that would be like asking them to release Windlight only > when they actually don't store the f'ing windlight settings inside the > application tree where they are eradicated with _every_ version Interesting. I wonder if this is why Secondlife can't run with Windows Vista with UAC enabled. From matthew.dowd at hotmail.co.uk Mon Apr 7 06:43:25 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 06:43:27 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <47FA22E0.4050204@gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA22E0.4050204@gmail.com> Message-ID: Mmmm, I'm running SL under Vista with UAC enabled! Matthew _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live From olli_aro at yahoo.co.uk Mon Apr 7 06:42:51 2008 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Mon Apr 7 06:45:17 2008 Subject: [sldev] Plotting Data on SLURL Message-ID: Hi all, Hope this is the right forum for my question. I did read through the descriptions for all lists available and this seemed like to closest one for my query. Anyway, I am interested to plot some additional data on the map generated from SLURL and was wondering if anyone knows if this is possible and legal without offending the owners of slurl.com? I had a quick look into this and since it uses Google Maps API it seems like it should be quite easy to add additional data on the map. The only thing that I could not work out was the initial X and Y, but I assume that this is what SLURL application works out at server side based on the given slurl? So, my question really is (in addition to if it is ok to use the great work done by SLURL people like this), how to work out X and Y coordinates based on the SLURL? Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/babaa2e8/attachment.htm From matthew.dowd at hotmail.co.uk Mon Apr 7 06:46:46 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 06:46:48 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> Message-ID: Since installing 1.19.1 release, Windows Vista keeps popping up a message when I'm running SL warning me that I am running low and memory, and suggesting I close SL. I've not seen this before in previous Windlight or RC versions. I'm running with 2GB RAM (and a 4GB swap), before anyone asks. Is there a pretty big memory leak in this version? Matthew _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live From aimee at ama-zing.co.uk Mon Apr 7 06:57:07 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Apr 7 06:57:14 2008 Subject: Dazzle (Was Re: [sldev] 1.19.1 release source) In-Reply-To: References: Message-ID: <8D426FE7-919F-46CE-9503-292413600DFE@ama-zing.co.uk> https://jira.secondlife.com/browse/VWR-5059 (Dazzle: Ability to switch between new/old theme from within SL) would probably be a good place to file it maybe. For a comprehensive analysis of why it's essential Dazzle doesn't go live, without at least providing a dark skin as well, see my comments on https://jira.secondlife.com/browse/VWR-5080 (Dazzle: certain color combinations hard on visually impaired), it's completely unusable as it stands for many people. Aimee. On Apr 5, 2008, at 19:49, Soft wrote: > On Sat, Apr 5, 2008 at 1:36 PM, Matthew Dowd > wrote: >> >> There was a suitable "slate" scheme for the Dazzle firstlook >> posted in the forums. > > Could you provide a link on that, or encourage the poster to file it > as a JIRA patch to clear licensing concerns? From robin.cornelius at gmail.com Mon Apr 7 06:59:36 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 06:59:43 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <47FA22E0.4050204@gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA22E0.4050204@gmail.com> Message-ID: On Mon, Apr 7, 2008 at 2:34 PM, Jason Giglio wrote: > Barney Boomslang wrote: > >> Can I make a plea that Dazzle does not go live (even in RC) until it suppor > > > > > Now come on, that would be like asking them to release Windlight only > > when they actually don't store the f'ing windlight settings inside the > > application tree where they are eradicated with _every_ version > > Interesting. I wonder if this is why Secondlife can't run with Windows > Vista with UAC enabled. > There is a fault somewhere in the VFS which is causing a setting to be written to "program files" instead of the users home directory. I started chasing this with someone in irc the other day but not having a windows build platform made it kind of difficult :-) Robin From robin.cornelius at gmail.com Mon Apr 7 07:06:50 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 07:06:57 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> Message-ID: On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote: > > Since installing 1.19.1 release, Windows Vista keeps popping up a message when I'm running SL warning me that I am running low and memory, and suggesting I close SL. I've not seen this before in previous Windlight or RC versions. I'm running with 2GB RAM (and a 4GB swap), before anyone asks. > > Is there a pretty big memory leak in this version? Well i have seen some interesting memory usage over the whole RC series tried to valgrid but not identified anything major. But i have had swap storms again and on linux i usually use a ulimit to prevent it from stealing too much memory. But this is up and down a lot. BTW are you someone who moves the camera a lot? i have seen it suggested that moving the camera us causing a leak? It would be really cool if we could feature freeze for a little while and chase some bugs out of the system to get things really stable before adding more new things. Regards Robin From sldev at free.fr Mon Apr 7 07:51:04 2008 From: sldev at free.fr (Henri Beauchamp) Date: Mon Apr 7 07:51:09 2008 Subject: Feature freeze (was: Re: [sldev] Major memory leak with 1.19.1 release) In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> Message-ID: <20080407165104.214aaf54.sldev@free.fr> On Mon, 7 Apr 2008 15:06:50 +0100, Robin Cornelius wrote: > On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote: > > .../... > > It would be really cool if we could feature freeze for a little while > and chase some bugs out of the system to get things really stable > before adding more new things. Hear, hear !!! I can only second it ! Yes, pretty please, DO feature freeze SL and DO hunt down every known bug before resuming the development of new features. And for one, I won't mind if the "little while" was counted in months, as long as it means stable, bugless viewer and server in the end ! Henri. From kfa at gmx.net Mon Apr 7 06:28:14 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Mon Apr 7 07:56:03 2008 Subject: [sldev] 1.19.1.4 RC - Debug Build In-Reply-To: <47F952CA.5070007@gmx.net> References: <47F952CA.5070007@gmx.net> Message-ID: <47FA216E.40201@gmx.net> After another complete sweep and fresh rebuild, it now looks like this: 1>Linking... 1>llimage.lib(llimagej2c.obj) : error LNK2019: unresolved external symbol "char const * __cdecl fallbackEngineInfoLLImageJ2CImpl(void)" (?fallbackEngineInfoLLImageJ2CImpl@@YAPBDXZ) referenced in function "public: static class std::basic_string,class std::allocator > __cdecl LLImageJ2C::getEngineInfo(void)" (?getEngineInfo@LLImageJ2C@@SA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) 1>llimage.lib(llimagej2c.obj) : error LNK2019: unresolved external symbol "class LLImageJ2CImpl * __cdecl fallbackCreateLLImageJ2CImpl(void)" (?fallbackCreateLLImageJ2CImpl@@YAPAVLLImageJ2CImpl@@XZ) referenced in function "public: __thiscall LLImageJ2C::LLImageJ2C(void)" (??0LLImageJ2C@@QAE@XZ) 1>llimage.lib(llimagej2c.obj) : error LNK2019: unresolved external symbol "void __cdecl fallbackDestroyLLImageJ2CImpl(class LLImageJ2CImpl *)" (?fallbackDestroyLLImageJ2CImpl@@YAXPAVLLImageJ2CImpl@@@Z) referenced in function "protected: virtual __thiscall LLImageJ2C::~LLImageJ2C(void)" (??1LLImageJ2C@@MAE@XZ) 1>Debug/debugview.exe : fatal error LNK1120: 3 unresolved externals 1>Build log was saved at "file://c:\SL\1.19.1.4\workspace2\linden\indra\newview\Debug\BuildLog.htm" 1>newview - 4 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 21 up-to-date, 0 skipped ========== Tons of similar messages on this list, and getting a bit tired of fruitlessly searching them for a previously offered solution, I am asking: *Is there no permanent fix for the build nightmare?* Being a noob in compiling under Windows, but not in programming, I dun wanna hassle with this, just dive into the code. Or is this asking for something that's not possible, or at least difficult? This is meant as a serious question (not whining). Thanks, Felix Felix Duesenburg wrote: > Back to square one, I can't seem to get the Debug configuration to > build. Whatever I try, the furthest I can reduce the number of errors > is down to 1 as follows (in the newview project): > > LINK : fatal error LNK1104: cannot open file 'llmozlib-vc80.lib' > > Don't think I haven't checked every setting I could find that would > provide include or library directories. Still, must have overlooked > something. The wiki page about finding leaks with the special debug > build instructions appears to be out of date. The patch given there > doesn't work since the source has moved on too far, some of the files > to patch don't exist anymore. And by now it should be possible to have > llmozlib included there too, not? > > Before anyone bothers with details, who has done a successful debug > build and could provide a set of solution/project files? I should be > able to do a diff and figure it out. > > TIA, > Felix > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robin.cornelius at gmail.com Mon Apr 7 08:05:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 08:05:05 2008 Subject: [sldev] 1.19.1.4 RC - Debug Build In-Reply-To: <47FA216E.40201@gmx.net> References: <47F952CA.5070007@gmx.net> <47FA216E.40201@gmx.net> Message-ID: On Mon, Apr 7, 2008 at 2:28 PM, Felix Duesenburg wrote: > Tons of similar messages on this list, and getting a bit tired of > fruitlessly searching them for a previously offered solution, I am asking: > *Is there no permanent fix for the build nightmare?* CMAKE is the answer to this nightmare. I know i just requested a feature freeze in another mail but i see cmake as a *major* bug fix to the build process not a feature :-) cmake *should* be capable of generating correct build files for the 3 supported platforms (VS project files, xcode project files and unix makefiles) and as they all share a common base things should not get out of sequence. PS: Any idea on the release schedule for cmake? Robin From tom at streamsense.net Mon Apr 7 08:37:53 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Apr 7 08:38:27 2008 Subject: [sldev] llSetTextureAnimation - Texture Animation adding abnormal load to sim latency In-Reply-To: References: <47F952CA.5070007@gmx.net> <47FA216E.40201@gmx.net> Message-ID: <47FA3FD1.5040501@streamsense.net> Was wondering if anyone has experienced this, or can shed any light on it: http://jira.secondlife.com/browse/SVC-2061 I noticed it on my sim a few days ago but as of yet doesn't appear to have seen much attention, i'm wondering if it's a few isolated cases. ~Tom From monkowsk at watson.ibm.com Mon Apr 7 08:47:15 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Apr 7 08:47:25 2008 Subject: [sldev] 100% repro issue with release 1.19.1(4) In-Reply-To: <47F955E0.5030204@cox.net> References: <47F6903B.70305@cox.net> <47F6A0B3.4@watson.ibm.com> <47F6A509.1030001@cox.net> <47F6C3B9.1000405@lindenlab.com> <47F6C53E.4070805@cox.net> <47F955E0.5030204@cox.net> Message-ID: <47FA4203.90107@watson.ibm.com> For future reference, the settings file is specified on the command line (Shortcut Target on MS Windows). It would be nice to know what caused the problem, though. One more thing to look at when I get a chance. :-) Mike Lawson English wrote: > Lawson English wrote: > >> Thanks Rob. I've been asking around and no-one else seems to notice a >> definite change between RC and R, so I suspect Dahlia's correct: the >> two are probably using different settings files. If I can't get rid of >> it by fiddling with preferences, I'll definitely file it since its >> annoying. I can "moonwalk" for up to 10-15 seconds in some sims and >> suddenly jump ahead the distance I should have walked during that time >> when using the release viewer, and walk normally in the same sim in >> the same spot with the RC. >> > > I deleted everything that looked like it had anything to do with being a > preferences file and the problem went away. I'm a noob again though... From monkowsk at watson.ibm.com Mon Apr 7 08:50:39 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Apr 7 08:50:52 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> Message-ID: <47FA42CF.2060801@watson.ibm.com> There are leaks, but try this: From VWR-364 > [EDIT by Nicholaz Beresford] Some of the memory usage may be by design (texture buffer based on video ram setting ... up to 700-800 MB on the system the user above reports), see https://jira.secondlife.com/browse/VWR-733 . A resolution to this part of the problem is to set video ram (preferences, adv. graphics) to a lower value (128 MB) Mike Matthew Dowd wrote: > Since installing 1.19.1 release, Windows Vista keeps popping up a message when I'm running SL warning me that I am running low and memory, and suggesting I close SL. I've not seen this before in previous Windlight or RC versions. I'm running with 2GB RAM (and a 4GB swap), before anyone asks. > > Is there a pretty big memory leak in this version? From robin.cornelius at gmail.com Mon Apr 7 08:54:16 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 08:54:22 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: <47FA42CF.2060801@watson.ibm.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> Message-ID: On Mon, Apr 7, 2008 at 4:50 PM, Mike Monkowski wrote: > There are leaks, but try this: > > From VWR-364 > > > [EDIT by Nicholaz Beresford] Some of the memory usage may be by design > (texture buffer based on video ram setting ... up to 700-800 MB on the > system the user above reports), see > https://jira.secondlife.com/browse/VWR-733 . A resolution to this part of > the problem is to set video ram (preferences, adv. graphics) to a lower > value (128 MB) > > Yes, Setting this too high can lead to swap storming for sure (if you run out of ram, 700MB for textures is quite a lot), so it is worth setting low for memory leak fighting. Robin From monkowsk at watson.ibm.com Mon Apr 7 08:54:34 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Apr 7 08:54:39 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA22E0.4050204@gmail.com> Message-ID: <47FA43BA.2000306@watson.ibm.com> Robin Cornelius wrote: > There is a fault somewhere in the VFS which is causing a setting to be > written to "program files" instead of the users home directory. I > started chasing this with someone in irc the other day but not having > a windows build platform made it kind of difficult :-) Robin, is there a JIRA on this? If not, what are the details? Mike From xotmid at gmail.com Mon Apr 7 09:01:50 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Apr 7 09:01:55 2008 Subject: [sldev] Estate Windlight Settings? Message-ID: hey all, Any word on when we will see estate control of windlight? Dimentox -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/8e68326d/attachment.htm From GordonWendt at gmail.com Mon Apr 7 09:06:56 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Apr 7 09:07:02 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: Message-ID: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> What do you mean by estate control of windlight? other than default sun position which is already estate controlled I believe everything else is client side unless I am mistaken in which case please tell me. -Gordon Wendt. On Mon, Apr 7, 2008 at 12:01 PM, Brandon Husbands wrote: > hey all, > > Any word on when we will see estate control of windlight? > > Dimentox > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/14d11581/attachment.htm From matthew.dowd at hotmail.co.uk Mon Apr 7 09:33:15 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 09:33:17 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> Message-ID: Mmmm, I changed the graphics setting - now I get a smartheap error after about 5 minutes rather than a vista one. Matthew _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live From soft at lindenlab.com Mon Apr 7 09:59:08 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 7 09:59:10 2008 Subject: [sldev] 1.19.1 build issues - big main thread Message-ID: There are a number of threads about 1.19.1 build issues. Please help me consolidate the problems into one place by replying to this thread only with build issues. I built Mac and Linux this morning and ran both without problems. Speak up if you're seeing something different. Windows is another story. That's crashing on startup in llkdu.dll. If you run with openjpeg (delete indra/newview/ReleaseNoOpt/llkdu.dll) it's fine. I'm poking about to see who owns changes related to this. Again, please comment if you're seeing something different. One thing that seems to be catching up a lot of Windows users: Be sure you add your cygin bin directory to the end of your build tool paths in Visual Studio. There are no longer hard-coded references to C:\cygwin\bin -- look at Tools->Options->Projects->VC++ Directories->"Show directoreis for" Executable files and put C:\cygwin\bin or local equivalent at the end. From matthew.dowd at hotmail.co.uk Mon Apr 7 10:04:24 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 10:04:26 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> Message-ID: My understanding is that the plan was when you entered a sim, the client would download a set of default settings and configure itself from that. An estate owner can upload that default set. Matthew _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live From robin.cornelius at gmail.com Mon Apr 7 10:08:23 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 10:08:29 2008 Subject: [sldev] 1.19.1 release source In-Reply-To: <47FA43BA.2000306@watson.ibm.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA22E0.4050204@gmail.com> <47FA43BA.2000306@watson.ibm.com> Message-ID: <47FA5507.5070509@gmail.com> Mike Monkowski wrote: > Robin Cornelius wrote: >> There is a fault somewhere in the VFS which is causing a setting to be >> written to "program files" instead of the users home directory. I >> started chasing this with someone in irc the other day but not having >> a windows build platform made it kind of difficult :-) > > Robin, is there a JIRA on this? If not, what are the details? I'm not sure, I certainly have not opened one as I have not get any repro or found the issue myself. Now this may have been fixed or been just a specific version of the last RC, as i saw a comment earlier from some one running with vista and UAC so maybe this is dead and gone now? If anyone can repro I would be happy to talk to them. Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080407/9f9d2687/signature.pgp From soft at lindenlab.com Mon Apr 7 10:11:39 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 7 10:11:42 2008 Subject: [sldev] Re: 1.19.1 build issues - big main thread In-Reply-To: References: Message-ID: On Mon, Apr 7, 2008 at 11:59 AM, Soft wrote: > There are a number of threads about 1.19.1 build issues. Please help > me consolidate the problems into one place by replying to this thread > only with build issues. > > I built Mac and Linux this morning and ran both without problems. > Speak up if you're seeing something different. > > Windows is another story. That's crashing on startup in llkdu.dll. If > you run with openjpeg (delete indra/newview/ReleaseNoOpt/llkdu.dll) > it's fine. I'm poking about to see who owns changes related to this. > Again, please comment if you're seeing something different. Someone updated llkdu without checking in updated DLLs. I'm pushing an update in the next ten minutes or so. I verified that Windows builds and runs properly with this change as well. This should mean all three platforms are working from source. From robin.cornelius at gmail.com Mon Apr 7 10:13:07 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 10:13:16 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> Message-ID: <47FA5623.70404@gmail.com> Matthew Dowd wrote: > My understanding is that the plan was when you entered a sim, the client would download a set of default settings and configure itself from that. An estate owner can upload that default set. Yes, any viewer that has "region defaults" set would see the version that the estate owner set. What would be even better if there were lsl calls to do this. There are a number of "weather machines" so these would benefit from being able to set the region windlight controls (with appropriate permissions etc). Well that's what i would like anyway :-) Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080407/cb82828f/signature.pgp From matthew.dowd at hotmail.co.uk Mon Apr 7 10:18:25 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 10:18:26 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <47FA5623.70404@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> Message-ID: Mmmm, perhaps a staged approach - region control windlight first; then the implementation of LSL functions for managing estate functions (there are plenty of other estate settings it would be useful to control via scripting). Should this be before or after the proposed feature freeze to fix bugs? Matthew _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx From monkowsk at watson.ibm.com Mon Apr 7 10:26:10 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Apr 7 10:26:18 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> Message-ID: <47FA5932.3080401@watson.ibm.com> Matthew Dowd wrote: > Mmmm, I changed the graphics setting - now I get a smartheap error after about 5 minutes rather than a vista one. So....what's a smartheap error? How much memory is SL actually using now? Mike From xotmid at gmail.com Mon Apr 7 10:29:40 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Apr 7 10:29:45 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> Message-ID: Can we upload the settings? Ive changed the Regions settings but it does not do jack except for the sun. On Mon, Apr 7, 2008 at 12:18 PM, Matthew Dowd wrote: > > Mmmm, perhaps a staged approach - region control windlight first; then the > implementation of LSL functions for managing estate functions (there are > plenty of other estate settings it would be useful to control via > scripting). > > Should this be before or after the proposed feature freeze to fix bugs? > > Matthew > _________________________________________________________________ > Get Hotmail on your mobile. Text MSN to 63463 now! > > http://mobile.uk.msn.com/pc/mail.aspx_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/1e8b1904/attachment.htm From robin.cornelius at gmail.com Mon Apr 7 10:32:45 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 7 10:32:53 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> Message-ID: <47FA5ABD.6040906@gmail.com> Brandon Husbands wrote: > Can we upload the settings? > Ive changed the Regions settings but it does not do jack except for the sun. This depends on your GPU class and the options you've got set for graphics quality. If your GPU's upto it and you have everything on the settings produce *dramatic* effects to the sky and linden water. You can't miss them if they are happening :-) If your GPU's older or settings are down then the effects are very little pretty much as you describe. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080407/db05987c/signature.pgp From gigstaggart at gmail.com Mon Apr 7 10:35:23 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Apr 7 10:35:35 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> Message-ID: <47FA5B5B.904@gmail.com> Matthew Dowd wrote: > Mmmm, I changed the graphics setting - now I get a smartheap error after about 5 minutes rather than a vista one. > I think it's just smartheap fucking up, not that you are actually running out of memory. There's a huge jira on this subject. Just compile without smartheap enabled. -Jason From xotmid at gmail.com Mon Apr 7 10:48:30 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Apr 7 10:48:34 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <47FA5ABD.6040906@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <47FA5ABD.6040906@gmail.com> Message-ID: What i mean is As an estate manager Me changing settings besides the old sun dont do anything.. I am more curious from the server side when this will be done. On Mon, Apr 7, 2008 at 12:32 PM, Robin Cornelius wrote: > Brandon Husbands wrote: > > Can we upload the settings? > > Ive changed the Regions settings but it does not do jack except for the > sun. > > This depends on your GPU class and the options you've got set for > graphics quality. If your GPU's upto it and you have everything on the > settings produce *dramatic* effects to the sky and linden water. You > can't miss them if they are happening :-) > > If your GPU's older or settings are down then the effects are very > little pretty much as you describe. > > Robin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/e010e877/attachment.htm From secret.argent at gmail.com Mon Apr 7 10:56:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 7 10:56:57 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <47FA5623.70404@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> Message-ID: <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> On 2008-04-07, at 12:13, Robin Cornelius wrote: > Matthew Dowd wrote: >> My understanding is that the plan was when you entered a sim, the >> client would download a set of default settings and configure >> itself from that. An estate owner can upload that default set. > > Yes, any viewer that has "region defaults" set would see the version > that the estate owner set. This makes it even more important to bring back "nighttime gamma" (and a corresponding "daytime gamma", and possibly other overrides), because people need to be able to adjust the overall brightness of the world to match their monitor, eyes, and real world environment. No, changing the overall monitor gamma doesn't cut it, if I turn my monitor gamma up enough to compensate for the current night-time brightness everything else is washed out. Without overriding gamma adjustments it may simply become impossible for me to EVER turn on "region defaults". From xotmid at gmail.com Mon Apr 7 11:13:35 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Apr 7 11:13:39 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> Message-ID: So let me get this straight.. I go to my region where i am an estate manager.. I play with my preference settings and do all the groovy effects.. and that will set the sim? One would thing it would be in the sim settings.. If its there then all we have is SUN CONTROL Which leads me to my previous question how or when do we set the effects. On Mon, Apr 7, 2008 at 12:56 PM, Argent Stonecutter wrote: > On 2008-04-07, at 12:13, Robin Cornelius wrote: > > > Matthew Dowd wrote: > > > > > My understanding is that the plan was when you entered a sim, the > > > client would download a set of default settings and configure itself from > > > that. An estate owner can upload that default set. > > > > > > > > Yes, any viewer that has "region defaults" set would see the version > > that the estate owner set. > > > > This makes it even more important to bring back "nighttime gamma" (and a > corresponding "daytime gamma", and possibly other overrides), because people > need to be able to adjust the overall brightness of the world to match their > monitor, eyes, and real world environment. No, changing the overall monitor > gamma doesn't cut it, if I turn my monitor gamma up enough to compensate for > the current night-time brightness everything else is washed out. > > Without overriding gamma adjustments it may simply become impossible for > me to EVER turn on "region defaults". > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/d30cd752/attachment.htm From yoz at lindenlab.com Mon Apr 7 11:20:22 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Mon Apr 7 11:20:32 2008 Subject: [sldev] Plotting Data on SLURL In-Reply-To: References: Message-ID: <84156973-5AEC-4C09-928B-1216DA1711EF@lindenlab.com> On Apr 7, 2008, at 6:42 AM, Olli Aro wrote: > Hi all, > > Hope this is the right forum for my question. I did read through the > descriptions for all lists available and this seemed like to closest > one for my query? > > Anyway, I am interested to plot some additional data on the map > generated from SLURL and was wondering if anyone knows if this is > possible and legal without offending the owners of slurl.com? Hi Olli, Yes, it's completely fine. Go crazy with it! There's documentation here: http://wiki.secondlife.com/wiki/MapAPI (thanks to Thraxis Epsilon for that!) > I had a quick look into this and since it uses Google Maps API it > seems like it should be quite easy to add additional data on the > map. The only thing that I could not work out was the initial X and > Y, but I assume that this is what SLURL application works out at > server side based on the given slurl? So, my question really is (in > addition to if it is ok to use the great work done by SLURL people > like this), how to work out X and Y coordinates based on the SLURL? There are now JSON web services for getting the X & Y coords for a given region, and vice versa. If you take a look at the function SLMap.gotoRegion() (line 750 in slmapapi.js) you'll see code that calls the former, and gotoSLURL() (line 1368) for the latter. Good luck, and let me know how you get on! -- Yoz Linden From bos at lindenlab.com Mon Apr 7 11:26:04 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Apr 7 11:26:07 2008 Subject: [sldev] CMake status [was Re: 1.19.1.4 RC - Debug Build] In-Reply-To: References: <47F952CA.5070007@gmx.net> <47FA216E.40201@gmx.net> Message-ID: <47FA673C.5090408@lindenlab.com> Robin Cornelius wrote: > I know i just requested a feature freeze in another mail but i see > cmake as a *major* bug fix to the build process not a feature :-) Yes, that's the intention. > cmake *should* be capable of generating correct build files for the 3 > supported platforms (VS project files, xcode project files and unix > makefiles) and as they all share a common base things should not get > out of sequence. The version of CMake we're currently using (2.4.8) supports Visual Studio 2003 and 2005, which have substantially different project file formats, and also nmake, if you like pretending you're still using DOS. We've internally used both VS2003 and VS2005. On OS X, it supports both XCode and GNU Make. I've built our code with both, with no problems. And on Linux, it supports both GNU Make and KDevelop. Again, I've used both to build the code. We haven't tried VS2008 yet, but that's the only base not covered so far. > PS: Any idea on the release schedule for cmake? I'm currently finishing off the merge of the Havok4 code base. Once it passes our regular QA processes on both the viewer and server sides, we'll be folding it into our release (aka "trunk") branch. It's already been through one round of server-side QA with a few minor glitches, and I use the CMake-built viewer as my default viewer now. As for an actual date, think end of the month or so. If you want to feed me any more patches so that they're in right from the beginning, now's the time. References: <84156973-5AEC-4C09-928B-1216DA1711EF@lindenlab.com> Message-ID: [[ Forgot to send to list ]] Is there any further word on updates to the mapAPI system? As of right now not all regions can be displayed, nor are the tile sets exactly the freshest the further you zoom out. I have my own API wrapper made for OpenLayers ( http://www.openlayers.org ), using my custom TML service that uses the SL backend (with some small issues). The wrapper is fairly complete, but I haven't continued work as I don't know what direction LL will be going with the mapAPI system. You can view a demo of the wrapper at: http://www.mysldev.com/OpenLayer/oslurl.html The Region Names are a virtual TML service that generates an image dynamically for the region name. On Mon, Apr 7, 2008 at 11:20 AM, Yoz Grahame wrote: > > Hi Olli, > > Yes, it's completely fine. Go crazy with it! > There's documentation here: http://wiki.secondlife.com/wiki/MapAPI (thanks > to Thraxis Epsilon for that!) From secret.argent at gmail.com Mon Apr 7 11:49:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 7 11:50:12 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> Message-ID: <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> On 2008-04-07, at 13:13, Brandon Husbands wrote: > So let me get this straight.. > I go to my region where i am an estate manager.. I play with my > preference settings and do all the groovy effects.. and that will > set the sim? There will be some new interface that doesn't exist yet that will allow yo to upload Windlight presets to the sim. From monkowsk at watson.ibm.com Mon Apr 7 12:01:32 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Apr 7 12:01:37 2008 Subject: [sldev] CMake status [was Re: 1.19.1.4 RC - Debug Build] In-Reply-To: <47FA673C.5090408@lindenlab.com> References: <47F952CA.5070007@gmx.net> <47FA216E.40201@gmx.net> <47FA673C.5090408@lindenlab.com> Message-ID: <47FA6F8C.6040706@watson.ibm.com> Bryan O'Sullivan wrote: > The version of CMake we're currently using (2.4.8) supports Visual > Studio 2003 and 2005, which have substantially different project file > formats, and also nmake, if you like pretending you're still using DOS. > We've internally used both VS2003 and VS2005. Do you test the debug builds too? Mike From xotmid at gmail.com Mon Apr 7 12:28:45 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Apr 7 12:28:50 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> Message-ID: I dont suppose a linden can answer if we can send them a file or how long it will be untill we get the option. On Mon, Apr 7, 2008 at 1:49 PM, Argent Stonecutter wrote: > On 2008-04-07, at 13:13, Brandon Husbands wrote: > > > So let me get this straight.. > > I go to my region where i am an estate manager.. I play with my > > preference settings and do all the groovy effects.. and that will set the > > sim? > > > > There will be some new interface that doesn't exist yet that will allow yo > to upload Windlight presets to the sim. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080407/1bafffd6/attachment.htm From kfa at gmx.net Mon Apr 7 13:00:30 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Mon Apr 7 13:00:38 2008 Subject: [sldev] CMake status [was Re: 1.19.1.4 RC - Debug Build] In-Reply-To: References: <47F952CA.5070007@gmx.net> <47FA216E.40201@gmx.net> Message-ID: <47FA7D5E.9080603@gmx.net> WTG!! Guess it would help to chip in a few more votes for VWR-2871. However, opinions don't seem to be unanimous there. I'm for everything that makes life easier for as many people as possible. It may take a better overview than I have to make that assessment. Felix Robin Cornelius wrote: > CMAKE is the answer to this nightmare. > > I know i just requested a feature freeze in another mail but i see > cmake as a *major* bug fix to the build process not a feature :-) > > cmake *should* be capable of generating correct build files for the 3 > supported platforms (VS project files, xcode project files and unix > makefiles) and as they all share a common base things should not get > out of sequence. > > PS: Any idea on the release schedule for cmake? > > Robin > > From soft at lindenlab.com Mon Apr 7 13:35:11 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 7 13:35:16 2008 Subject: [sldev] Handling open source translations Message-ID: I'm curious - how do other projects handle volunteer-submitted translations? As I understand it, these come with a few liabilities that need to be resolved: * They could be loaded down with obscenities or rudeness. If none of us speak, say, Latvian, we'd never know the harm of telling someone to "go pick mushrooms" (a death threat) even if we use machine translation to verify translations back to English. How do we prevent that? * They could contain misleading translations. A fraudster could have a field day by reversing LSL debit permission payment accept/reject buttons and singling out users in that language community. How do we protect users? We can't simply say the translation is "unsupported." Not only would we leave people open to harm this way, but we'd create inventive for submitting these types of translations. * Open source developers don't deliver on a schedule. We can pay for 1-day turn around from contractors where a language has many users. But when we get to languages with only a few hundred users, it's tough to make a case for commercial translation services to do the updates. We can't hold back shipping while we wait for every last language to be brought to parity by volunteers. How do we make contributions timely, or how do we eliminate the need for timely translations? It would be great if we were taking in the new translations that are often offered. But the initial translation work is only a small fraction of the overall resources that language support consumes. How do we make user-submitted translations work? How do other projects handle these problems? From matthew.dowd at hotmail.co.uk Mon Apr 7 13:41:05 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 7 13:41:07 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: <47FA5B5B.904@gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> <47FA5B5B.904@gmail.com> Message-ID: >I think it's just smartheap fucking up, not that you are actually >running out of memory. There's a huge jira on this subject. > >Just compile without smartheap enabled. I can do that - but this problem is with the Linden compiled release viewer too... Matthew _________________________________________________________________ Win 100?s of Virgin Experience days with BigSnapSearch.com http://www.bigsnapsearch.com From lenglish5 at cox.net Mon Apr 7 14:58:46 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Apr 7 14:58:49 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <20080407165104.214aaf54.sldev@free.fr> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> Message-ID: <47FA9916.7010605@cox.net> Henri Beauchamp wrote: > On Mon, 7 Apr 2008 15:06:50 +0100, Robin Cornelius wrote: > > >> On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote: >> >> .../... >> >> It would be really cool if we could feature freeze for a little while >> and chase some bugs out of the system to get things really stable >> before adding more new things. >> > > Hear, hear !!! > > I can only second it ! > > Yes, pretty please, DO feature freeze SL and DO hunt down every known bug > before resuming the development of new features. > > And for one, I won't mind if the "little while" was counted in months, as > long as it means stable, bugless viewer and server in the end ! > > Well, some bugs and source code oddities in the graphics subsystem were automatically fixed/corrected by the Windlight team, so its counter-productive to say "no new features" when new features are going to fix certain bugs/issues for free as part of deploying said new feature. An even more drastic proposal on MY part is to refactor the client with clean divisions of the GUI and the other subsystems, but for some reason, few programmers who contribute to SL apparently see a need for this... #caps_lock_on I personally see it as the single most important thing that could ever possibly be done to make the Second Life viewer more bugfree, #caps_lock_off but, YMMV. Lawson From kfa at gmx.net Mon Apr 7 15:07:23 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Mon Apr 7 15:07:31 2008 Subject: [sldev] Handling open source translations In-Reply-To: References: Message-ID: <47FA9B1B.3080700@gmx.net> Soft wrote: > I'm curious - how do other projects handle volunteer-submitted > translations? As I understand it, these come with a few liabilities > that need to be resolved: > > * They could be loaded down with obscenities or rudeness. If none of > us speak, say, Latvian, we'd never know the harm of telling someone to > "go pick mushrooms" (a death threat) even if we use machine > translation to verify translations back to English. How do we prevent > that? > There isn't really an alternative to peer review by persons with the relevant knowledge, in that case Latvian speaking SL users. Machine translation is not suitable to deal with adages and such. It gets worse with languages that often use a lot more metaphoric expressions than most European ones, e.g. Arabic. You have no chance of handling that in-house unless you have speakers of that language among your staff and can dedicate their time to the task. > * They could contain misleading translations. A fraudster could have a > field day by reversing LSL debit permission payment accept/reject > buttons and singling out users in that language community. How do we > protect users? We can't simply say the translation is "unsupported." > Not only would we leave people open to harm this way, but we'd create > inventive for submitting these types of translations. > Gee, right! I didn't even think of that. Shivering at the thought that a virus could do that as well, just rewrite the XML files. In light of this, I have to pick up a thought that I had just days ago when I got started poking at the SL source: Is there a good reason that all the floaters and widgets get loaded only at runtime from XML rather than being hard coded into the application? These things are not dynamic and change only during development. It should increase performance if we didn't have to do that, at the expense of only a slightly bigger binary. Look at how Trolltech's Qt toolkit works - it handles UI definitions in XML files, but then takes them into the code by a specially designed preprocessor. If we did that, it should also be much harder to manipulate the SL viewer. It could be automatically compiled into one binary per language and this way totally eliminate the need for external text resources. > * Open source developers don't deliver on a schedule. We can pay for > 1-day turn around from contractors where a language has many users. > But when we get to languages with only a few hundred users, it's tough > to make a case for commercial translation services to do the updates. > We can't hold back shipping while we wait for every last language to > be brought to parity by volunteers. How do we make contributions > timely, or how do we eliminate the need for timely translations? > > Been in a similar situation before, not for an open source but for a commercial project. Translation of the user interface turned out to be quite an effort, we tried to be cheap and it didn't work. If your business depends on it, you ultimately get what you pay for. In the context of SL, I'd reply with the question first, is it really that urgent? To whip up volunteers, a little bit of active lobbying might be in order. There are SL groups dedicated to most countries and languages, maybe they'd be happy to hear from a Linden? > It would be great if we were taking in the new translations that are > often offered. But the initial translation work is only a small > fraction of the overall resources that language support consumes. How > do we make user-submitted translations work? How do other projects > handle these problems? > > I would suggest, create a JIRA per language pack offered, and invite people to proofread it. If found ok, they should cast a vote (since it's not anonymous, abuse should be sufficiently discouraged). If errors are detected, corrections are to be posted in the comments section. Accept a package into the official viewer when a number of votes is reached that you feel comfortable with. Cheers, Felix From tom at streamsense.net Mon Apr 7 16:16:10 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Apr 7 16:16:18 2008 Subject: [sldev] Handling open source translations In-Reply-To: References: Message-ID: <47FAAB3A.5080603@streamsense.net> Soft wrote: > I'm curious - how do other projects handle volunteer-submitted > translations? 1. If the accuracy of a translation is ultimately important for security and for business reasons, pay for a translation. 2. If you can't justify paying for a commercial translation for a specific language, then accept '"community supported" translations for those languages. A "possibly faulty" translation is better than no translation. ~Tom From echerlin at gmail.com Mon Apr 7 16:21:07 2008 From: echerlin at gmail.com (Edward Cherlin) Date: Mon Apr 7 16:21:12 2008 Subject: [sldev] Handling open source translations In-Reply-To: References: Message-ID: On Mon, Apr 7, 2008 at 1:35 PM, Soft wrote: > I'm curious - how do other projects handle volunteer-submitted > translations? As I understand it, these come with a few liabilities > that need to be resolved: For the One Laptop Per Child approach, see http://wiki.laptop.org/go/Localization http://dev.laptop.org/translate The various Free/Open Source Software projects within the GNU/Linux/BSD community all do something similar. Everybody has some plan for having localizations tested by members of the target user group before general distribution. Also, contributions are logged so that each string can be traced back to its author. Localizers have to register and log in each time. Anyone found to be messing with the localizations can be banned. As with Wikipedia, there are further levels of security possible if the problem arises. Since it rarely does, given the current safeguards, those measures can be kept in reserve without imposing any burden on the community when they are not needed. I administer the Haitian Creole French (Krey?l Ayisyen) and Khmer/Cambodia localizations for OLPC. That means that I recruit people and help them get started, and occasionally request a new feature or project for the Pootle localization server, not that I do localization myself. Historical examples of the problems you cite are well-known in the community. I am thinking in particular of a missionary in North America who got himself some scurrilous language informants who thought there was nothing funnier than getting him to put the vilest obscenities into his sermons. > * They could be loaded down with obscenities or rudeness. If none of > us speak, say, Latvian, we'd never know the harm of telling someone to > "go pick mushrooms" (a death threat) even if we use machine > translation to verify translations back to English. How do we prevent > that? That happens at the UN and generally in international communication, apparently all the time. Khrushchev's "We will bury you" is not a threat, but a prediction that We will outlive You. > * They could contain misleading translations. A fraudster could have a > field day by reversing LSL debit permission payment accept/reject > buttons and singling out users in that language community. How do we > protect users? We can't simply say the translation is "unsupported." > Not only would we leave people open to harm this way, but we'd create > inventive for submitting these types of translations. Recruit testing volunteers as well as a localization volunteers. > * Open source developers don't deliver on a schedule. We can pay for > 1-day turn around from contractors where a language has many users. > But when we get to languages with only a few hundred users, it's tough > to make a case for commercial translation services to do the updates. > We can't hold back shipping while we wait for every last language to > be brought to parity by volunteers. How do we make contributions > timely, or how do we eliminate the need for timely translations? You convince the community that the work is valuable, and is either the most important or the most fun work they could be doing right now. You make sure that volunteers come into the project from different sectors of the community. At worst, you hire the professionals to review the work rather than do it all. > It would be great if we were taking in the new translations that are > often offered. But the initial translation work is only a small > fraction of the overall resources that language support consumes. How > do we make user-submitted translations work? How do other projects > handle these problems? -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ "The best way to predict the future is to invent it."--Alan Kay From davep at lindenlab.com Mon Apr 7 16:44:39 2008 From: davep at lindenlab.com (Dave Parks) Date: Mon Apr 7 16:44:43 2008 Subject: [sldev] Requesting for texture In-Reply-To: References: Message-ID: <47FAB1E7.8050300@lindenlab.com> See LLVOVolume::updateTextures. That's where the desired decode resolution of textures is calculated. It's based on the approximate area the object would take up on the screen if you were looking straight at it from your current camera position. It looks like it's visibility agnostic (ignores view angle and occlusion). If you want to see what happens when textures for non-visible objects are not updated, uncomment the "!mDrawable->isVisible()" early out. Qian Hao ~ wrote: > I am currently studying the part on requesting for texture. Does the > viewer only request for texture image that are in the viewing angle or > does it request for every primitives in the island? Is the occlusion > done before request for texture? > > I was looking through the lltexturefetch.cpp and I was wondering what > is decodePriority? Does the client program use this to sort what > texture image to request from the server first? > > Thank you, > Qian Hao > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From brad at lindenlab.com Mon Apr 7 16:49:50 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Mon Apr 7 16:48:08 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> Message-ID: <47FAB31E.4060101@lindenlab.com> Argent is correct, that is the planned functionality for WindLight milestone 2. Currently no one is working towards that milestone as the former WindLight team members are all focused on viewer stability projects. We are currently in the process of evaluating project priorities for the upcoming quarter, and WindLight server side interfaces will, I'm sure, come up in the discussions this week. I think it's likely that stability work will be a higher priority though. WindLight 1.0 was justifiable in that it included significant performance, stability, and compatibility improvement work on the renderer. WindLight 2 is purely a feature. Hopefully by next week I'll be able to report back on how it's been prioritized. -Brad Brandon Husbands wrote: > I dont suppose a linden can answer if we can send them a file or how > long it will be untill we get the option. > > On Mon, Apr 7, 2008 at 1:49 PM, Argent Stonecutter > > wrote: > > On 2008-04-07, at 13:13, Brandon Husbands wrote: > > So let me get this straight.. > I go to my region where i am an estate manager.. I play with > my preference settings and do all the groovy effects.. and > that will set the sim? > > > There will be some new interface that doesn't exist yet that will > allow yo to upload Windlight presets to the sim. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From anthonyrbundy at gmail.com Mon Apr 7 17:17:19 2008 From: anthonyrbundy at gmail.com (Tony) Date: Mon Apr 7 17:17:23 2008 Subject: [sldev] Handling open source translations In-Reply-To: References: Message-ID: <47FAB98F.1090201@gmail.com> One interesting thing that I have heard of (though not in open source) is Google's method of incorporating a way for users to suggest a better translation within the program if they are using a language setting other then English. Maybe there is a way for users to submit suggestions through the viewer? Then you might be able to get a larger group that will likely improve the translation. I'm thinking a language button they can click, and then a place on the viewer (for UI items) to indicate the translation for the viewer item. If text is selected, then they just submit a direct translation of that text. If you get several exact matches from different sources (qualified by time or registration somehow) then you would likely have a high degree of confidence in the translation. It might even be useful for people to just confirm that certain translations are acceptable using this kind of message. Tony Soft wrote: > I'm curious - how do other projects handle volunteer-submitted > translations? As I understand it, these come with a few liabilities > that need to be resolved: > > * They could be loaded down with obscenities or rudeness. If none of > us speak, say, Latvian, we'd never know the harm of telling someone to > "go pick mushrooms" (a death threat) even if we use machine > translation to verify translations back to English. How do we prevent > that? > > * They could contain misleading translations. A fraudster could have a > field day by reversing LSL debit permission payment accept/reject > buttons and singling out users in that language community. How do we > protect users? We can't simply say the translation is "unsupported." > Not only would we leave people open to harm this way, but we'd create > inventive for submitting these types of translations. > > * Open source developers don't deliver on a schedule. We can pay for > 1-day turn around from contractors where a language has many users. > But when we get to languages with only a few hundred users, it's tough > to make a case for commercial translation services to do the updates. > We can't hold back shipping while we wait for every last language to > be brought to parity by volunteers. How do we make contributions > timely, or how do we eliminate the need for timely translations? > > It would be great if we were taking in the new translations that are > often offered. But the initial translation work is only a small > fraction of the overall resources that language support consumes. How > do we make user-submitted translations work? How do other projects > handle these problems? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From poppy at lindenlab.com Mon Apr 7 20:31:36 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Apr 7 20:31:55 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FA9916.7010605@cox.net> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> Message-ID: <47FAE718.7080209@lindenlab.com> >>> On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote: >>> It would be really cool if we could feature freeze for a little while >>> and chase some bugs out of the system to get things really stable >>> before adding more new things. I can see the appeal of the idea, but that doesn't seem feasible for this project. Consider some of the long-term branches now reaching completion. Would we just shelf LSL refactoring until everyone is happy, then resume? That is to say, should studio blighty spend the next quarter hunting bugs in the soon-to-be obsolete LSL runtime? (That is also to say, would you be the one who would tell Babbage and Scouse? I know Scouse could take me on by himself, I'm not gonna tell him that.) > Henri Beauchamp wrote: >> Yes, pretty please, DO feature freeze SL and DO hunt down every known bug >> before resuming the development of new features. Can you tell me a project that has no known bugs? Can you tell me the development lifecycle, budget, and business model of that software? (I want to know how to do that!) Lawson English wrote: > Well, some bugs and source code oddities in the graphics subsystem were > automatically fixed/corrected by the Windlight team, so its > counter-productive to say "no new features" when new features are going > to fix certain bugs/issues for free as part of deploying said new feature. *** THANK YOU! *** There's quite a bit more of that on the horizon, as you probably know. > An even more drastic proposal on MY part is to refactor the client with > clean divisions of the GUI and the other subsystems, but for some > reason, few programmers who contribute to SL apparently see a need for > this... ... and that makes me a Sad Panda. I recently tried to push internally for this. I got kinda deflected, because we have plenty of other APIs yet to design / code that we've already promised. (hello, AWG!) I'd *love* to see this as the first step toward moving forward on that viewer plugin SDK (not to be confused with a viewer scripting API) that everyone's been talking about. I don't work on the viewer now, so I'm not the best person to be rambling about this, but I do think what it would buy us alone in testing would be worth it. I know at least one Linden who could rant about how awesome automated testing becomes with an architecture like that. Unfortunately it's really hard work for what may be seen as little benefit. A case needs to be made that a modular architecture is more important than, say, agni DB scalability, inventory loss, LSL refactoring, build system refactoring, or whatever else engineering is working on. (Contrary to belief, not everyone is working on "flashy new features" no matter how often people repeat that meme with no actual internal information.) It's also more difficult than your average task, because you're essentially developing an API, which you Better Not Screw Up. There have been a few "viewer cleanup" branches going out which should be a step in the right direction, but aren't close to this. If you're interested and have experience doing modularizations like this, start to think about it and make some proposals. There's the AWG protocol development for the sim and grids, but no protocol working groups for the viewer. Make it happen! + poppy From poppy at lindenlab.com Mon Apr 7 20:33:50 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Apr 7 20:34:10 2008 Subject: [sldev] CMake status [was Re: 1.19.1.4 RC - Debug Build] In-Reply-To: <47FA6F8C.6040706@watson.ibm.com> References: <47F952CA.5070007@gmx.net><47FA216E.40201@gmx.net> <47FA673C.5090408@lindenlab.com> <47FA6F8C.6040706@watson.ibm.com> Message-ID: <47FAE79E.9070904@lindenlab.com> Mike Monkowski wrote: > Do you test the debug builds too? Works on Mac for me, altho I admit I've been doing linux builds lately, and have been doing RelWithDebInfo. I also haven't svn switched to cmake-8 yet. + poppy From kamilion at gmail.com Mon Apr 7 20:49:03 2008 From: kamilion at gmail.com (Kamilion) Date: Mon Apr 7 20:49:06 2008 Subject: [sldev] Re: 1.19.1 build issues - big main thread In-Reply-To: References: Message-ID: I've been keeping an eye on the SVN commit mailing list... Would it be possible to actually post the list of LJIRA/PJIRA issue IDs that were assumed resolved in a push instead of the generic "Snapshot of internal branch Branch_1-20-Viewer"? Just the list of issue IDs themselves, we don't need the name or URL associated with the ID, we can look that up ourselves. You seem to be pushing out drops at a rapid rate, and it doesn't seem like there's more than 5 to 6 issues resolved per push, and it would be very very helpful to us to be able to see what's changed in each drop at a glance, especially with all the different branches like maint-ui and the rest. I'm having to spend at least an hour examining the drops to see what's changed, when, and if it was already checked into another branch previously -- Five minutes not spent on your end turns out to be hours spent on our end just keeping track of what changed! I should hope this wouldn't put undue burden on you, as I am acutely aware of how incredibly busy you already are. -- Kami (By the way, normal build fine on ubuntu hardy -- I havn't tried CMAKE yet, but I will sometime soon! +1 love to all y'all for making CMAKE a reality!) On Mon, Apr 7, 2008 at 10:11 AM, Soft wrote: > On Mon, Apr 7, 2008 at 11:59 AM, Soft wrote: > > I built Mac and Linux this morning and ran both without problems. > > Speak up if you're seeing something different. From soft at lindenlab.com Mon Apr 7 21:27:19 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 7 21:27:23 2008 Subject: [sldev] Re: 1.19.1 build issues - big main thread In-Reply-To: References: Message-ID: On Mon, Apr 7, 2008 at 10:49 PM, Kamilion wrote: > I've been keeping an eye on the SVN commit mailing list... > Would it be possible to actually post the list of LJIRA/PJIRA issue > IDs that were assumed resolved in a push instead of the generic > "Snapshot of internal branch Branch_1-20-Viewer"? > > Just the list of issue IDs themselves, we don't need the name or URL > associated with the ID, we can look that up ourselves. > > You seem to be pushing out drops at a rapid rate, and it doesn't seem > like there's more than 5 to 6 issues resolved per push, and it would > be very very helpful to us to be able to see what's changed in each > drop at a glance, especially with all the different branches like > maint-ui and the rest. I'm having to spend at least an hour examining > the drops to see what's changed, when, and if it was already checked > into another branch previously -- Five minutes not spent on your end > turns out to be hours spent on our end just keeping track of what > changed! > > I should hope this wouldn't put undue burden on you, as I am acutely > aware of how incredibly busy you already are. I've given thought to trying to include the commit messages making upeach push, but it gets to be a lot when spread over all the branches. I'm probing to find out how far we are from moving toward a shared repository for internal and external development. If it looks like that's still multiple quarters away, this could be worth it. From dmahalko at gmail.com Tue Apr 8 01:19:16 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Apr 8 01:19:18 2008 Subject: [sldev] LL: Most major projects done? Time to return to haptics :-) Message-ID: We are rapidly reaching the point where LL is completing a bunch of major projects that have been discussed literally for years now. Database scaling, physics, viewer updating, and soon Mono... ? Poor LL may be running out of incredibly huge and ambitious things to occupy their time with these majors out of the way. So let me make a small suggestion for your next big project. :-) I would really like to see a way to interact more directly with virtual environments, and current haptics technologies just do not cut it. Most of them involve sitting in an office chair still staring at a computer monitor while twiddling a small movement-limited knob or joystick. Even the best available technology, the CAVE, still has us just waving our hands around at nonphysical things we cannot touch. You know what I would like to do? I would like to rez a cube, and have the option to reach out with my hand, grab it, and stretch it, turn it, move it around, etc. I'd like to be able to select by pointing at a prim and waggling my finger at it. I'd like to go for a stroll, physically walking through the virtual world, sitting down on a virtual park bench, resting my back on a virtual chair cushion. Then stand up and literally fly up into the air soaring through the clouds, able to feel my body doing physical somersaults and barrel rolls in the air... Sure, sure, this will someday be supposedly possible through nerve implants, the Matrix, blah blah blah. We are decades and possibly a century or more away from that occurring. And besides I really don't want wires jabbing into my spinal cord, and people hacking my brain, thank you very much. So what's the next best thing? There are already people working on a full-body exosuit, that works as a strength enhancing exoskeleton. It has sensors that detect small muscle movements and multiplies that by several times to assist in the lifting and moving of heavy objects. This is intended for common everyday use, in job situations where nurses for example must be able to lift and move hospital patients with high strength but also careful sensitivity. I see this exosuit concept as possibly the ultimate virtual reality haptics interface, if it were reimplemented in a different way for a completely different purpose. Rather than using it to lift physical objects, the exosuit could become the ultimate haptics interface. The suit would be mounted on a suspension boom in midair, with the ability to rotate freely 360-degrees on any axis and with force-reaction cylinders permitting sudden rapid movement of the exosuit up to a meter in any direction. The exosuit would also include a high-resolution stereoscopic HUD and 3D stereophonic sound for the wearer that fully immerses the wearer into the virtual environment.. The exosuit sensors operate so that the wearer feels no weight on their body from the supporting exostructure, and the sensors can quickly move the suit to match any movement of the wearer. The key detail here is that the joints of the exosuit are translated to apply to an avatar in the virtual 3D world, such that movement of the wearer of the exosuit is duplicated by motion of the avatar in the 3D virtual environment. Raise your physical arm and wave to a friend and your avatar immediately does the same. Nod your head, and your avatar does the same. Eye-tracking in the HUD and ultrasonic 3D topography scanning of the face could allow your avatar to match (or map to) your physical facial expressions. The exosuit also receives feedback from the virtual environment to provide direct force-feedback to the suit wearer, such that walking on rough ground in the virtual environment feels rough, as the exosuit boots move against the wearer's feet, to simulate the rough unstable ground. If the person stumbles and falls forward, the suit flips the wearer into a suspended prone position and suddenly jerks hard upward to simulate falling to the virtual ground. Reaching up, the wearer's avatar can grab a ledge and pull themselves up to a sitting position, with the exosuit rotating and moving in midair to now provide a "solid" ground platform, firmly supporting the legs in a straight out position from the hips, as if the wearer were really sitting on the virtual ground. The strength of the exosuit force-reactiveness could be controlled as levels of "user-familiarity", from novice to advanced user, with the full force potentially strong enough to cause skin bruising from high-impact events such as falling off a high-speed virtual motorcycle and the avatar slamming into a virtual brick wall. We've already had force-feeback amusement rides at Disney parks for years, and with the work the exosuit concept, all that needs to be done is to bring the two technologies together for a new application. An exosuit applied to virtual applications could be far lighter than an independently mobile strength exosuit, since the VR exosuit has no need to carry its own power source. A mobile strength exosuit must also have its own heavy actuators mounted directly on the frame, while a VR exosuit can operate using external hydraulic pressure supplied from the support gantry, allowing it to be very light and nimble. So I say enough with these desktop "force feedback" toys and "VR" stereo glasses, and put an end to the CAVEs. I want to literally step into and directly physically manipulate and experience my Second Life.. How about it, LL? It doesn't seem like you'll be too busy after Mono is released.. ;-) - Scalar Tardis / Dale Mahalko From kfa at gmx.net Tue Apr 8 02:16:16 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 8 02:16:20 2008 Subject: [sldev] CMake status In-Reply-To: <47FAE79E.9070904@lindenlab.com> References: <47F952CA.5070007@gmx.net><47FA216E.40201@gmx.net> <47FA673C.5090408@lindenlab.com> <47FA6F8C.6040706@watson.ibm.com> <47FAE79E.9070904@lindenlab.com> Message-ID: <47FB37E0.80007@gmx.net> Not sure if it's going to make friends bringing up yet another alternative, but would anyone like to consider Eclipse CDT? Felix From poppy at lindenlab.com Tue Apr 8 03:04:11 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy)) Date: Tue Apr 8 03:02:10 2008 Subject: [sldev] CMake status In-Reply-To: <47FB37E0.80007@gmx.net> References: <47F952CA.5070007@gmx.net><47FA216E.40201@gmx.net> <47FA673C.5090408@lindenlab.com> <47FA6F8C.6040706@watson.ibm.com> <47FAE79E.9070904@lindenlab.com> <47FB37E0.80007@gmx.net> Message-ID: <47FB431B.6010705@lindenlab.com> Felix Duesenburg wrote: > Not sure if it's going to make friends bringing up yet another > alternative, but would anyone like to consider Eclipse CDT? ____ __ __ _ | _ \ /\ | \/ | | | |_) | / \ | \ / | | | _ < / /\ \ | |\/| | | | |_) / ____ \| | | |_| |____/_/ \_\_| |_(_) http://www.cmake.org/Wiki/CMake:Eclipse + poppy From tillie at xp2.de Tue Apr 8 03:54:14 2008 From: tillie at xp2.de (Tillie Ariantho) Date: Tue Apr 8 03:54:20 2008 Subject: [sldev] LL: Most major projects done? Time to return to haptics :-) In-Reply-To: References: Message-ID: <20080408125414.48j5gse00wlc0cs8@webmail.readonly.de> Quoting Dale Mahalko : [...9 > I would really like to see a way to interact more directly with > virtual environments, and current haptics technologies just do not cut > it. Most of them involve sitting in an office chair still staring at a > computer monitor while twiddling a small movement-limited knob or > joystick. Even the best available technology, the CAVE, still has us > just waving our hands around at nonphysical things we cannot touch. [...] I know of a better project. Fix the bugs: * Sims are unreachable quite a lot * Asset server is not working pretty often * Teleports dont work many times * Groups (especially chat is VERY bugged -- Tillie From gigstaggart at gmail.com Tue Apr 8 04:10:51 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 8 04:10:54 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <47FAB31E.4060101@lindenlab.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> <47FAB31E.4060101@lindenlab.com> Message-ID: <47FB52BB.8010008@gmail.com> Brad Kittenbrink (Brad Linden) wrote: > Argent is correct, that is the planned functionality for WindLight > milestone 2. Currently no one is working towards that milestone as the > former WindLight team members are all focused on viewer stability > projects. We are currently in the process of evaluating project > priorities for the upcoming quarter, and WindLight server side > interfaces will, I'm sure, come up in the discussions this week. > > I think it's likely that stability work will be a higher priority > though. WindLight 1.0 was justifiable in that it included significant > performance, stability, and compatibility improvement work on the > renderer. WindLight 2 is purely a feature. Hopefully by next week I'll > be able to report back on how it's been prioritized. I have to dissent with my associates here that are calling for no new features. I don't think there should be any such "feature freeze". Too often that seems to translate to "work on features *I* care about". When a feature enables new forms of creation, such as Windlight region settings would, I believe that is inherently more valuable than a purely user-centric feature. I've written an entire essay on this topic: http://www.gigstaggart.com/blog/?p=13 So for me, the priorities look something like: 1. Serious Bugs 2. Platform Capital Features (that allow new forms of creation) 3. Other Bugs 4. Non platform capital features Note that Windlight, in terms of its visual enhancements alone, is purely in category 4. Adding the ability to create, impose, suggest, and share atmospheric presets is a category 2 effort. Obviously you could argue that this is just a representation of "What Gigs cares about"... Maybe so. But I think the arguments are pretty compelling to divide up features into two categories, rather than the overly simplistic bug/feature dichotomy that doesn't work so well when your product is also a platform. -Jason From matthew.dowd at hotmail.co.uk Tue Apr 8 04:14:08 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Apr 8 04:14:10 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FAE718.7080209@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: > >>> On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote:> >>> It would be really cool if we could feature freeze for a little while> >>> and chase some bugs out of the system to get things really stable> >>> before adding more new things. Hang on - not that I'm opposed to rebalancing of features versus bug fixing with a much stronger balance on fixing things, but those particular words are Robin Cornelius's (I think) not mine! > Can you tell me a project that has no known bugs? Can you tell me the development lifecycle, budget, and business model of that software?> (I want to know how to do that!) Well no project has no known bugs - but the number of severe and longstanding bugs in SL at the moment would really place it the quality of alpha or early beta! The impression from outside LL is that bugs can reported, acknowledged, imported assigned an internal id, and then stagnate ignored! A good example of the impression that LL just ignores bugs was Torley closing a lot of windlight bugs when windlight moved into the RC as "needs more info - please confirm these are still an issue with the RC", many of which were so trivial to confirm that it would have take someone less than a day to check (and some would have been obvious as not fixed by anyone using the RC). Combined with the fact that the way these were closed (a background script?) meant none of the watchers or reporter got any notification, doesn't help convince people LL takes bug fixing seriously. > > Well, some bugs and source code oddities in the graphics subsystem were > > automatically fixed/corrected by the Windlight team, so its > > counter-productive to say "no new features" when new features are going > > to fix certain bugs/issues for free as part of deploying said new feature.> > *** THANK YOU! ***> > There's quite a bit more of that on the horizon, as you probably know. A total feature freeze is a little unrealistic, admittedly - however, the impression at the moment is that a bug doesn't get fixed unless it is addressed as a side effect of a new feature! (or picked up by the external open source community. We need some (visiable) Lindens dedicated to working through the bug backlog (and also from the sounds of things, the patch backlog too). Some would argue that this should have happened before forcing people onto the 1.19 line. > > An even more drastic proposal on MY part is to refactor the client with > > clean divisions of the GUI and the other subsystems, but for some > > reason, few programmers who contribute to SL apparently see a need for > > this...> > ... and that makes me a Sad Panda. I don't think any of the external open sources disagree a refactor is long overdue and necessary. However, no-one in the external community is likely to put the amount of effort required without some pretty cast iron assurance from LL that it will be incorporated into the code. There is also the practical logistics of doing this, since without access to the LL internal source repository any binary/source drop from LL would often result in the large amount of the work having to be redone. Unless/untill LL allows public access to their internal source repository (and perhaps even then), this is something LL needs to take a lead on. Matthew _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080408/ada62423/attachment.htm From babbage at lindenlab.com Tue Apr 8 04:48:20 2008 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Tue Apr 8 04:48:20 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FAE718.7080209@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr><47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: <47FB5B84.5030904@lindenlab.com> > I can see the appeal of the idea, but that doesn't seem feasible for > this project. Consider some of the long-term branches now reaching > completion. Would we just shelf LSL refactoring until everyone is > happy, then resume? That is to say, should studio blighty spend the > next quarter hunting bugs in the soon-to-be obsolete LSL runtime? > (That is also to say, would you be the one who would tell Babbage and > Scouse? I know Scouse could take me on by himself, I'm not gonna tell > him that.) In fact, this isn't an either or choice. Arguably the biggest benefit of Mono is that it gets us a more stable, tested and secure VM. For example SEC-53 is a simulator crash bug on the LSL runtime, but it causes an exception to be thrown in the Mono runtime, and is caught at compile time by the Mono bytecode verifier. At the moment we're trying to implement post hoc verification of LSL bytecode to fix these problems, but it's finger in the dyke work and it's extremely unlikely that LSL bytecode is completely verifiable. The CIL bytecode that runs on Mono is verifiable by design. ECMA-335 describes the algorithm and the requirements for each opcode. The Mono bytecode verifier is in active development and will be heavily used by Moonlight to run untrusted CIL in browsers. Mono may look like a shiny new feature, but it's arguably a better route to stability and security than freezing LSL and fixing bugs in the existing runtime. Cheers, Jim From olli_aro at yahoo.co.uk Tue Apr 8 05:00:42 2008 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Tue Apr 8 05:00:48 2008 Subject: [sldev] Plotting Data on SLURL In-Reply-To: Message-ID: Hi all, Thanks for great responses and encouragement. I have also found this resource http://secondlife.com/developers/mapapi/, which states that the function for plotting data based on regional coordinates should now also work. I will give this a go later today :) Regards, Olli -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Harold Brown Sent: 07 April 2008 19:41 To: SL-Dev Subject: Re: [sldev] Plotting Data on SLURL [[ Forgot to send to list ]] Is there any further word on updates to the mapAPI system? As of right now not all regions can be displayed, nor are the tile sets exactly the freshest the further you zoom out. I have my own API wrapper made for OpenLayers ( http://www.openlayers.org ), using my custom TML service that uses the SL backend (with some small issues). The wrapper is fairly complete, but I haven't continued work as I don't know what direction LL will be going with the mapAPI system. You can view a demo of the wrapper at: http://www.mysldev.com/OpenLayer/oslurl.html The Region Names are a virtual TML service that generates an image dynamically for the region name. On Mon, Apr 7, 2008 at 11:20 AM, Yoz Grahame wrote: > > Hi Olli, > > Yes, it's completely fine. Go crazy with it! > There's documentation here: http://wiki.secondlife.com/wiki/MapAPI (thanks > to Thraxis Epsilon for that!) _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kfa at gmx.net Tue Apr 8 05:02:27 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 8 05:02:34 2008 Subject: [sldev] CMake status In-Reply-To: <47FB431B.6010705@lindenlab.com> References: <47F952CA.5070007@gmx.net><47FA216E.40201@gmx.net> <47FA673C.5090408@lindenlab.com> <47FA6F8C.6040706@watson.ibm.com> <47FAE79E.9070904@lindenlab.com> <47FB37E0.80007@gmx.net> <47FB431B.6010705@lindenlab.com> Message-ID: <47FB5ED3.5010503@gmx.net> Gotcha. /me slides slowly from his chair to the ground, holding the gunshot wound in his chest, and sighs with his last breath Paul Oppenheim (Poppy) wrote: > Felix Duesenburg wrote: >> Not sure if it's going to make friends bringing up yet another >> alternative, but would anyone like to consider Eclipse CDT? > > ____ __ __ _ | _ \ /\ | \/ | | > | |_) | / \ | \ / | | > | _ < / /\ \ | |\/| | | > | |_) / ____ \| | | |_| > |____/_/ \_\_| |_(_) > > > http://www.cmake.org/Wiki/CMake:Eclipse > > + poppy > From tom at streamsense.net Tue Apr 8 05:28:17 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Apr 8 05:28:29 2008 Subject: [sldev] Dazzle / Windlight merge? Message-ID: <47FB64E1.7060703@streamsense.net> Hi, I was under the impression that first look clients were kept in sync with the normal viewer. Doesn't this imply that the Dazzle client should now incorporate windlight? If not, how come? Cheers, Tom From secret.argent at gmail.com Tue Apr 8 06:23:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 8 06:23:29 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <47FB52BB.8010008@gmail.com> References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> <47FAB31E.4060101@lindenlab.com> <47FB52BB.8010008@gmail.com> Message-ID: <01E45257-B3B2-4F13-AE42-C09D29BA2DD0@gmail.com> On 2008-04-08, at 06:10, Jason Giglio wrote: > When a feature enables new forms of creation, such as Windlight region > settings would, I believe that is inherently more valuable than a > purely > user-centric feature. I have to agree. Here's some platform-capital features that should be "low hanging fruit": * Portals or scripted teleports. (llTeleportAgent) * Non-volatile per-prim storage from scripts. (llGet/SetProperty) * Non-volatile per-user storage from scripts. (llGet/SetUserProperty) * Selective visibility of prims. (llSetVisibilityList) All these things are analogous to capabilities that text-based shared worlds have had. For example, almost all of them let you embed little scripts in descriptions that could read public properties of the viewer and the object, and do things like change the description based on the number of times someone had looked at the object, or whether the viewer had a role-playing ability... so if you inspected a tree a number of times, and you had the ability to see magical objects, the third time you looked at it you would notice a door in the trunk. Opening the door would move you to an "inside the tree" location. From secret.argent at gmail.com Tue Apr 8 06:27:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 8 06:27:41 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FB5B84.5030904@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr><47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> <47FB5B84.5030904@lindenlab.com> Message-ID: <0292050D-378A-4728-959F-A8F510F2F60E@gmail.com> On 2008-04-08, at 06:48, Jim Purbrick (Babbage) wrote: > Arguably the biggest benefit of Mono is that it gets us a more > stable, tested and secure VM. For example SEC-53 is a simulator > crash bug on the LSL runtime, but it causes an exception to be > thrown in the Mono runtime, and is caught at compile time by the > Mono bytecode verifier. [...] Mono may look like a shiny new > feature, but it's arguably a better route to stability and security > than freezing LSL and fixing bugs in the existing runtime. There have been multiple statements from Lindens that the LSL2 runtime is NOT going away, that both CIL and LSL2 will remain available indefinitely. Are you now telling us something different? From marinekelley at gmail.com Tue Apr 8 06:28:02 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Tue Apr 8 06:28:10 2008 Subject: [sldev] Estate Windlight Settings? In-Reply-To: <01E45257-B3B2-4F13-AE42-C09D29BA2DD0@gmail.com> References: <47FA5623.70404@gmail.com> <3A8B4106-4452-4427-8EFC-FC5A2BB48766@gmail.com> <1F605BD4-4EBE-4704-8AF2-89D8B0D1D660@gmail.com> <47FAB31E.4060101@lindenlab.com> <47FB52BB.8010008@gmail.com> <01E45257-B3B2-4F13-AE42-C09D29BA2DD0@gmail.com> Message-ID: <9e52a8c10804080628s78dae2bdya0e7ae2afb537088@mail.gmail.com> * Non-volatile per-user storage from scripts. (llGet/SetUserProperty) Yes ! Me wants !! Well actually a llGetViewerID function would be better (for my own needs) since some of my scripts must check whether the user is on my version of the viewer or not. It is not critical and I do it another way, but it would be nicer, atomic, would relieve both the sim and the scripter from some unnecessary work. Marine 2008/4/8, Argent Stonecutter : > > On 2008-04-08, at 06:10, Jason Giglio wrote: > > > When a feature enables new forms of creation, such as Windlight region > > settings would, I believe that is inherently more valuable than a purely > > user-centric feature. > > > > I have to agree. Here's some platform-capital features that should be "low > hanging fruit": > > * Portals or scripted teleports. (llTeleportAgent) > > * Non-volatile per-prim storage from scripts. (llGet/SetProperty) > > * Non-volatile per-user storage from scripts. (llGet/SetUserProperty) > > * Selective visibility of prims. (llSetVisibilityList) > > All these things are analogous to capabilities that text-based shared > worlds have had. For example, almost all of them let you embed little > scripts in descriptions that could read public properties of the viewer and > the object, and do things like change the description based on the number of > times someone had looked at the object, or whether the viewer had a > role-playing ability... so if you inspected a tree a number of times, and > you had the ability to see magical objects, the third time you looked at it > you would notice a door in the trunk. Opening the door would move you to an > "inside the tree" location. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080408/00fe60aa/attachment.htm From daveh at lindenlab.com Tue Apr 8 06:57:37 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Tue Apr 8 06:57:42 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <0292050D-378A-4728-959F-A8F510F2F60E@gmail.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr><47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> <47FB5B84.5030904@lindenlab.com> <0292050D-378A-4728-959F-A8F510F2F60E@gmail.com> Message-ID: <843519C9-DA7C-4A90-B22D-B2A2DA9DFEC7@lindenlab.com> On 8 Apr 2008, at 14:27, Argent Stonecutter wrote: > On 2008-04-08, at 06:48, Jim Purbrick (Babbage) wrote: >> Arguably the biggest benefit of Mono is that it gets us a more >> stable, tested and secure VM. For example SEC-53 is a simulator >> crash bug on the LSL runtime, but it causes an exception to be >> thrown in the Mono runtime, and is caught at compile time by the >> Mono bytecode verifier. [...] Mono may look like a shiny new >> feature, but it's arguably a better route to stability and security >> than freezing LSL and fixing bugs in the existing runtime. > > > There have been multiple statements from Lindens that the LSL2 > runtime is NOT going away, that both CIL and LSL2 will remain > available indefinitely. Are you now telling us something different? You're correct. LSL2 runtime is not going away. We *may* at some point in the future turn off compiling to LSL2. However, there are several questions that need to be answered before we can make that decision. From alissa_sabre at yahoo.co.jp Tue Apr 8 07:17:45 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Apr 8 07:17:59 2008 Subject: [sldev] Re: 1.19.1 build issues - big main thread In-Reply-To: References: Message-ID: <1dv4dsedzddsdds4dsxfu67f.alissa_sabre@yahoo.co.jp> Soft, I tried 1.19.1.4 (aka r84244, i.e., no RC) bundle, and it worked. Thank you, Soft, for doing the rerolling. Details follow: > > I built Mac and Linux this morning and ran both without problems. > > Speak up if you're seeing something different. I tried it on three platforms: * Macintosh: Intel Mac mini, OS X 10.4.11, Universal configuration; * Linux: Fedora 8, NVIDIA GeForce 7025 + NVIDIA Driver 169.12, scons BTARGET=client STANDALONE=no DISTCC=no, g++ 3.4; and * Windows: XP SP2, Visual C++ Express 2005 SP1, both ReleaseNoOpt and ReleaseForDownload configurations, using "Manual conversion of solution/project files" method. All of them primarily compiled fine and worked fine. I faced two issues during the test builds. On Macintosh build, I got a warning "suggest use of -bind_at_load, as lazy binding may result in errors or different symbols beig used" when Linking AutoUpdater. I believe this is not new to 1.19.1 series, altough I don't find any JIRA issue filing on this. On Linux build, I got trouble with the issue VWR-5734 and needed to remove the g++ command line option "-D_FORTIFY_SOURCE" as a workaround. Although I have not yet used the resulting viewers for long time, I experienced no problems with them. > This should mean all three > platforms are working from source. Confirmed. Alissa Sabre -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From monkowsk at watson.ibm.com Tue Apr 8 07:50:09 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Apr 8 07:50:15 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: <47FB8621.2060508@watson.ibm.com> Matthew Dowd wrote: > The impression from outside LL is that bugs can reported, acknowledged, > imported assigned an internal id, and then stagnate ignored! See also http://nicholaz-beresford.blogspot.com/2008/04/moment-of-truth.html From tofu.linden at lindenlab.com Tue Apr 8 08:00:12 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Apr 8 08:00:14 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FB64E1.7060703@streamsense.net> References: <47FB64E1.7060703@streamsense.net> Message-ID: <47FB887C.4010709@lindenlab.com> Thomas Grimshaw wrote: > I was under the impression that first look clients were kept in sync > with the normal viewer. Not strictly, no - if there is utility in issuing a fresher FL client (i.e. there are more changes/fixes to test specific to the FL) then it will be updated, but that update may or may not be strictly in sync with the latest stable viewer due to the branching structure and the trade-off of whether the gain from picking up the latest fixes outweighs the cost of changing a lot more variables than those which the FL series is intended to exercise. > Doesn't this imply that the Dazzle client should now incorporate > windlight? If not, how come? In this case, because 1.20 is due out Real Soon Now and has Dazzle, Windlight and lots more. :) -Tofu From monkowsk at watson.ibm.com Tue Apr 8 08:10:37 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Apr 8 08:10:44 2008 Subject: [sldev] Major memory leak with 1.19.1 release In-Reply-To: References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <47FA42CF.2060801@watson.ibm.com> <47FA5B5B.904@gmail.com> Message-ID: <47FB8AED.40006@watson.ibm.com> Matthew Dowd wrote: >>I think it's just smartheap fucking up, not that you are actually >>running out of memory. There's a huge jira on this subject. >> >>Just compile without smartheap enabled. > > > I can do that - but this problem is with the Linden compiled release viewer too... > > Matthew I had a look at VWR-3943. I have a solid repro, a debugger, and a leak detector. Its days are numbered. :-) Mike From alissa_sabre at yahoo.co.jp Tue Apr 8 09:13:53 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Apr 8 09:14:03 2008 Subject: [sldev] Handling open source translations In-Reply-To: References: Message-ID: <8ts01dwdds61nJci5ec13PYo.alissa_sabre@yahoo.co.jp> Soft, > I'm curious - how do other projects handle volunteer-submitted > translations? By enough eyeballs. # See the lesson #8 (and #6 also) in The Cathedral and the Bazaar :-) > * They could be loaded down with obscenities or rudeness. Yes, they could be, as the current Linden's official Japanese translation partly *are*. > If none of > us speak, say, Latvian, we'd never know the harm of telling someone to > "go pick mushrooms" Your first mistake is excluding users, or residents in SL terms, from "us". IF there are no Latvian speaking residents in SL, nobody cares about Latvian translation, so the quality doesn't matter. I believe, however, there are *some* Latvian speakers already, who are experienced in SL. If we released just broken Latvian translation, and it said go pick mushrooms, they immediately notice the message was translated in a wrong way, and would complain loudly. (Unless we closed our ears.) BTW, the current Japanese translation is not that bad. It sometimes says complete nonsense and makes users puzzled, but, as far as I know, it says no critical silliness. > if we use machine > translation to verify translations back to English. Who in the world said so? I recommend not to do it, anyway. > * They could contain misleading translations. Yes, as the current Linden's official ... (ditto) > A fraudster could have a > field day by reversing LSL debit permission payment accept/reject > buttons and singling out users in that language community. How do we > protect users? By trusting the community. > We can't simply say the translation is "unsupported." Correct. Saying that and ignoring the complaints on the translation makes things worse. We need to distribute the draft translation for testing (call it beta, RC, FL, whatever), gather feedback from the language users, and repair mistakes fast. During the test cycle, we need to warn users on the possibilities of hazardous mistakes, of course. The point is, making ourselves responsible for the translation. # In that particular reason, I believe it is very bad way to call all # language UI's other than English "Beta" for more than a year... LL could even _hire_ several residents who are (1) very good at Latvian, (2) able to communicate in English, and (3) experienced in SL and ask them to review the traslation, and compensating them with some real money, Linden dollars, or other in-world treats such as free lands. > * Open source developers don't deliver on a schedule. As Lindens don't. Well, I'm not joking. LL has been saying on this SLDev list that LL has no set schedule on viewer releases; they are ready when ready. LL employees always say that's the reason LL never expose future release schedules to open source developers; it is not secrecy. Unless LL has been telling a lie to the community, both LL developers and open source developers don't deliver on a schedule. No differences. > But when we get to languages with only a few hundred users, it's tough > to make a case for commercial translation services to do the updates. I understand it. > We can't hold back shipping while we wait for every last language to > be brought to parity by volunteers. You don't need to. Currently, most of the translations shipped with SL viewer are out-of-sync, due to the recent big changes on the UI design, as well as introduction of WindLight. They are basically not "open source contribution." I've heard you LL has a contract with an external translation service company, and let them translate XUI files. > How do we make contributions > timely, or how do we eliminate the need for timely translations? It is no guaranteed way to make contributions timely. There are no good way to avoid relase-by-release translation. Anyway, Linden's translation process doesn't work well. The translation is not delivered in a timely manner. Why do you worry only about the community's contribution? My suggestion is as follows: (1) Publish LL's changes to base (en-us) XUI files early. The best way will be to publish LL's internal SVN repository, but you should have working on that kinds of things (or some altrnatives to that), so I don't think I need to explain why it is needed. The only thing I can say now is that it's not just C++ source; translation is not an exception. (2) Encourage translators by taking their works as soon as possible, gathering constructive feedback on them, and giving sincere appreciation to them through community development channels. (As oppposed to the current practice, i.e., just ignoring the submission for months or saying "we don't want your translation." Have Lindens learned from the lessons of VWR-1293? It was a sad story... (3) Develop a _drop-in_ mechanism, or something similar to that, to add a new language into the viewer, so that community developped translation can be distributed without bothering Lindens. Languages with hundreds of users will soon be supported by the community if a good mechanims and environment is available. I imagine tens of languages are supported by residents groups, and the updated languages resources are developped during the viewer's RC cycle and released just several days after the viewer's official version up. (4) For some active language groups, you Lindens could set a deadline for translation. For example, you set a deadline three days before the planned release date of the new version of SL viewer. The community tries to stabilize the updated translation, using the RC viewers, by the set date. LL can take the translation that made it on time and put them into the official release package. This *may* solve the issue you raised earlier: open source devs don't deliver on a schedule. There are no guarantee that open source developers deliver on a schedule, but many are happy to try it. Documentation of some Linux distributions are run that way; the core release team sets a date, and the translation groups tries to deliver by the date. In most cases, translated documents are available on time... Anyway I'm grad you Lindens started thinking on this issue. I've been thinking it for more than a year, really... Alissa Sabre -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From secret.argent at gmail.com Tue Apr 8 09:54:11 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 8 09:54:54 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FB887C.4010709@lindenlab.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> Message-ID: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> On 2008-04-08, at 10:00, Tofu Linden wrote: > In this case, because 1.20 is due out Real Soon Now and has Dazzle, > Windlight and lots more. :) Is the Dazzle bright color scheme going to be mandatory to get 1.20? Because I find Dazzle physically painful to use. From danteferret at gmail.com Tue Apr 8 10:23:22 2008 From: danteferret at gmail.com (Dante Tucker) Date: Tue Apr 8 10:23:25 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: <4d211a610804081023o29ce71a4seae0418f1510f1aa@mail.gmail.com> On Tue, Apr 8, 2008 at 12:54 PM, Argent Stonecutter wrote: > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. > > > Dazzle can't be anywhere near done, It does not seem like it has been worked on at all to me. I don't think the plan with dazzle is to redo the UI into what you see in FL. I was under the impression dazzle would introduce client features like easier skinning of the client etc. At least thats what the original plan was. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080408/46930954/attachment.htm From poppy at lindenlab.com Tue Apr 8 11:07:48 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy)) Date: Tue Apr 8 11:05:47 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FB5B84.5030904@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr><47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> <47FB5B84.5030904@lindenlab.com> Message-ID: <47FBB474.9040001@lindenlab.com> Jim Purbrick (Babbage) wrote: > In fact, this isn't an either or choice. Arguably the biggest benefit of > Mono is that it gets us a more stable, tested and secure VM. For example > SEC-53 is a simulator crash bug on the LSL runtime, but it causes an > exception to be thrown in the Mono runtime, and is caught at compile > time by the Mono bytecode verifier. At the moment we're trying to > implement post hoc verification of LSL bytecode to fix these problems, > but it's finger in the dyke work and it's extremely unlikely that LSL > bytecode is completely verifiable. The CIL bytecode that runs on Mono is > verifiable by design. ECMA-335 describes the algorithm and the > requirements for each opcode. The Mono bytecode verifier is in active > development and will be heavily used by Moonlight to run untrusted CIL > in browsers. Thank you for clarifying the specifics with Mono, I just needed to grab the nearest big-project-that's-bringing-stability and found mono. You're right, that's my point. It isn't an either/or choice with anything out right now. Everything lately has a large stability component. Until we release something that doesn't have a large stability or performance component, the "no new features / feature freeze" argument is a strawman. > Mono may look like a shiny new feature, but it's arguably a better route > to stability and security than freezing LSL and fixing bugs in the > existing runtime. And thank you for it! :D + poppy From sldev at free.fr Tue Apr 8 11:15:29 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 8 11:19:24 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FAE718.7080209@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: <20080408201529.0d18d8ca.sldev@free.fr> On Mon, 07 Apr 2008 20:31:36 -0700, Paul Oppenheim (Poppy Linden) wrote: > >>> On Mon, Apr 7, 2008 at 2:46 PM, Matthew Dowd wrote: > >>> It would be really cool if we could feature freeze for a little while > >>> and chase some bugs out of the system to get things really stable > >>> before adding more new things. > > I can see the appeal of the idea, but that doesn't seem feasible for this > project. Consider some of the long-term branches now reaching completion. > Would we just shelf LSL refactoring until everyone is happy, then resume? > That is to say, should studio blighty spend the next quarter hunting bugs > in the soon-to-be obsolete LSL runtime? If it works, don't touch it as it would break it. If it got bugs, then simply fix them. And _yes_ it does mean putting every other development on hold till at least all the identified bugs are fixed ! > > Henri Beauchamp wrote: > > >> Yes, pretty please, DO feature freeze SL and DO hunt down every known bug > >> before resuming the development of new features. > > Can you tell me a project that has no known bugs? Please, do not try and twist my words: I did write _known_ bugs: look at the JIRA: they are hundreds !!! Way enough to keep you busy for months. > Lawson English wrote: > > Well, some bugs and source code oddities in the graphics subsystem were > > automatically fixed/corrected by the Windlight team, so its > > counter-productive to say "no new features" when new features are going > > to fix certain bugs/issues for free as part of deploying said new feature. > > *** THANK YOU! *** Yes, thank you indeed for v1.19.1.4: a viewer that is MUCH slower than 1.19.0.5 was for (by LL's onw admission on the blog) 50% of your residents, a viewer which slows down to a crawl (< 5fps !!!) after only one hour online while 1.19.0.5 runs happily at 20-60fps for hours... What is more counter-producive ? Fixing the bugs in a well tested render pipeline, or writing a new one, with new bugs, less speed and more incompatibilities ? The current headlong rush for more features is certainly not helping to make the viewer more stable neither faster. Bloating the code only brings more issues. You should really start to _optimize_ the code instead (and yes, there is MUCH room for optimization in the current code). Regards, Henri. From tillie at xp2.de Tue Apr 8 11:39:45 2008 From: tillie at xp2.de (Tillie Ariantho) Date: Tue Apr 8 11:40:25 2008 Subject: [?? Probable Spam] Re: [sldev] Dazzle / Windlight merge? In-Reply-To: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: <47FBBBF1.40100@xp2.de> Argent Stonecutter wrote: > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. Yes, true. I can't work with that bright inventory, I dont find anything in there anymore with those colors. If it is going live like that I need to hack it and edit the colors to darker ones. :-( Tillie From tinacloud at gmx.de Tue Apr 8 12:41:02 2008 From: tinacloud at gmx.de (Zi Ree) Date: Tue Apr 8 12:41:08 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FB887C.4010709@lindenlab.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> Message-ID: <200804082141.02994.tinacloud@gmx.de> Am Dienstag 08 April 2008 schrieb Tofu Linden: > In this case, because 1.20 is due out Real Soon Now and has Dazzle, > Windlight and lots more. :) Dazzle? Argh ... I really hope there is a way to either remove or recolor the bright blue GUI ... In dark scenes you simply can't use it, because you can't see anything of the world anymore :P > -Tofu Zi From tom at streamsense.net Tue Apr 8 12:44:53 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Apr 8 12:45:09 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: <47FBCB35.3090106@streamsense.net> Argent Stonecutter wrote: > On 2008-04-08, at 10:00, Tofu Linden wrote: >> In this case, because 1.20 is due out Real Soon Now and has Dazzle, >> Windlight and lots more. :) > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. If Dazzle is made mainstream before SL has full skinning capabilities, i can forsee many, many client hacks circulating. :) ~Tom From tateru.nino at gmail.com Tue Apr 8 13:12:41 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Apr 8 13:17:22 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: <47FBD1B9.9020401@weblogsinc.com> Argent Stonecutter wrote: > On 2008-04-08, at 10:00, Tofu Linden wrote: >> In this case, because 1.20 is due out Real Soon Now and has Dazzle, >> Windlight and lots more. :) > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. Dazzle(n): *1. * To dim the vision of, especially to blind with intense light. -- Tateru Nino http://www.massively.com/ From monkowsk at watson.ibm.com Tue Apr 8 14:24:08 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Apr 8 14:24:14 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FBD1B9.9020401@weblogsinc.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FBD1B9.9020401@weblogsinc.com> Message-ID: <47FBE278.1080804@watson.ibm.com> Tateru Nino wrote: > > > Argent Stonecutter wrote: > >> On 2008-04-08, at 10:00, Tofu Linden wrote: >> >>> In this case, because 1.20 is due out Real Soon Now and has Dazzle, >>> Windlight and lots more. :) >> >> >> Is the Dazzle bright color scheme going to be mandatory to get 1.20? >> >> Because I find Dazzle physically painful to use. > > Dazzle(n): *1. * To dim the vision of, especially to blind with intense > light. My dictionary has two applicable definitions: (vt) 1 : to overpower with light (vi) 1 : to lose clear vision esp. from looking at bright light :-) Mike From overtake at keynet.com.br Tue Apr 8 16:49:46 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Tue Apr 8 17:10:54 2008 Subject: [sldev] Estate Windlight Settings? References: <493033a70804070906m7a04ed11o90ba8beca43a3a6a@mail.gmail.com> <47FA5623.70404@gmail.com> Message-ID: <007f01c899d6$290629e0$6e00a8c0@eaurouge> I remember some time ago Torin put out a zip file with a number of windlight settings he made for us to download and install... I wonder if we can?t make such files, put them on a prim on the tp point of our places for people to get and install. It will be some work the first time, but later on people can just change to this setting when arriving. Far from auto, but this can be a way while we wait for the full feature. Anyone has any idea of how to export these settings? {}Overtake From sammy.frederix at gmail.com Tue Apr 8 18:11:37 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Tue Apr 8 18:11:44 2008 Subject: [sldev] VWR-6186 - review requested Message-ID: <6F9D14AE-A462-4271-9E65-B657B5C60D6C@gmail.com> Hi, While I am waiting for the lindens to process my Contribution Agreement, I was wondering if anyone could look over the (extremely) trivial patch for bug VWR-6186 (https://jira.secondlife.com/browse/VWR-6186 ) which fixes a minor memory leak on start up (on the Mac), as well as a couple of warnings sent to the System Log. From aimee at ama-zing.co.uk Tue Apr 8 18:22:40 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Apr 8 18:22:46 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FBE278.1080804@watson.ibm.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FBD1B9.9020401@weblogsinc.com> <47FBE278.1080804@watson.ibm.com> Message-ID: On Apr 8, 2008, at 22:24, Mike Monkowski wrote: > > My dictionary has two applicable definitions: > > (vt) 1 : to overpower with light > (vi) 1 : to lose clear vision esp. from looking at bright light > Possibly the most accidentally appropriate and ironic project name choice ever, simultaneously. Also blue text on a blue background is in fact a commonly exploited trick for hiding the small print on contracts, relying on the fact that the human eye focuses blue in front of the retina rather than on its surface, which causes blue text to fade into the background, and subconsciously deters people from attempting to read it because it causes discomfort. https://jira.secondlife.com/browse/VWR-5080 If you find the Dazzle colour scheme a problem please vote and comment there to get some visible weight behind the issue, to match the apparently common opinion. Aimee. From hakushakukun at gmail.com Tue Apr 8 19:08:00 2008 From: hakushakukun at gmail.com (Adric R) Date: Tue Apr 8 19:08:04 2008 Subject: [sldev] Re: Dazzle / Windlight merge? Message-ID: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> Dazzle will be released pretty much exactly as it was in the First Look, which makes me wonder why we even bothered having a First Look for it at all. They could have just as easily released the artwork package and saved us all an install. If you look at Benjamin Linden's office hours, most of the feedback we gave him about Dazzle has been pretty much ignored, which is pretty sad; the opinions of residents so far haven't impacted the new skin created by the "resident experience team". I really hope this 1.20 release isn't mandatory. It looks (at least from this outside observer) like as with the chatterbox, LL is going to wait for resident outrage again before addressing problems members of the community saw and were vocal about in advance: in this case, the lack of any means for skin switching. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080408/fc1cb394/attachment.htm From tom at streamsense.net Tue Apr 8 19:09:45 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Apr 8 19:09:57 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> Message-ID: <47FC2569.4020005@streamsense.net> Adric R wrote: > I really hope this 1.20 release isn't mandatory. It looks (at least > from this outside observer) like as with the chatterbox, LL is going > to wait for resident outrage again before addressing problems members > of the community saw and were vocal about in advance: in this case, > the lack of any means for skin switching. Out of curiosity, Does anyone in this list like Dazzle ? ~Tom From tateru.nino at gmail.com Tue Apr 8 19:31:05 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Apr 8 19:35:45 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC2569.4020005@streamsense.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> Message-ID: <47FC2A69.4070606@gmail.com> Thomas Grimshaw wrote: > Adric R wrote: >> I really hope this 1.20 release isn't mandatory. It looks (at least >> from this outside observer) like as with the chatterbox, LL is going >> to wait for resident outrage again before addressing problems members >> of the community saw and were vocal about in advance: in this case, >> the lack of any means for skin switching. > Out of curiosity, > > Does anyone in this list like Dazzle ? > Perhaps not in this list - but I have met two residents who are looking forward to it as is. From labrat.hb at gmail.com Tue Apr 8 20:03:44 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Apr 8 20:03:47 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC2A69.4070606@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> Message-ID: [and again for the entire list] There's a bit more to Dazzle then just changing the graphics. There were several internal changes that had to be made to allow some hard coded colors to be changed as well as to allow for images to be loaded differently. No I don't like the bright blue Dazzle graphics, and I did recolor everything to be darker to fit my taste. Once the 1.20 RC's are available, even if there is not native skin support, I will write an external program to allow for different UI sets at the very least. The external program would only be a stop-gap solution until true "theme / skin" support could be added to the client. On Tue, Apr 8, 2008 at 7:31 PM, Tateru Nino wrote: > Thomas Grimshaw wrote: > > Adric R wrote: > > > > > I really hope this 1.20 release isn't mandatory. It looks (at least from > this outside observer) like as with the chatterbox, LL is going to wait for > resident outrage again before addressing problems members of the community > saw and were vocal about in advance: in this case, the lack of any means for > skin switching. > > > > > Out of curiosity, > > > > Does anyone in this list like Dazzle ? > > > > > Perhaps not in this list - but I have met two residents who are looking > forward to it as is. > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From labrat.hb at gmail.com Tue Apr 8 20:58:19 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Apr 8 20:58:22 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC2A69.4070606@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> Message-ID: I have a few domains I could use... would be no different then the third party clients for most people. As for the slate version posted on the forums. That was mine and for reference for those who hadn't seen it: http://farm3.static.flickr.com/2199/2283545712_270bb33015_b.jpg > That will rock, Harold. My only wonder is, where will people find it? There's no dedicated area for skinning on the website or the forums, and from my experience mentoring, I'd consider the wiki too labyrinthine > for most users to find on their own. Agreed on the brightness, though. I'm surprised the Dazzle team never released at least "test" version of a darker skin for users to try out. Lately, I've been using my own > mix of Dazzle/Classic a lot like the "Slate" version someone posted a while back, and it's pretty rockin'. From poppy at lindenlab.com Tue Apr 8 21:33:52 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Tue Apr 8 21:34:41 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FBD1B9.9020401@weblogsinc.com> <47FBE278.1080804@watson.ibm.com> Message-ID: <47FC4730.7070901@lindenlab.com> Aimee Walton wrote: > Also blue text on a blue background is in fact a commonly exploited > trick for hiding the small print on contracts, relying on the fact that > the human eye focuses blue in front of the retina rather than on its > surface, which causes blue text to fade into the background, and > subconsciously deters people from attempting to read it because it > causes discomfort. Ouch. I've forwarded this thread on to a dazzle dev. + poppy From aimee at ama-zing.co.uk Tue Apr 8 21:39:37 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Apr 8 21:39:42 2008 Subject: [sldev] Branch_1-20-Viewer and libndofdev.dylib (Joystick/Space Navigator support) Message-ID: LIB_NDOF is defined by default in the new branch, meaning ndofdev_external.h and libndofdev.dylib are required but not included. Having temporarily patched in the old versions I was using previously, I can't seem to actually move forwards using it at the moment (I'm guessing that's because I'm using the old lib), but I have to say being able to even just steer with the Space Navigator is a revolution (vague pun intended :) A big thank you to those that made this possible :) I think this makes the SN the killer 'must have' peripheral for SL. Having just used it for flycam control the last few months I'd be lost without it, especially when building. Now being able to control avatar motion entirely with one hand, and still use the mouse/ keyboard with the other makes it completely indispensable. One thing I would request is a tick box to disable the automatic switch to the build manipulation mode, I find it more useful to use it to move my camera around the work-piece, rather than to move prims with it. Though puppeteering objects around the room with it was quite fun, it's far to easy to accidentally nudge the SN while in build mode sending whatever you have selected off to some random position and rotation. It might be more useful for editing if it followed the snap to grid setting, making precise adjustment with it easier. ... and yes having spent 5 minutes in world with the new colour scheme just to test this, I now have a major headache and am off to bed :S Aimee. (SL name Aimee Trescothick). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/a5b16e14/attachment.htm From tofu.linden at lindenlab.com Tue Apr 8 22:12:11 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Apr 8 22:12:14 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FBCB35.3090106@streamsense.net> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FBCB35.3090106@streamsense.net> Message-ID: <47FC502B.8060101@lindenlab.com> Thomas Grimshaw wrote: > Argent Stonecutter wrote: >> On 2008-04-08, at 10:00, Tofu Linden wrote: >>> In this case, because 1.20 is due out Real Soon Now and has Dazzle, >>> Windlight and lots more. :) >> >> Is the Dazzle bright color scheme going to be mandatory to get 1.20? >> >> Because I find Dazzle physically painful to use. > If Dazzle is made mainstream before SL has full skinning capabilities, i > can forsee many, many client hacks circulating. :) Skinnability went into the trunk (and 1.20) at the same time as Dazzle. I haven't experimented with it myself so I don't know how flexible it is, but I'd totally expect it to facilitate de-cyan-ifying Dazzle. -Tofu From ramzi at lindenlab.com Tue Apr 8 22:46:37 2008 From: ramzi at lindenlab.com (Ramzi) Date: Tue Apr 8 22:46:22 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> Message-ID: <47FC583D.8060204@lindenlab.com> Thanks Harold, it's an important point-- the Dazzle project was the first comprehensive change, and also a "proof of needed abstraction" to the UI code. Dazzle is what identified, for example, that the color for Pie Menus shouldn't need to be hardcoded to the same color as the MenuItemDisabledColor. Or that we'd like to separate the icon from its background art(or how about a gradient?) in sortable column headers. I've seen the internal team take the feedback from the First Look very seriously, every week, from the issue tracker & office hours. Yes, the further UI abstraction work and persistent skin installs aren't complete yet; but we've made a heartfelt attempt to update the wiki with real plans for [[Skinning]] this quarter & beyond, aggregate issues in VWR-6027, document some current capabilities in a [[Skinning HowTo/Basics]]*, and (hopefully) see more resident links to their darker/classic skin creations in the meantime. W/r/t optional viewers -- I can say that Linden Lab heard great Resident feedback recently about the advantages to having 2 supported viewer versions available whenever possible. Listening to that feedback is what led to making 1.19.0.5 the minimum version /only after/ 1.19.1 was released about a week ago. -Ramzi [[User:Ramzi Linden]] *this page can't be seen just yet, because wiki.secondlife.com is having auth problems as I type this. sigh. Harold Brown wrote: > [and again for the entire list] > > There's a bit more to Dazzle then just changing the graphics. There > were several internal changes that had to be made to allow some hard > coded colors to be changed as well as to allow for images to be loaded > differently. > > No I don't like the bright blue Dazzle graphics, and I did recolor > everything to be darker to fit my taste. Once the 1.20 RC's are > available, even if there is not native skin support, I will write an > external program to allow for different UI sets at the very least. > > The external program would only be a stop-gap solution until true > "theme / skin" support could be added to the client. > > On Tue, Apr 8, 2008 at 7:31 PM, Tateru Nino wrote: > >> Thomas Grimshaw wrote: >> >>> Adric R wrote: >>> >>> >>>> I really hope this 1.20 release isn't mandatory. It looks (at least from >>>> >> this outside observer) like as with the chatterbox, LL is going to wait for >> resident outrage again before addressing problems members of the community >> saw and were vocal about in advance: in this case, the lack of any means for >> skin switching. >> >>> Out of curiosity, >>> >>> Does anyone in this list like Dazzle ? >>> >>> >>> >> Perhaps not in this list - but I have met two residents who are looking >> forward to it as is. >> >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tateru.nino at gmail.com Wed Apr 9 00:08:47 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 9 00:13:27 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC583D.8060204@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> Message-ID: <47FC6B7F.2030803@gmail.com> That's good feedback for us - and I must admit that as far as the Dazzle project goes, I cannot help but be pleased about a more customizable, skinnable, themeable user interface (actually for my day to day work, I'd love to just hide 90% of the UI). That work isn't easy to see, of course. There's a fair bit of WYSIWYG thinking when it comes to Dazzle (not on your part - on ours). The only part most of us really see is the new skin. Some of us like it. For others it is eye-watering. A changelog about what's going on under the hood that to enable and extend those appearance changes - now that might help show off that the focus isn't really on a single set of surface alterations. Just a suggestion. Ramzi wrote: > Thanks Harold, it's an important point-- the Dazzle project was the > first comprehensive change, and also a "proof of needed abstraction" > to the UI code. Dazzle is what identified, for example, that the > color for Pie Menus shouldn't need to be hardcoded to the same color > as the MenuItemDisabledColor. Or that we'd like to separate the icon > from its background art(or how about a gradient?) in sortable column > headers. > > I've seen the internal team take the feedback from the First Look very > seriously, every week, from the issue tracker & office hours. Yes, > the further UI abstraction work and persistent skin installs aren't > complete yet; but we've made a heartfelt attempt to update the wiki > with real plans for [[Skinning]] this quarter & beyond, aggregate > issues in VWR-6027, document some current capabilities in a [[Skinning > HowTo/Basics]]*, and (hopefully) see more resident links to their > darker/classic skin creations in the meantime. > > W/r/t optional viewers -- I can say that Linden Lab heard great > Resident feedback recently about the advantages to having 2 supported > viewer versions available whenever possible. Listening to that > feedback is what led to making 1.19.0.5 the minimum version /only > after/ 1.19.1 was released about a week ago. > > -Ramzi > [[User:Ramzi Linden]] > > > *this page can't be seen just yet, because wiki.secondlife.com is > having auth problems as I type this. sigh. > > > > Harold Brown wrote: >> [and again for the entire list] >> >> There's a bit more to Dazzle then just changing the graphics. There >> were several internal changes that had to be made to allow some hard >> coded colors to be changed as well as to allow for images to be loaded >> differently. >> >> No I don't like the bright blue Dazzle graphics, and I did recolor >> everything to be darker to fit my taste. Once the 1.20 RC's are >> available, even if there is not native skin support, I will write an >> external program to allow for different UI sets at the very least. >> >> The external program would only be a stop-gap solution until true >> "theme / skin" support could be added to the client. >> >> On Tue, Apr 8, 2008 at 7:31 PM, Tateru Nino >> wrote: >> >>> Thomas Grimshaw wrote: >>> >>>> Adric R wrote: >>>> >>>> >>>>> I really hope this 1.20 release isn't mandatory. It looks (at >>>>> least from >>>>> >>> this outside observer) like as with the chatterbox, LL is going to >>> wait for >>> resident outrage again before addressing problems members of the >>> community >>> saw and were vocal about in advance: in this case, the lack of any >>> means for >>> skin switching. >>> >>>> Out of curiosity, >>>> >>>> Does anyone in this list like Dazzle ? >>>> >>>> >>>> >>> Perhaps not in this list - but I have met two residents who are looking >>> forward to it as is. >>> >>> >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From matthew.dowd at hotmail.co.uk Wed Apr 9 00:21:29 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 9 00:21:33 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC583D.8060204@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> Message-ID: > W/r/t optional viewers -- I can say that Linden Lab heard great Resident > feedback recently about the advantages to having 2 supported viewer > versions available whenever possible. Listening to that feedback is > what led to making 1.19.0.5 the minimum version /only after/ 1.19.1 was > released about a week ago. I think the hearing was a little selective - what was being asked for was that an previous line of viewer is not obsoleted before the current line has been through enough minor releases to iron out the major issues in the current line and allow the current line to bed down. Because 1.19.1 adds the whole windlight pipeline (with quite a few fairly serious known bugs) rather than just mop up issues arising with 1.19.0, I wouldn't regard the 1.19 quite cooked enough to drop the 1.18 line. The fuss when LL tried to make 1.19.0 the minimum browser was that 1.19.0 was not stable enough, not that people wanted 2 abitrary versions available. 1.19.1 isn't as stable as the later 1.18 versions, and doesn't per se make 1.19.0 any more stable. Making 1.19.0 the minimum on the release of 1.19.1 is like Microsoft withdrawing all support for Windows XP (and earlier) on release of Vista Service Pack 1! Matthew _________________________________________________________________ Win 100?s of Virgin Experience days with BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/59caf320/attachment-0001.htm From kfa at gmx.net Wed Apr 9 00:40:22 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 9 00:40:27 2008 Subject: [sldev] Handling open source translations In-Reply-To: <47FAB98F.1090201@gmail.com> References: <47FAB98F.1090201@gmail.com> Message-ID: <47FC72E6.2020805@gmx.net> Tony wrote: > > Maybe there is a way for users to submit suggestions through the > viewer? Then you might be able to get a larger group that will likely > improve the translation. > > I'm thinking a language button they can click, and then a place on the > viewer (for UI items) to indicate the translation for the viewer item. > If text is selected, then they just submit a direct translation of > that text. > > If you get several exact matches from different sources (qualified by > time or registration somehow) then you would likely have a high degree > of confidence in the translation. > > It might even be useful for people to just confirm that certain > translations are acceptable using this kind of message. > > Tony Now that is really neat! :) I can envision how this could be done on the technical side and it doesn't appear too complicated, unless stumbling over something unforeseen. I wouldn't mind trying a stab at it if this was posted as a project. Felix From matthew.dowd at hotmail.co.uk Wed Apr 9 00:47:35 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 9 00:47:37 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC6B7F.2030803@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> Message-ID: > For others it is eye-watering. This is the key part - when it comes to the colour of user interfaces, there is no single solution; and it is not just about preferences, a colour scheme that one person finds extremely clear, can for another be headaching inducingly illegible. Which is why almost from when there were colour monitors software and operating systems allowed the colour schemes to be configurable. Which is why, I, and others, think it is essential that when dazzle goes into an RC it should a) natively support alternate schemes/skins b) come with a number of alternatives pre-installed (I would suggest at a minimum: the blue dazzle one, one based on the current scheme which Harold may be able to help with, and having just looked through the wiki, maybe one based on the old green theme which admittedly was before my time....) Matthew _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/4c47f2d4/attachment.htm From kfa at gmx.net Wed Apr 9 03:14:59 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 9 03:15:05 2008 Subject: Resolved: [sldev] 1.19.1.4 RC - Crashes after successful build In-Reply-To: <47F893E5.2090801@gmx.net> References: <47F893E5.2090801@gmx.net> Message-ID: <47FC9723.2040500@gmx.net> Not sure if anyone else is still experiencing this, but for me it doesn't occur anymore. Why, I am at a loss to explain though. After the umpteenth dumb blind noobish-desperate clean sweep of the source tree incl. converting the project files for MSVC++ 2005 (even reinstalled the official viewer), the problem just vanished ever since I _religiously_ copy my compiled viewer into the program directory of the official viewer, plus only the files I have tweaked in app_settings or xui (keep backups of the originals, of course). I can only concede to some newbie oversight, as I have not been able to trace this back to any understandable cause. Even a binary comparison of the resource files did not reveal anything. Hope the above procedure helps someone else avoid two days of headbanging. The debug configuration still doesn't build. Cheers, Felix PS: To make sure I always know if I'm using the release viewer or my own, I also applied this little change: --- linden-orig/indra/newview/llappviewer.cpp 2008-03-29 16:25:00.000000000 -0400 +++ linden/indra/newview/llappviewer.cpp 2008-04-07 10:36:39.187500000 -0400 @@ -2031,7 +2031,7 @@ } // XUI:translate - gSecondLife = "Second Life"; + gSecondLife = "My Second Life"; // Read skin/branding settings if specified. if (! gDirUtilp->getSkinDir().empty() ) From secret.argent at gmail.com Wed Apr 9 03:30:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 03:30:29 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC583D.8060204@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> Message-ID: <6065A193-F735-4ABB-900A-3F61F7C84159@gmail.com> On 2008-04-09, at 00:46, Ramzi wrote: > W/r/t optional viewers -- I can say that Linden Lab heard great > Resident feedback recently about the advantages to having 2 > supported viewer versions available whenever possible. Listening > to that feedback is what led to making 1.19.0.5 the minimum > version /only after/ 1.19.1 was released about a week ago. The problem is that 1.19.* will not support building over 768 meters, and has related problems (for example it truncates home position and teleport destinations from landmarks to 768 meters), so whether 1.20 is "optional" or not, it will be necessary once people start taking advantage of Havok for building. If Dazzle is going to be in 1.20, then please, could we have one more 1.19 release with the 768 meter limitation removed? From xotmid at gmail.com Wed Apr 9 04:54:37 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Wed Apr 9 04:54:39 2008 Subject: [sldev] MONO: region request. Message-ID: PLease please please for the love of god.. Allow estate owners to turn off old LSL bite code.. It will help us get rid of laggy old scripts.. epically for combat/roleplay sims. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/bb11f644/attachment.htm From secret.argent at gmail.com Wed Apr 9 05:26:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 05:26:39 2008 Subject: [sldev] MONO: region request. In-Reply-To: References: Message-ID: Turning off the old code will not necessarily improve performance. I am totally impressed by how far they've come with Mono, because I've been involved in similar projects to replace "old code" interpreters in realtime systems with more modern systems, and there's all kinds of pitfalls involved in the process... because unless an interpreter is designed for realtime it's very very hard to get good realtime behavior out of it. From nik at terminaldischarge.net Wed Apr 9 05:43:15 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Apr 9 05:43:20 2008 Subject: [sldev] MONO: region request. In-Reply-To: References: Message-ID: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> > Turning off the old code will not necessarily improve performance. But if you are able to disable LSL2 scripts for a region and stop that runtime and only have the mono runtime available (so mono compiled scripts will only work) it gets rid of the problems we currently have with LSL2 (like scripts that are doing nothing still taking a fixed chunk of the processing time). I don't see why this is something that couldn't at least be considered. Something like an option in the region estate tools "Enable LSL2 Runtime for region" and "Enable Mono Runtime for region" with tick boxes and such. Though it could be problematic if the systems aren't designed to be loaded any other time than at simulator boot-up. Though it doesn't personally bother me, as I own no regions. But I can see why he'd ask. > > I am totally impressed by how far they've come with Mono, because > I've been involved in similar projects to replace "old code" > interpreters in realtime systems with more modern systems, and > there's all kinds of pitfalls involved in the process... because > unless an interpreter is designed for realtime it's very very hard to > get good realtime behavior out of it. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net From kfa at gmx.net Wed Apr 9 05:55:02 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 9 05:55:07 2008 Subject: [sldev] About to mess with the LSL compiler Message-ID: <47FCBCA6.7010204@gmx.net> Hi @, I was about to try a take on VWR-5714 (switch/case statement for LSL) and couldn't dig up whether the following questions have been brought up before: How dangerous is it to mess with the bytecode? When the viewer compiles a script and uploads it, does the server verify it in any way? I've read the warning in the script library about adding functions, but what about the language structure itself? If I get it wrong during development, could it potentially crash a region, impair its performance, or even cause other residents' scripts to malfunction? Ultimately: Could a hacker with malicious intent wreak havoc by introducing faulty bytecode this way? For now, I've just submitted a patch to MISC-431 (LSL multiline comments), but this was only a little tweak in the parser which didn't generate any code. I want to stay on the side of caution before digging any deeper. If this has been discussed earlier, I'd appreciate a pointer. Felix From robin.cornelius at gmail.com Wed Apr 9 06:25:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 9 06:25:48 2008 Subject: [sldev] MONO: region request. In-Reply-To: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> Message-ID: On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford wrote: > I don't see why this is something that couldn't at least be considered. > Something like an option in the region estate tools "Enable LSL2 Runtime > for region" and "Enable Mono Runtime for region" with tick boxes and such. > I though, but am probably wrong, that the mono runtime emulates the lsl2 runtime for mono regions so that lsl2 on a mono region is basically wrapped my mono and i recall (but again may have imagined) that even doing this was faster than the native lsl2 engine. Please correct me if i have gone mad. Robin From alissa_sabre at yahoo.co.jp Wed Apr 9 06:38:24 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Apr 9 06:38:37 2008 Subject: [sldev] Possible trouble on SL wiki site Message-ID: <74dvads4eh4kw8uG9eaaev4.alissa_sabre@yahoo.co.jp> To those who may concern, SL wiki site looks more like Wikipedia than SL wiki now (2008-4-9T13:30+0000). It appears that SL wiki is now running with Mediawiki's default skin. At this moment, I have no enough time to analyze what is happening, but I think the SL wiki site is having some trouble. -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From tateru.nino at gmail.com Wed Apr 9 07:15:19 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 9 07:20:10 2008 Subject: [sldev] MONO: region request. In-Reply-To: References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> Message-ID: <47FCCF77.9090709@weblogsinc.com> Robin Cornelius wrote: > On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford wrote: > > >> I don't see why this is something that couldn't at least be considered. >> Something like an option in the region estate tools "Enable LSL2 Runtime >> for region" and "Enable Mono Runtime for region" with tick boxes and such. >> >> > > I though, but am probably wrong, that the mono runtime emulates the > lsl2 runtime for mono regions so that lsl2 on a mono region is > basically wrapped my mono and i recall (but again may have imagined) > that even doing this was faster than the native lsl2 engine. > > Please correct me if i have gone mad. > Two different runtimes. One for LSL source compiled to Mono bytecode and one for LSL source compiled to LSL2 bytecode. That, as I understand it, is where we're headed in the near-term. Each sim having two script runtimes. -- Tateru Nino http://www.massively.com/ From soft at lindenlab.com Wed Apr 9 08:25:09 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 08:25:14 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm Message-ID: If you have something that should be discussed during tomorrow's open source office hour, please add it to: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Otherwise, see you in Hippotropolis From monkowsk at watson.ibm.com Wed Apr 9 08:46:16 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 9 08:46:54 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm In-Reply-To: References: Message-ID: <47FCE4C8.7090004@watson.ibm.com> Soft wrote: > If you have something that should be discussed during tomorrow's open > source office hour, please add it to: > > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda The Wiki says I'm logged in successfuly, but won't let me edit, so I'll post it here: 1. What's coming in 1.20? 2. Skinning for Dazzle. 3. What ever happened to the group voice chat moderation that was supposed to be in 1.19? (Or you could just answer that one here I guess) :-) Mike From soft at lindenlab.com Wed Apr 9 08:57:56 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 08:58:03 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm In-Reply-To: <47FCE4C8.7090004@watson.ibm.com> References: <47FCE4C8.7090004@watson.ibm.com> Message-ID: On Wed, Apr 9, 2008 at 10:46 AM, Mike Monkowski wrote: > Soft wrote: > > > If you have something that should be discussed during tomorrow's open > > source office hour, please add it to: > > > > https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > > > The Wiki says I'm logged in successfuly, but won't let me edit, so I'll > post it here: > > 1. What's coming in 1.20? I'll ask Alcatraz (release team) for notes. > 2. Skinning for Dazzle. A good first point of contact on the skinning question would be Benjamin Linden's office hours. He's the great Grand Poobah of UI issues. His office hours are immediately after the open source hours on Thursdays. http://wiki.secondlife.com/wiki/Office_Hours#Benjamin_Linden > 3. What ever happened to the group voice chat moderation that was supposed > to be in 1.19? (Or you could just answer that one here I guess) :-) No idea. Asking the bhear guys. From soft at lindenlab.com Wed Apr 9 09:53:10 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 09:53:15 2008 Subject: [sldev] 1.20 release notes (rough draft) Message-ID: > On Wed, Apr 9, 2008 at 10:46 AM, Mike Monkowski wrote: > > Soft wrote: > > > > > > 1. What's coming in 1.20? This is rough, and some items may be added or removed before the final release notes: New features and changes: * Updates to the user interface (UI) visual design and architecture: ** A new, lighter color scheme ** Improved UI graphics (icons, buttons, etc) ** Ability to customize text color of Instant Messages ** Enhancements to the UI texture rendering system ** Ability to reference textures by filename ** Support for non-powers-of-two textures ** Support for PNG textures * LSL scripting for object glow! ** Script a prim's glow attribute, details here: http://wiki.secondlife.com/wiki/LlSetPrimitiveParams * Improved Joystick and 3D input device support ** Integrated a new open source library created by 3Dconnexion designed to integrate multi axis input devices with Second Life ** Joystick devices can now control the Avatar, Edited Objects, or the Flycam (View menu > Joystick Flycam) ** Added a "Joystick Setup" window to the Preferences under "Input & Camera" for adjusting multi axis input devices ** Settings are currently optimized for Logitech's 3Dconnexion SpaceNavigator but should be tunable for any joystic or 3D imput device Changes: * DEV-7118 Remove voice setup wizard from Viewer * DEV-11631 Remove "Detecting hardware" from first-use startup to save 10 seconds of start time * DEV-11208 Remove "Critical Message" string from startup community standards dialog * DEV-9641 Remove "Start Gesture" from menu bar * DEV-7119 Remove "do you want streaming audio" dialog * DEV-4898 Get rid of Friends dropdown on Map * DEV-2370 Display the Camera and Movement controls by default * DEV-9779 Add online offline notification to open IM windows * DEV-3677 one click sit should not be available if you're already sitting * DEV-11714 Replace "(hippos)" and "(waiting)" with "(Loading...)" * DEV-4952 Print the name of the missing gesture in the error message * DEV-4706 Make running more intuitive by double-tapping forward * DEV-11146 Move the right justified text on the splash screen just a bit to the left * DEV-6876 Ctrl-shift-1 needs to be in a floater someday. * DEV-2558 Make login progress bar an indefinite status indicator * DEV-7112 Option to turn off all group titles to make name tags smaller * DEV-5502 Small UI tweaks to the "near me" floater for usability Fixes: * DEV-7746 SVC-1072: Havok 4 -- Objects can exist up to 4096 meters up, but scripted rez above 1024 meters fails silently * DEV-2886 SVC-747: Estate Banned Residents list doesn't increment higher than 252 * DEV-12266 VWR-5498: WindLight Release Candidate doesn't rembember correct size of IM window between sessions * DEV-11416 VWR-747: Texture preview should not have constrained aspect ratio * DEV-8349 VWR-3984: WindLight: Certain snapshot options incorrectly capture a part of the screen * DEV-6547 VWR-3438: WindLight: Glow (including water reflections) shows through HUD objects * DEV-10647 VWR-4616: Snapshot, clicking on more removes current pic * DEV-2071 VWR-1405: llMapDestination does not work as designed for OS X/Intel viewers * DEV-6928 VWR-3625: Highlights don't affect non-root prims * DEV-3809 VWR-2113: Mac Auto Updater "hides", giving appearance of failing * DEV-10214 VWR-2755: duplicate PARCEL_FLAG_RESTRICT_PUSHOBJECT line in keywords.ini * DEV-2473 VWR-442: Require confirmation when inviting a new group owner * DEV-10694 VWR-4903: Show avatar's name in the "Eject" and "Freeze" confirmation screens * DEV-13168 VWR-6066: "Are you sure you want to clear you browser cache" in "Perferences > Web > Clear Now" has a typo * DEV-12878 VWR-5656: Secondlife icon missing in Linux version 1.19.1 RC1 ? * DEV-1022 VWR-2600: Add option to enable Full-Scene Anti-Aliasing (FSAA) in the viewer * DEV-7665 VWR-3633: Avatar impostor of not-yet-rezzed avatar not appearing * DEV-2010 Localize LLFloaterCamera / llcameraview.cpp * DEV-6672 glow is rendered on property lines and selection silhouettes * DEV-9868 LLImageJ2C should be able to tell us what en/decoding implementation is being used * DEV-8015 Residents That Have Been Granted Modify Rights Can TAKE the Objects. * DEV-3770 Estate tools in non-english UI cannot change maturity level of islands from PG to Mature. * DEV-1625 Agent Limit spontaneously resets to zero * DEV-9600 Web control code does not correctly reject sl:// links * DEV-10205 Wait before printing missing gestures if the name isn't yet available * DEV-9991 camera smoothing * DEV-7110 LSL call to open place dialog to move user around without opening map * DEV-9605 Cannot close Buy Land floater when (waiting for data) from web site * DEV-9634 Gestures appear in random order - Part Two * DEV-9865 Preference Help button is not pointing to the correct url * DEV-4906 Add Hyperlink to MOTD. * DEV-13163 Occlusion crash on SIS cards * DEV-13045 VBO related crash on ATI R100 cards * DEV-5192 lowest avatar detail is higher than before * DEV-5848 Avatar Impostor sprites have opaque black edges * DEV-5942 impostors tilt * DEV-6662 impostors need to update once after they stop walking * DEV-9854 Give residents the means to detect laggy avatars and visually mute them. Source changes: * The settings system has been significantly revamped. llcontroldef.cpp has been replaced with an XML file controlling all settings values: app_settings/settings.xml * The command line parser has also been revamped. All but a few special arguments are now associated with control settings and controlled by the file app_settings/cmd_line.xml * DEV-10213 VWR-2645: Source typo RELEASE_FOR_DOWNLOAD should be LL_RELEASE_FOR_DOWNLOAD ? * DEV-9937 g++ 4 viewer compile issues * DEV-10091 Dead code removal createLegacyWearableFromAvatar From periapse at lindenlab.com Wed Apr 9 10:03:59 2008 From: periapse at lindenlab.com (Periapse Linden) Date: Wed Apr 9 10:04:01 2008 Subject: [sldev] MONO: region request. In-Reply-To: <47FCCF77.9090709@weblogsinc.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> Message-ID: <47FCF6FF.2010802@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/3feb1dde/attachment.htm From ed at anuff.com Wed Apr 9 10:07:29 2008 From: ed at anuff.com (Ed Anuff) Date: Wed Apr 9 10:07:36 2008 Subject: [sldev] Texture Cache in Simulator? In-Reply-To: <20080409133837.5E72841B2C9@stupor.lindenlab.com> Message-ID: Maybe this is already in place, but, since textures are immutable, does it make sense for the sim to maintain a copy of some number of textures in use in a region? It would make it easier to send these en masse on region entry to make things visible more quickly. Haven't looked at the code in this regards, so as I said, maybe this is already the way it's done, but it seems like textures are pulled on-demand rather than pushed pre-emtively. From xotmid at gmail.com Wed Apr 9 10:17:20 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Wed Apr 9 10:17:29 2008 Subject: [sldev] MONO: region request. In-Reply-To: <47FCF6FF.2010802@lindenlab.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> Message-ID: Ao a simple script? Have you seen the performance spikes when a person is using a AO? Come visit toxia some time and see how well lsl2 is and be careful of the smoking CPU on the sim server. Look at take controls and the way it can lag a sim. Most Combat/Roleplay (which is a Huge chunk of SL actually) sim owners will end up banning anything known to have lsl2 scripts in it i will guarantee that. This is why we need the option to turn it off. I will stop by the office hours and discuss this more. On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden wrote: > Yes, Tateru, as you say there are two different runtimes, LSL2 and Mono. > At launch the Mono runtime will be completely "opt-in": any LSL script that > you created or have modify permission for may be compiled to Mono. From then > on the script will run only under Mono (unless recompiled again back to > LSL2). We need this opt-in paradigm because although Mono is feature > compatible with LSL2, the same script will have different behaviors and > characteristics depending on which runtime it uses. The simple performance > differences between the two runtimes mean that scripts change behavior, and > may need modification to be useful when they switch to Mono. > > Thus in order to not break existing content, we want to ship with both > runtimes, and keep Mono opt-in. Eventually we may turn off compilation to > LSL2 bytecode. This will make Mono automatic for all new script content, > however we are unlikely to turn off the LSL2 runtime on the entire grid. > There are simply too many scripts, actively running in the world, whose > creators have left SL or who don't want to QA and release a Mono version. > > The idea which started this thread was a suggestion to allow estate or > parcel owners the ability to selectively turn off only the LSL2 runtime. > This would mean that scripted attachments using LSL2 would silently fail to > run, much like the way the current "no scripts" switch works, but only for > LSL2. I see merit in the suggestion, but I think it's simply too early to > know if such a feature would be truly useful. Mono definitely improves the > performance dramatically for scripts that do a lot of math, but has much > more humble returns for simple scripts like AOs or attachment size/color > modders. After Mono launches market pressure will develop to encourage > scripters to make Mono versions available for those calculation intensive > scripts that most benefit from Mono. This process, a kind of natural > selection, may obviate the utility of a selective LSL2 disabler. Let's > discuss this feature again after we see how Mono is adopted post launch. > > Any who want more details on our current thinking, plans, or who want to > discuss this feature request, or propose others, are welcome to attend our > Mono office hours. See the Mono betawiki page for the schedule. > > > Tateru Nino wrote: > > Robin Cornelius wrote: > > On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford wrote: > > > > I don't see why this is something that couldn't at least be considered. > Something like an option in the region estate tools "Enable LSL2 Runtime > for region" and "Enable Mono Runtime for region" with tick boxes and > such. > > > > > I though, but am probably wrong, that the mono runtime emulates the > lsl2 runtime for mono regions so that lsl2 on a mono region is > basically wrapped my mono and i recall (but again may have imagined) > that even doing this was faster than the native lsl2 engine. > > Please correct me if i have gone mad. > > > Two different runtimes. One for LSL source compiled to Mono bytecode and > one for LSL source compiled to LSL2 bytecode. That, as I understand it, is > where we're headed in the near-term. Each sim having two script runtimes. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/9140f9ce/attachment-0001.htm From yoz at lindenlab.com Wed Apr 9 10:44:31 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Wed Apr 9 10:44:33 2008 Subject: [sldev] Possible trouble on SL wiki site In-Reply-To: <74dvads4eh4kw8uG9eaaev4.alissa_sabre@yahoo.co.jp> References: <74dvads4eh4kw8uG9eaaev4.alissa_sabre@yahoo.co.jp> Message-ID: On Apr 9, 2008, at 6:38 AM, Alissa Sabre wrote: > To those who may concern, > > SL wiki site looks more like Wikipedia than SL wiki now > (2008-4-9T13:30+0000). It appears that SL wiki is now running with > Mediawiki's default skin. > > At this moment, I have no enough time to analyze what is happening, > but I think the SL wiki site is having some trouble. Yep, there are also the editing problems which Mike mentioned. We're on it. Thanks for the report! -- Yoz From nik at terminaldischarge.net Wed Apr 9 11:24:39 2008 From: nik at terminaldischarge.net (Nicholas Radford) Date: Wed Apr 9 11:23:38 2008 Subject: FW: [sldev] MONO: region request. Message-ID: <004801c89a6e$fa49a6b0$eedcf410$@net> From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Periapse Linden Sent: 09 April 2008 18:04 To: sldev Mailing List Subject: Re: [sldev] MONO: region request. Yes, Tateru, as you say there are two different runtimes, LSL2 and Mono. At launch the Mono runtime will be completely "opt-in": any LSL script that you created or have modify permission for may be compiled to Mono. From then on the script will run only under Mono (unless recompiled again back to LSL2). We need this opt-in paradigm because although Mono is feature compatible with LSL2, the same script will have different behaviors and characteristics depending on which runtime it uses. The simple performance differences between the two runtimes mean that scripts change behavior, and may need modification to be useful when they switch to Mono. Thus in order to not break existing content, we want to ship with both runtimes, and keep Mono opt-in. Eventually we may turn off compilation to LSL2 bytecode. This will make Mono automatic for all new script content, however we are unlikely to turn off the LSL2 runtime on the entire grid. There are simply too many scripts, actively running in the world, whose creators have left SL or who don't want to QA and release a Mono version. The idea which started this thread was a suggestion to allow estate or parcel owners the ability to selectively turn off only the LSL2 runtime. This would mean that scripted attachments using LSL2 would silently fail to run, much like the way the current "no scripts" switch works, You could make an icon for it too J but only for LSL2. I see merit in the suggestion, but I think it's simply too early to know if such a feature would be truly useful. Mono definitely improves the performance dramatically for scripts that do a lot of math, but has much more humble returns for simple scripts like AOs or attachment size/color modders. After Mono launches market pressure will develop to encourage scripters to make Mono versions available for those calculation intensive scripts that most benefit from Mono. This process, a kind of natural selection, may obviate the utility of a selective LSL2 disabler. Let's discuss this feature again after we see how Mono is adopted post launch. Fair enough, I wonder if there is a list for "possible future features to discuss for Mono integration" somewhere I can add the idea too? Or just wait for a convenient time to bring it up again? I don't really think its applicable for Jira, at least not yet. Any who want more details on our current thinking, plans, or who want to discuss this feature request, or propose others, are welcome to attend our Mono office hours. See the Mono beta wiki page for the schedule. I might just do that. J Tateru Nino wrote: Robin Cornelius wrote: On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford wrote: I don't see why this is something that couldn't at least be considered. Something like an option in the region estate tools "Enable LSL2 Runtime for region" and "Enable Mono Runtime for region" with tick boxes and such. I though, but am probably wrong, that the mono runtime emulates the lsl2 runtime for mono regions so that lsl2 on a mono region is basically wrapped my mono and i recall (but again may have imagined) that even doing this was faster than the native lsl2 engine. Please correct me if i have gone mad. Two different runtimes. One for LSL source compiled to Mono bytecode and one for LSL source compiled to LSL2 bytecode. That, as I understand it, is where we're headed in the near-term. Each sim having two script runtimes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/3e23635b/attachment.htm From secret.argent at gmail.com Wed Apr 9 13:08:28 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 13:08:29 2008 Subject: [sldev] MONO: region request. In-Reply-To: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> Message-ID: <4C1D0BE9-5CCD-41EF-B1B5-1144E34A2E7E@gmail.com> On 2008-04-09, at 07:43, Nik Radford wrote: > But if you are able to disable LSL2 scripts for a region and stop that > runtime and only have the mono runtime available (so mono compiled > scripts > will only work) it gets rid of the problems we currently have with > LSL2 > (like scripts that are doing nothing still taking a fixed chunk of the > processing time). I was under the impression that Mono was still using the same basic scheduling algorithms as LSO, because those are a function of the simulation, not the interpreter per-se. From secret.argent at gmail.com Wed Apr 9 13:10:05 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 13:10:06 2008 Subject: [sldev] MONO: region request. In-Reply-To: References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> Message-ID: On 2008-04-09, at 08:25, Robin Cornelius wrote: > I though, but am probably wrong, that the mono runtime emulates the > lsl2 runtime for mono regions so that lsl2 on a mono region is > basically wrapped my mono and i recall (but again may have imagined) > that even doing this was faster than the native lsl2 engine. If that was the case LSL scripts on a Mono region would have many of the same runtime bugs as Mono scripts. From matthew.dowd at hotmail.co.uk Wed Apr 9 13:16:36 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 9 13:16:38 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: References: Message-ID: > * DEV-7746 SVC-1072: Havok 4 -- Objects can exist up to 4096 meters> up, but scripted rez above 1024 meters fails silently> * DEV-8015 Residents That Have Been Granted Modify Rights Can TAKE the Objects. Aren't these server side issues - particularly the last one: if the fix for that is in the viewer, then presumedly third party utils can still take such objects? Matthew _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080409/cc161258/attachment.htm From secret.argent at gmail.com Wed Apr 9 13:17:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 13:17:21 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: References: Message-ID: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> > * DEV-4898 Get rid of Friends dropdown on Map Why? > * DEV-3677 one click sit should not be available if you're already > sitting Why not? > * DEV-4706 Make running more intuitive by double-tapping forward Optional? > * DEV-7746 SVC-1072: Havok 4 -- Objects can exist up to 4096 meters > up, but scripted rez above 1024 meters fails silently That's not a viewer fix. Is the corresponding viewer fix in there? > * DEV-6672 glow is rendered on property lines and selection > silhouettes Does this mean that the property line problem will never be fixed? > * DEV-8015 Residents That Have Been Granted Modify Rights Can TAKE > the Objects. That's not a viewer fix, I hope. o_O From kelly at lindenlab.com Wed Apr 9 13:30:19 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Apr 9 13:30:30 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> Message-ID: <47FD275B.3030901@lindenlab.com> >> * DEV-7746 SVC-1072: Havok 4 -- Objects can exist up to 4096 meters >> up, but scripted rez above 1024 meters fails silently > > That's not a viewer fix. Is the corresponding viewer fix in there? > The problem with releasing rough pre-release notes. You are correct. What is in this viewer is the viewer-side component of increasing the max build height to 4096. Internally that work was tracked in DEV-7746. - Kelly From soft at lindenlab.com Wed Apr 9 13:39:09 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 13:39:20 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> Message-ID: On Wed, Apr 9, 2008 at 3:17 PM, Argent Stonecutter wrote: > > * DEV-8015 Residents That Have Been Granted Modify Rights Can TAKE the > Objects. > > > > That's not a viewer fix, I hope. o_O The change we went with makes that existing behavior more clear in the permission dialog and tooltip. The behavior is by design, but people may not realize they've granted that power. Again, these are rough notes, subject to revision before RC/release. From ordinal.malaprop at fastmail.fm Wed Apr 9 13:41:03 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Wed Apr 9 13:41:12 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> Message-ID: <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> On 9 Apr 2008, at 21:17, Argent Stonecutter wrote: >> * DEV-4706 Make running more intuitive by double-tapping forward > > Optional? NO NO NO NO DON'T DO THAT This is changing fundamental control behaviour. I already have an attachment that detects double-taps for its own purposes, and I know that there are others out there. An easier way for scripts to detect double-taps: yes, great, I'd love to see it. A change in the basic response to double-taps: NO NO NO NO DON'T DO THAT. From secret.argent at gmail.com Wed Apr 9 13:44:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 13:44:41 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> Message-ID: <6146A1BC-B08D-4A05-95F8-6EC2F41CB1E7@gmail.com> On 2008-04-09, at 15:39, Soft wrote: > On Wed, Apr 9, 2008 at 3:17 PM, Argent Stonecutter > wrote: >>> * DEV-8015 Residents That Have Been Granted Modify Rights Can >>> TAKE the Objects. >> That's not a viewer fix, I hope. o_O > > The change we went with makes that existing behavior more clear in the > permission dialog and tooltip. Roger that. Thanks for the clarification. And I think I agree with Ordinal's reaction to the double-tap change. For that matter, I'd like to see autopilot use something other than double-click. From soft at lindenlab.com Wed Apr 9 13:46:42 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 13:46:48 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> Message-ID: On Wed, Apr 9, 2008 at 3:41 PM, wrote: > > On 9 Apr 2008, at 21:17, Argent Stonecutter wrote: > > > > > > * DEV-4706 Make running more intuitive by double-tapping forward > > > > > > > Optional? > > > > NO NO NO NO DON'T DO THAT Being clear here - if you're unhappy with any of these, replying on the list isn't a good way to get them changed or discussed. These aren't open source-specific issues. Create JIRAs for each, filing them as new bugs or requests against the 1.20 source. This way they'll go through the normal Monday (general bug), Wednesday (RC bug) and Thursday (usability bug) office hour triages and will make it back to the right devs and their studio heads. From ramzi at lindenlab.com Wed Apr 9 13:52:06 2008 From: ramzi at lindenlab.com (Ramzi) Date: Wed Apr 9 13:51:51 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FC6B7F.2030803@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> Message-ID: <47FD2C76.2060101@lindenlab.com> Great suggestion. The page I mentioned before is now up on the wiki: https://wiki.secondlife.com/wiki/Skinning_HowTo/Basics This starts with the current (albeit limited) capabilities for changing color, art & sizing as of version 1.20. I'm hoping others will add to it, add other tutorials, and post the results of their mods. I can commit to documenting the capabilities like this, as they improve with each phase of the Skinning project. Ramzi Tateru Nino wrote: > [...] > A changelog about what's going on under the hood that to enable and > extend those appearance changes - now that might help show off that > the focus isn't really on a single set of surface alterations. Just a > suggestion. > > Ramzi wrote: >> Thanks Harold, it's an important point-- the Dazzle project was the >> first comprehensive change, and also a "proof of needed abstraction" >> to the UI code. Dazzle is what identified, for example, that the >> color for Pie Menus shouldn't need to be hardcoded to the same color >> as the MenuItemDisabledColor. Or that we'd like to separate the icon >> from its background art(or how about a gradient?) in sortable column >> headers. >> >> I've seen the internal team take the feedback from the First Look >> very seriously, every week, from the issue tracker & office hours. >> Yes, the further UI abstraction work and persistent skin installs >> aren't complete yet; but we've made a heartfelt attempt to update the >> wiki with real plans for [[Skinning]] this quarter & beyond, >> aggregate issues in VWR-6027, document some current capabilities in a >> [[Skinning HowTo/Basics]]*, and (hopefully) see more resident links >> to their darker/classic skin creations in the meantime. >> >> W/r/t optional viewers -- I can say that Linden Lab heard great >> Resident feedback recently about the advantages to having 2 supported >> viewer versions available whenever possible. Listening to that >> feedback is what led to making 1.19.0.5 the minimum version /only >> after/ 1.19.1 was released about a week ago. >> >> -Ramzi >> [[User:Ramzi Linden]] >> >> >> *this page can't be seen just yet, because wiki.secondlife.com is >> having auth problems as I type this. sigh. >> >> >> >> Harold Brown wrote: >>> [and again for the entire list] >>> >>> There's a bit more to Dazzle then just changing the graphics. There >>> were several internal changes that had to be made to allow some hard >>> coded colors to be changed as well as to allow for images to be loaded >>> differently. >>> >>> No I don't like the bright blue Dazzle graphics, and I did recolor >>> everything to be darker to fit my taste. Once the 1.20 RC's are >>> available, even if there is not native skin support, I will write an >>> external program to allow for different UI sets at the very least. >>> >>> The external program would only be a stop-gap solution until true >>> "theme / skin" support could be added to the client. >>> >>> On Tue, Apr 8, 2008 at 7:31 PM, Tateru Nino >>> wrote: >>> >>>> Thomas Grimshaw wrote: >>>> >>>>> Adric R wrote: >>>>> >>>>> >>>>>> I really hope this 1.20 release isn't mandatory. It looks (at >>>>>> least from >>>>>> >>>> this outside observer) like as with the chatterbox, LL is going to >>>> wait for >>>> resident outrage again before addressing problems members of the >>>> community >>>> saw and were vocal about in advance: in this case, the lack of any >>>> means for >>>> skin switching. >>>> >>>>> Out of curiosity, >>>>> >>>>> Does anyone in this list like Dazzle ? >>>>> >>>>> >>>>> >>>> Perhaps not in this list - but I have met two residents who are >>>> looking >>>> forward to it as is. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From yoz at lindenlab.com Wed Apr 9 14:03:28 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Wed Apr 9 14:03:30 2008 Subject: Wiki fixed (was Re: [sldev] Possible trouble on SL wiki site) In-Reply-To: References: <74dvads4eh4kw8uG9eaaev4.alissa_sabre@yahoo.co.jp> Message-ID: On Apr 9, 2008, at 10:44 AM, Yoz Grahame wrote: > > On Apr 9, 2008, at 6:38 AM, Alissa Sabre wrote: >> To those who may concern, >> >> SL wiki site looks more like Wikipedia than SL wiki now >> (2008-4-9T13:30+0000). It appears that SL wiki is now running with >> Mediawiki's default skin. >> >> At this moment, I have no enough time to analyze what is happening, >> but I think the SL wiki site is having some trouble. > > Yep, there are also the editing problems which Mike mentioned. We're > on it. Thanks for the report! Both the editing and style problems are now fixed. -- Yoz From daveh at lindenlab.com Wed Apr 9 14:08:03 2008 From: daveh at lindenlab.com (Dave Hillier) Date: Wed Apr 9 14:08:10 2008 Subject: [sldev] MONO: region request. In-Reply-To: <4C1D0BE9-5CCD-41EF-B1B5-1144E34A2E7E@gmail.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <4C1D0BE9-5CCD-41EF-B1B5-1144E34A2E7E@gmail.com> Message-ID: <86FC2D4E-A22C-4AD2-B09B-D96D16ED6BDC@lindenlab.com> You're correct. Improving the scheduler is work we have planned in the future. On 9 Apr 2008, at 21:08, Argent Stonecutter wrote: > On 2008-04-09, at 07:43, Nik Radford wrote: >> But if you are able to disable LSL2 scripts for a region and stop >> that >> runtime and only have the mono runtime available (so mono compiled >> scripts >> will only work) it gets rid of the problems we currently have with >> LSL2 >> (like scripts that are doing nothing still taking a fixed chunk of >> the >> processing time). > > I was under the impression that Mono was still using the same basic > scheduling algorithms as LSO, because those are a function of the > simulation, not the interpreter per-se. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From ordinal.malaprop at fastmail.fm Wed Apr 9 14:28:10 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Wed Apr 9 14:28:15 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> Message-ID: <518DA880-BD10-4E84-8785-7AC2C850D0D7@fastmail.fm> On 9 Apr 2008, at 21:46, Soft wrote: > On Wed, Apr 9, 2008 at 3:41 PM, wrote: >> >> On 9 Apr 2008, at 21:17, Argent Stonecutter wrote: >> >>> >>>> * DEV-4706 Make running more intuitive by double-tapping forward >>>> >>> >>> Optional? >>> >> >> NO NO NO NO DON'T DO THAT > > Being clear here - if you're unhappy with any of these, replying on > the list isn't a good way to get them changed or discussed. These > aren't open source-specific issues. > > Create JIRAs for each, filing them as new bugs or requests against the > 1.20 source. This way they'll go through the normal Monday (general > bug), Wednesday (RC bug) and Thursday (usability bug) office hour > triages and will make it back to the right devs and their studio > heads. Okay. For the benefit of anyone interested in the issue, filed as http://jira.secondlife.com/browse/MISC-1100 From soft at lindenlab.com Wed Apr 9 14:32:14 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 14:32:18 2008 Subject: [sldev] 1.20 release notes (cleaned up) Message-ID: Bridie was out this AM and so she couldn't head me off from dropping the last version of the release notes. It turns out she had already done thorough cleanup work. In the future, look to linden/indra/newview/releasenotes.txt by the time of the first RC for these notes. I'm adding a note about this to the docs directory as well: The much clearer, pJIRA-centric: Release Notes for Second Life 1.20(0) April 9th, 2008 ===================================== New features and changes: * Updates to the user interface (UI) visual design and architecture: ** A new, lighter color scheme ** Improved UI graphics (icons, buttons, etc) ** Ability to customize text color of Instant Messages ** Enhancements to the UI texture rendering system ** Ability to reference textures by filename ** Support for non-powers-of-two textures ** Support for PNG textures * LSL scripting for object glow! ** Script a prim's glow attribute, details here: http://wiki.secondlife.com/wiki/LlSetPrimitiveParams * Improved Joystick and 3D input device support ** Integrated a new open source library created by 3Dconnexion designed to integrate multi axis input devices with Second Life ** Joystick devices can now control the Avatar, Edited Objects, or the Flycam (View menu > Joystick Flycam) ** Added a "Joystick Setup" window to the Preferences under "Input & Camera" for adjusting multi axis input devices ** Settings are currently optimized for Logitech's 3Dconnexion SpaceNavigator but should be tunable for any joystic or 3D imput device Changes: * Removed voice setup wizard from Viewer * Removed "Detecting hardware" from first-use startup to save 10 seconds of start time * Removed "Critical Message" string from startup community standards dialog * Removed "Start Gesture" from menu bar * Removed "do you want streaming audio" dialog * Removed Friends dropdown on Map * Display the Camera and Movement controls by default * Added online offline notification to open IM windows * One click sit not be available if you're already sitting * Replaced "(hippos)" and "(waiting)" with "(Loading...)" * Print the name of the missing gesture in the error message * Double-tap forward to run * Adjusted the right-justified text on the splash screen * Ctrl-shift-1 now displays Statistics in a floater * Login progress bar change * Option available to turn off all group titles to make name tags smaller * Small UI tweaks made to the "near me" floater for usability Fixes: * SVC-1072: Havok 4 -- Objects can exist up to 4096 meters up, but scripted rez above 1024 meters fails silently * SVC-747: Estate Banned Residents list doesn't increment higher than 252 * VWR-5498: WindLight Release Candidate doesn't rembember correct size of IM window between sessions * VWR-747: Texture preview should not have constrained aspect ratio * VWR-3984: WindLight: Certain snapshot options incorrectly capture a part of the screen * VWR-3438: WindLight: Glow (including water reflections) shows through HUD objects * VWR-4616: Snapshot, clicking on more removes current pic * VWR-1405: llMapDestination does not work as designed for OS X/Intel viewers * VWR-3625: Highlights don't affect non-root prims * VWR-2113: Mac Auto Updater "hides", giving appearance of failing * VWR-2755: duplicate PARCEL_FLAG_RESTRICT_PUSHOBJECT line in keywords.ini * VWR-442: Require confirmation when inviting a new group owner * VWR-4903: Show avatar's name in the "Eject" and "Freeze" confirmation screens * VWR-6066: "Are you sure you want to clear you browser cache" in "Perferences > Web > Clear Now" has a typo * VWR-5656: Secondlife icon missing in Linux version 1.19.1 RC1 ? * VWR-2600: Add option to enable Full-Scene Anti-Aliasing (FSAA) in the viewer * VWR-3633: Avatar impostor of not-yet-rezzed avatar not appearing * Localization of camera controls/tooltips * Fixed: glow is rendered on property lines and selection silhouettes * LLImageJ2C now indicates what en/decoding implementation is being used * New messaging to inform Residents about consequences of selecting "Can modify my objects" * Fixed: Estate tools in non-english UI cannot change maturity level of islands from PG to Mature. * Fixed: Agent Limit spontaneously resets to zero * Fixed: Web control code does not correctly reject sl:// links * Fixed: Wait before printing missing gestures if the name isn't yet available * Abrupt velocity changes of SL camera are smoother * llMapDestination() can be used to open place dialog to teleport user without opening map * Fixed: Cannot close Buy Land floater when (waiting for data) from web site * Fixed: Gestures appear in random order * Fixed: Preference Help button is not pointing to the correct url * Added Hyperlink to MOTD. * Fixed: Occlusion crash on SIS cards * Fixed: VBO related crash on ATI R100 cards * Fixed: lowest avatar detail is higher than before * Fixed: Avatar Impostor sprites have opaque black edges * Fixed: Impostors tilt * Fixed: Impostors need to update once after they stop walking * Fixed: Provide way to visually mute "costly" avatars (check cost: client->rendering->info displays->avatar render cost) Source changes: * The settings system has been significantly revamped. llcontroldef.cpp has been replaced with an XML file controlling all settings values: app_settings/settings.xml * The command line parser has also been revamped. All but a few special arguments are now associated with control settings and controlled by the file app_settings/cmd_line.xml * VWR-2645: Source typo RELEASE_FOR_DOWNLOAD should be LL_RELEASE_FOR_DOWNLOAD ? * Fixed: g++ 4 viewer compile issues * Dead code removal createLegacyWearableFromAvatar From monkowsk at watson.ibm.com Wed Apr 9 15:07:47 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 9 15:07:51 2008 Subject: [sldev] 1.20 release notes (cleaned up) In-Reply-To: References: Message-ID: <47FD3E33.1060208@watson.ibm.com> Soft wrote: > In the future, look to linden/indra/newview/releasenotes.txt by the > time of the first RC for these notes. Inquiring minds want to know *before* the RC comes out. :-) Mike From ordinal.malaprop at fastmail.fm Wed Apr 9 15:09:55 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Wed Apr 9 15:10:08 2008 Subject: [sldev] 1.20 release notes (cleaned up) In-Reply-To: <47FD3E33.1060208@watson.ibm.com> References: <47FD3E33.1060208@watson.ibm.com> Message-ID: <130C452F-1337-4594-BB9E-99AC3A071DCD@fastmail.fm> Enquiring minds need to use the JIRA more! I am certainly now warned that the best method of getting an opinion across is by filing a bug or feature report on something that doesn't exist yet. I suggest that you take the same approach! On 9 Apr 2008, at 23:07, Mike Monkowski wrote: > Soft wrote: >> In the future, look to linden/indra/newview/releasenotes.txt by the >> time of the first RC for these notes. > > Inquiring minds want to know *before* the RC comes out. :-) > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at lindenlab.com Wed Apr 9 15:18:25 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 9 15:18:31 2008 Subject: [sldev] 1.20 release notes (cleaned up) In-Reply-To: <130C452F-1337-4594-BB9E-99AC3A071DCD@fastmail.fm> References: <47FD3E33.1060208@watson.ibm.com> <130C452F-1337-4594-BB9E-99AC3A071DCD@fastmail.fm> Message-ID: On Wed, Apr 9, 2008 at 5:09 PM, wrote: > On 9 Apr 2008, at 23:07, Mike Monkowski wrote: > > Soft wrote: > > > > > In the future, look to linden/indra/newview/releasenotes.txt by the > > > time of the first RC for these notes. > > > > > > > Inquiring minds want to know *before* the RC comes out. :-) > > Enquiring minds need to use the JIRA more! I am certainly now warned that > the best method of getting an opinion across is by filing a bug or feature > report on something that doesn't exist yet. I suggest that you take the same > approach! If you're comfortable building from source, join the sldev-commits mailing list. The branch has existed for a few days. Otherwise, the RC binary follows not long after the first source drop on the new branch. From gigstaggart at gmail.com Wed Apr 9 15:21:01 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 9 15:21:09 2008 Subject: [sldev] MONO: region request. In-Reply-To: <86FC2D4E-A22C-4AD2-B09B-D96D16ED6BDC@lindenlab.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <4C1D0BE9-5CCD-41EF-B1B5-1144E34A2E7E@gmail.com> <86FC2D4E-A22C-4AD2-B09B-D96D16ED6BDC@lindenlab.com> Message-ID: <47FD414D.30703@gmail.com> Dave Hillier wrote: > You're correct. Improving the scheduler is work we have planned in the > future. Then this answers the question. Sheer number of scripts, more than anything, are what consume CPU. This would make a "disable LSL2" feature less relevant, at least until a new scheduler is in. -Jason From kfa at gmx.net Wed Apr 9 15:24:49 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 9 15:25:00 2008 Subject: [sldev] MONO: region request. In-Reply-To: <47FD414D.30703@gmail.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <4C1D0BE9-5CCD-41EF-B1B5-1144E34A2E7E@gmail.com> <86FC2D4E-A22C-4AD2-B09B-D96D16ED6BDC@lindenlab.com> <47FD414D.30703@gmail.com> Message-ID: <47FD4231.10906@gmx.net> Jason Giglio wrote: > Dave Hillier wrote: > >> You're correct. Improving the scheduler is work we have planned in the >> future. >> > > Then this answers the question. Sheer number of scripts, more than > anything, are what consume CPU. > > What about scripts that only execute a statement once upon default entry, e.g. to set an object property which is not accessible via UI (hovering text etc.)? From gigstaggart at gmail.com Wed Apr 9 15:30:08 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 9 15:30:15 2008 Subject: [sldev] 1.20 release notes (cleaned up) In-Reply-To: References: Message-ID: <47FD4370.1090904@gmail.com> Soft wrote: > * llMapDestination() can be used to open place dialog to teleport user > without opening map What does this mean exactly? Will it show up like a lure? -Jason From nik at terminaldischarge.net Wed Apr 9 15:33:35 2008 From: nik at terminaldischarge.net (Nicholas Radford) Date: Wed Apr 9 15:32:39 2008 Subject: FW: [sldev] MONO: region request. Message-ID: <000101c89a91$c1876330$44962990$@net> And again for the list. (Not having good luck tonight) > -----Original Message----- > From: sldev-bounces@lists.secondlife.com [mailto:sldev- > bounces@lists.secondlife.com] On Behalf Of Jason Giglio > Sent: 09 April 2008 23:21 > To: Dave Hillier > Cc: sldev Mailing List > Subject: Re: [sldev] MONO: region request. > > Dave Hillier wrote: > > You're correct. Improving the scheduler is work we have planned in > the > > future. > > Then this answers the question. Sheer number of scripts, more than > anything, are what consume CPU. > > This would make a "disable LSL2" feature less relevant, at least until > a > new scheduler is in. Only if the same scheduler is used for both mono scripts and LSL2. My guess is they have their own to some degree. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nik at terminaldischarge.net Wed Apr 9 15:34:59 2008 From: nik at terminaldischarge.net (Nicholas Radford) Date: Wed Apr 9 15:34:00 2008 Subject: [sldev] MONO: region request. In-Reply-To: <000101c89a91$c1876330$44962990$@net> References: <000101c89a91$c1876330$44962990$@net> Message-ID: <000201c89a91$f394cd90$dabe68b0$@net> Even better ignore me :P > -----Original Message----- > From: sldev-bounces@lists.secondlife.com [mailto:sldev- > bounces@lists.secondlife.com] On Behalf Of Nicholas Radford > Sent: 09 April 2008 23:34 > To: sldev@lists.secondlife.com > Subject: FW: [sldev] MONO: region request. > > And again for the list. (Not having good luck tonight) > > > > > -----Original Message----- > > From: sldev-bounces@lists.secondlife.com [mailto:sldev- > > bounces@lists.secondlife.com] On Behalf Of Jason Giglio > > Sent: 09 April 2008 23:21 > > To: Dave Hillier > > Cc: sldev Mailing List > > Subject: Re: [sldev] MONO: region request. > > > > Dave Hillier wrote: > > > You're correct. Improving the scheduler is work we have planned in > > the > > > future. > > > > Then this answers the question. Sheer number of scripts, more than > > anything, are what consume CPU. > > > > This would make a "disable LSL2" feature less relevant, at least > until > > a > > new scheduler is in. > > > Only if the same scheduler is used for both mono scripts and LSL2. My > guess > is they have their own to some degree. > > > > > -Jason > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From marinekelley at gmail.com Wed Apr 9 16:13:13 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Wed Apr 9 16:13:19 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> Message-ID: <9e52a8c10804091613o1e8e5a3as80bf79d26b33bf3@mail.gmail.com> I second Ordinal on this one, it would change a lot of scripts behaviour... not to mention it will be impossible to detect through llGetAgentInfo (which detects AGENT_ALWAYS_RUN but certainly won't detect this double-tap). I have tested this double tap to run feature, it works well. It is very practical even... but please let the scripts detect it ! Marine 2008/4/9, Soft : > > On Wed, Apr 9, 2008 at 3:41 PM, wrote: > > > > On 9 Apr 2008, at 21:17, Argent Stonecutter wrote: > > > > > > > > > * DEV-4706 Make running more intuitive by double-tapping forward > > > > > > > > > > Optional? > > > > > > > NO NO NO NO DON'T DO THAT > > > Being clear here - if you're unhappy with any of these, replying on > the list isn't a good way to get them changed or discussed. These > aren't open source-specific issues. > > Create JIRAs for each, filing them as new bugs or requests against the > 1.20 source. This way they'll go through the normal Monday (general > bug), Wednesday (RC bug) and Thursday (usability bug) office hour > triages and will make it back to the right devs and their studio > heads. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/437065e4/attachment.htm From mrfrans at gmail.com Wed Apr 9 16:24:43 2008 From: mrfrans at gmail.com (Frans) Date: Wed Apr 9 16:24:45 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <9e52a8c10804091613o1e8e5a3as80bf79d26b33bf3@mail.gmail.com> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> <9e52a8c10804091613o1e8e5a3as80bf79d26b33bf3@mail.gmail.com> Message-ID: <7765f2c60804091624y5784a83dn5aa0e41661c51c6c@mail.gmail.com> I don't care much for this new feature either, but wouldn't the double tab toggle the always run setting on the server side? On Thu, Apr 10, 2008 at 1:13 AM, Marine Kelley wrote: > I second Ordinal on this one, it would change a lot of scripts > behaviour... not to mention it will be impossible to detect through > llGetAgentInfo (which detects AGENT_ALWAYS_RUN but certainly won't detect > this double-tap). I have tested this double tap to run feature, it works > well. It is very practical even... but please let the scripts detect it ! > > Marine > > -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/297bc887/attachment.htm From secret.argent at gmail.com Wed Apr 9 19:56:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 19:56:12 2008 Subject: [sldev] 1.20 release notes (cleaned up) In-Reply-To: References: Message-ID: <047E6A40-611A-4B37-9DD5-086B676C8CD6@gmail.com> On 2008-04-09, at 16:32, Soft wrote: > * Removed Friends dropdown on Map Why? > * One click sit not be available if you're already sitting Why not? > Fixes: > * SVC-1072: Havok 4 -- Objects can exist up to 4096 meters up, but > scripted rez above 1024 meters fails silently Needs further clarification. > * VWR-3633: Avatar impostor of not-yet-rezzed avatar not appearing What about "not yet rezzed avatar not appearing" even without avatar imposters? > * Fixed: glow is rendered on property lines and selection silhouettes What about VWR-4580? > * llMapDestination() can be used to open place dialog to teleport user > without opening map What about SVC-212? From secret.argent at gmail.com Wed Apr 9 20:51:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 9 20:51:53 2008 Subject: [sldev] 1.20 release notes (rough draft) In-Reply-To: <7765f2c60804091624y5784a83dn5aa0e41661c51c6c@mail.gmail.com> References: <4834B355-4C6F-4D7B-BDCF-1927DDAF2E7D@gmail.com> <41CB431B-4532-41CE-B8EE-77E4EACF0CEF@fastmail.fm> <9e52a8c10804091613o1e8e5a3as80bf79d26b33bf3@mail.gmail.com> <7765f2c60804091624y5784a83dn5aa0e41661c51c6c@mail.gmail.com> Message-ID: <0342D912-37A9-4500-A6E9-7881B3325F0C@gmail.com> Alternate suggestion: VWR-6250 From lenglish5 at cox.net Wed Apr 9 23:15:12 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Apr 9 23:15:14 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FAE718.7080209@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: <47FDB070.60603@cox.net> Paul Oppenheim (Poppy Linden) wrote: [...] > Lawson English wrote: >> Well, some bugs and source code oddities in the graphics subsystem >> were automatically fixed/corrected by the Windlight team, so its >> counter-productive to say "no new features" when new features are >> going to fix certain bugs/issues for free as part of deploying said >> new feature. > > *** THANK YOU! *** > > There's quite a bit more of that on the horizon, as you probably know. > Yep. I'm involved mildly by trying to do docs as theprotocols are developed. https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Rez_Avatar_Capability >> An even more drastic proposal on MY part is to refactor the client >> with clean divisions of the GUI and the other subsystems, but for >> some reason, few programmers who contribute to SL apparently see a >> need for this... > > ... and that makes me a Sad Panda. > > I recently tried to push internally for this. I got kinda deflected, > because we have plenty of other APIs yet to design / code that we've > already promised. (hello, AWG!) I'd *love* to see this as the first > step toward moving forward on that viewer plugin SDK (not to be > confused with a viewer scripting API) that everyone's been talking > about. I don't work on the viewer now, so I'm not the best person to > be rambling about this, but I do think what it would buy us alone in > testing would be worth it. I know at least one Linden who could rant > about how awesome automated testing becomes with an architecture like > that. > It's sad. It seems a no-brainer to me that that LL has to hire a decent crew of folks to re-factor the client from the bottom up and get the GUI into shape. There's things that could be done with a SL-specific GUI that would be overwhelmingly kool. E.G. have windlight-based animated skins: if you enter a goth zone, you get dreary GUI elements complete with dripping water when it rains. Combat sims would get explosion flickering and so on. In theory, you could patch the current client to get those effects, but the GUI is so inefficient (from what little I've seen) that it would be a fps-killer. With the right redesign, I'm positive you could play with all sorts of things in the viewer without impacting the framerate much, if at all. Refactoring things properly, you'd get the plug-in architecture, scripting architecture, lightweight clients, uber GUI skins, etc. And debugging would be a breeze compared to now. > Unfortunately it's really hard work for what may be seen as little > benefit. A case needs to be made that a modular architecture is more > important than, say, agni DB scalability, inventory loss, LSL > refactoring, build system refactoring, or whatever else engineering is > working on. (Contrary to belief, not everyone is working on "flashy > new features" no matter how often people repeat that meme with no > actual internal information.) It's also more difficult than your > average task, because you're essentially developing an API, which you > Better Not Screw Up. Well, thing is, it could be done in parallel with everything else if the APIs were properly documented (those who have ears, let them hear...). > > There have been a few "viewer cleanup" branches going out which should > be a step in the right direction, but aren't close to this. If you're > interested and have experience doing modularizations like this, start > to think about it and make some proposals. There's the AWG protocol > development for the sim and grids, but no protocol working groups for > the viewer. Make it happen! > Problem is, everyone wants immediate results so they're involved with libsl, realXtend or openviewer. Some of us set up a VAG for a modular viewer test harness which could be raided by anyone for ideas and code, but aside from my preliminary python login scripts, which really just test the AWG protocol docs, no-one's done anything with it. https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft Lawson From labrat.hb at gmail.com Wed Apr 9 23:38:16 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Wed Apr 9 23:38:19 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <47FD2C76.2060101@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: http://www.rpgstats.com/SL/Dazzle-Retro.zip - Contains the custom colors.xml file and darker images http://www.rpgstats.com/SL/Dazzle.zip - Contains a blank colors.xml file and the Dazzle UI images (for those who wish to revert without a re-install) Extract the zip file of your choice, there will be two folders. "app_settings" and "skins" Copy those two folders into your SecondLifeReleaseCandidate program folder ( on windows this is C:\Program Files\SecondLifeReleaseCandidate\ by default ) I may or may not work on an installer for this, it depends on what my time is like. On Wed, Apr 9, 2008 at 1:52 PM, Ramzi wrote: > Great suggestion. The page I mentioned before is now up on the wiki: > https://wiki.secondlife.com/wiki/Skinning_HowTo/Basics From matthew.dowd at hotmail.co.uk Thu Apr 10 03:47:07 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 10 03:47:09 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: Sorry, this post is harsh, negative, and will offend someone in the UI team, I've no doubt but it needs to be said! I see that Dazzle is going the same way as the Communicator window fiasco. Namely that LL release a firstlook, and then completely ignore the feedback, release the feature almost exactly as in the firstlook client and are then surprised by the negative feedback, and spend the next six months drip feeding small tweaks in an attempt to improve the mistake. OK, so with both the communicate window and dazzle there are a number of "i hate it please switch back" comments, but there were and are a number of comments which quite clearly set out some of the real issues, and even suggest solutions, and yet are totally ignored. There is another similarity between Dazzle and the Communicate window - whoever is behind the design of these seems to forget the raison d'etre of SL. The focus of attention in SL should be on the 3D world, not on the UI. Both the communicate and dazzle distract the attention from the 3D world onto the UI. This may hurt the egos of the UI team but a successful UI for an SL client should be one which the user doesn't notice, and just uses! If LL had actually bothered to listen to the feedback on the firstlook client from users they would have noticed two major points: i) that what was not needed was a new colour theme but more some level of easy (i.e. not hacking XML files) control over the colours. This is captured in jira as https://jira.secondlife.com/browse/VWR-5059 namely the ability to switch skins from within the client, and include the current colourisation as one of the default skins included with the client ii) that the new scheme far from being "more accessible and pleasing", actually causes eye strain. This is also captured in jira, had anyone from the UI team bothered to check, as https://jira.secondlife.com/browse/VWR-5080 , and in there one of the comments provides medical and documentary evidence why the scheme chosen by LL is a potential health risk and accessibility problem! Dazzle should not have got into an RC without at least one of these *major* issues being addressed. Had both been addressed, you might have managed a blog post which generated overwhelming postive responses on the blog comments and forums, whereas by ignoring both of these, LL has once again successfully snatched disaster from the jaws of victory! Matthew _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/4b46ccbf/attachment.htm From tillie at xp2.de Thu Apr 10 04:02:02 2008 From: tillie at xp2.de (Tillie Ariantho) Date: Thu Apr 10 04:02:48 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: <47FDF3AA.8080604@xp2.de> Matthew Dowd wrote: > I see that Dazzle is going the same way as the Communicator window fiasco. Namely that LL release a firstlook, and then completely ignore the feedback, release the feature almost exactly as in the firstlook client and are then surprised by the negative feedback, and spend the next six months drip feeding small tweaks in an attempt to improve the mistake. [...] I second this post. An idea would be: make a color/UI scheme for dazzle that looks like the old client, and let the user decide to switch to BRIGHT colors and changes. Add an UI selection dropdownbox somwhere for with SL included and user created UIs. Tillie From Anders at Arnholm.se Thu Apr 10 04:08:07 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Thu Apr 10 04:08:34 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: <20080410110807.GC3107@arnholm.se> On Thu, Apr 10, 2008 at 10:47:07AM +0000, Matthew Dowd wrote: > Dazzle should not have got into an RC without at least one of these *major* > issues being addressed. Had both been addressed, you might have managed a blog > post which generated overwhelming postive responses on the blog comments and > forums, whereas by ignoring both of these, LL has once again successfully > snatched disaster from the jaws of victory! I hate sending a message like this not adding anything, But as much I love windlight, the renderar part I think the 1.19 ui chanegs in IM tabs suck so much I can hardly live wuith it. Also what stuff go bad on the serverside 1.19 is much much more carsing that 1.18, and i revert back to 1.18.6.77465 so i get windlight and 1.18 gui, thats still te most stable over all on my system, some (major) windlight bugs like non showing avatars make it less optimal for being the main viewer thou. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080410/bccf3968/attachment.pgp From zak.escher at gmail.com Thu Apr 10 07:10:49 2008 From: zak.escher at gmail.com (Zak Escher) Date: Thu Apr 10 07:10:56 2008 Subject: [sldev] How to search for issues in JIRA? Message-ID: <47FE1FE9.4050504@gmail.com> I inadvertently entered a duplicate Jira issue (about the Friends dropdown being removed from the map). I searched Jira for issues with the 1.2 release candidate before entering the issue. I only saw 3 issues. How do I search Jira to find all the issues people have entered for the 1.2 release candidate? From sldev at free.fr Thu Apr 10 08:20:44 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Apr 10 08:20:48 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: <20080410172044.5cb31e9b.sldev@free.fr> On Thu, 10 Apr 2008 10:47:07 +0000, Matthew Dowd wrote: > Sorry, this post is harsh, negative, and will offend someone in the > UI team, I've no doubt but it needs to be said! Welcome to the club of the "rude people" saying what must be said... and (hopefully) listened to. I'm afraid I'm going to howl with you and be rather rude and blunt once again with LL... :-/ Believe me, I would prefer to congratulate everyone, but it is simply impossible in the current state of the affair. > I see that Dazzle is going the same way as the Communicator window > fiasco. Namely that LL release a firstlook, and then completely ignore > the feedback, release the feature almost exactly as in the firstlook > client and are then surprised by the negative feedback, and spend the > next six months drip feeding small tweaks in an attempt to improve the > mistake. I wholeheartedly second this, but really... What did you expect ? LL as a whole proved countless times that it is totally autistic to its _customers_' feedback and needs. Sometimes, one or two Lindens will do a good job explaining, and even replying (yes, they do, sometimes) to the residents either on the blog or on the mailing lists like this one. But 90% of the time, your pleas will fall into deaf ears. Plus, in the remaining 10%, the Linden who will be kind enough to reply and/or listen to you is not the one who will be able to make things move in the way you wish (and on a side note, I feel very sorry for the Lindens in question, because they are most likely the ones who will be hurted by my criticims: the others simply won't care). The developpers obviously don't work following the requests of the residents but only do what they themselves find "cool and dandy". There is no such thing as a clear roadmap that the residents could at least influence a little (what about making _serious_ and _exhaustive_ polls for the new features, or polling about the feedback to a release candidate ?). The project management is either absent or screwed, and instead of concentrating the power of the devel teams on fixing the bugs which daily ruin the residents' experience, they just let the various devel teams do what they wish and push new "features" which prove bad mistakes in the end, bloating further the code, and adding more bugs to the bunch of well known but still unfixed (for months) bugs. And I have been managing for over 20 years, so I know what I am speaking about... The QA is incompetent, delaying uselessly the patches submitted by the open source community while they proved they were working perfectly well and were not breaking anything, and on the other hand they let huge, obvious bugs slip through in new releases (such bugs that you stumble onto just 5 minutes after you logged in with the new viewer...). I can already make a prediction: if LL does not change really quickly the way they handle the development and the relations with their customers, they will "soon" (I give it 2 years at most to happen) find out that other companies can do better and swip the lot. The only reason why it did not already happened is that LL lived on a monopoly. This is currently changing and the only chance left to LL will be that their customers created a huge amount of contents that new games will take a few years to equal. I for one, am not far from either: - forking the viewer for good to make my own and show all the script kiddies at LL how a single person (who is not even a genius), working only during part of his free time, can do a better job than what they are doing. - giving up everything SL related and moving on to other, more gratifying things (Nicholaz is showing the way right now... saddly !). I already gave up submitting bug reports to the JIRA as this proved to be a total loss of time and energy. > OK, so with both the communicate window and dazzle there are a number > of "i hate it please switch back" comments, but there were and are a > number of comments which quite clearly set out some of the real > issues, and even suggest solutions, and yet are totally ignored. Rule #1: LL is always right regarding SL development. Rule #2: when LL is wrong, refer to rule #1. Rule #3: LL never commits mistakes. Rule #4: when a mistake happens, it's the ISP's fault, the Greemlins, or because of the full moon (the gradient in the gravitation changes tends to influence the database transactions...). But let's get serious again... > There is another similarity between Dazzle and the Communicate window > - whoever is behind the design of these seems to forget the raison > d'etre of SL. The focus of attention in SL should be on the 3D world, > not on the UI. Matthew... I think I'm falling in love with you... Err.. OK, I said "serious", didn't I ?... Yes, of course you are right. But LL script kiddies just _love_ playmobil-like UIs. They want the residents to drool at how pretty the UI is. They don't care the least about how _useful_, _practical_ or _accessible_ is their UI: all what counts is that it looks good damnit ! > Both the communicate and dazzle distract the attention from the 3D > world onto the UI. This may hurt the egos of the UI team but a > successful UI for an SL client should be one which the user > doesn't notice, and just uses! Matthew... would you marry me ? > If LL had actually bothered to listen to the feedback on the > firstlook client from users they would have noticed two major > points: > > i) that what was not needed was a new colour theme but more some > level of easy (i.e. not hacking XML files) control over the > colours. This is captured in jira as https://jira.secondlife.com/ > browse/VWR-5059 namely the ability to switch skins from within the > client, and include the current colourisation as one of the > default skins included with the client Frankly, I don't think more than 5% of the residents really care about UI skinning for the viewer. If you would let them the choice in a poll between getting the current viewer bugs fixed and moving to Dazzle, I bet than 95% of the votes would go to the bug fixes. This is simple logic... But LL is not a cartesian company. Rule #5: LL's logic is flawed, but flawed logic rocks ! > ii) that the new scheme far from being "more accessible and > pleasing", actually causes eye strain. This is also captured > in jira, had anyone from the UI team bothered to check, as > https://jira.secondlife.com/browse/VWR-5080 , and in there one > of the comments provides medical and documentary evidence why > the scheme chosen by LL is a potential health risk and > accessibility problem! Frankly, I am curious to see any "evidence" about the health issue, but I agree wholeheartedly that beside being distracting to the eye, Dazzle's UI is definitely going against accessibility basics. > Dazzle should not have got into an RC without at least one of > these *major* issues being addressed. Had both been addressed, > you might have managed a blog post which generated overwhelming > postive responses on the blog comments and forums, whereas by > ignoring both of these, LL has once again successfully snatched > disaster from the jaws of victory! > > Matthew Amen ! Henri. From soft at lindenlab.com Thu Apr 10 08:44:00 2008 From: soft at lindenlab.com (Soft) Date: Thu Apr 10 08:44:03 2008 Subject: [sldev] How to search for issues in JIRA? In-Reply-To: <47FE1FE9.4050504@gmail.com> References: <47FE1FE9.4050504@gmail.com> Message-ID: On Thu, Apr 10, 2008 at 9:10 AM, Zak Escher wrote: > I inadvertently entered a duplicate Jira issue (about the Friends dropdown > being removed from the map). I searched Jira for issues with the 1.2 release > candidate before entering the issue. I only saw 3 issues. How do I search > Jira to find all the issues people have entered for the 1.2 release > candidate? I think your fundamental point of confusion is that we're on 1.20, not 1.2. Each number between the decimals can be any number of digits. From labrat.hb at gmail.com Thu Apr 10 08:55:54 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Apr 10 09:02:00 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080410172044.5cb31e9b.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> Message-ID: Since I'm now about tired of seeing the same things on almost every thread I'll reply here. If all you want to do is bitch about how poorly LL is doing... do it on your personal blog. Yes I hate the Dazzle UI, Yes I posted my dislike when it was first shown, and when the Firstlook Came out. But the difference is I didn't bitch about how LL didn't listen to me. I made a Retro Dazzle skin with the classic UI colors and darker Dazzle interface images. I also posted it for people to download now that Dazzle and Windlight are merged with 1.20 From zak.escher at gmail.com Thu Apr 10 09:02:40 2008 From: zak.escher at gmail.com (Zak Escher) Date: Thu Apr 10 09:02:45 2008 Subject: [sldev] How to search for issues in JIRA? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: <47FE3A20.8060507@gmail.com> Actually I made a typo in my email. I meant 1.20. I think I have found what I was not doing correctly in the jira searches. I was specifying the version in "Fix For" and not "Affects Versions." Once I made that filter change, I seem to get the list of issues. Soft wrote: > On Thu, Apr 10, 2008 at 9:10 AM, Zak Escher wrote: > >> I inadvertently entered a duplicate Jira issue (about the Friends dropdown >> being removed from the map). I searched Jira for issues with the 1.2 release >> candidate before entering the issue. I only saw 3 issues. How do I search >> Jira to find all the issues people have entered for the 1.2 release >> candidate? >> > > I think your fundamental point of confusion is that we're on 1.20, not > 1.2. Each number between the decimals can be any number of digits. > From sldev at free.fr Thu Apr 10 09:07:56 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Apr 10 09:07:57 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> Message-ID: <20080410180756.05cd17d5.sldev@free.fr> On Thu, 10 Apr 2008 08:55:54 -0700, Harold Brown wrote: > Since I'm now about tired of seeing the same things on almost every > thread I'll reply here. > > If all you want to do is bitch about how poorly LL is doing... do it > on your personal blog. > > Yes I hate the Dazzle UI, Yes I posted my dislike when it was first > shown, and when the Firstlook Came out. But the difference is I > didn't bitch about how LL didn't listen to me. I made a Retro Dazzle > skin with the classic UI colors and darker Dazzle interface images. I > also posted it for people to download now that Dazzle and Windlight > are merged with 1.20 http://sldev.free.fr/ Have a nice day. From matthew.dowd at hotmail.co.uk Thu Apr 10 09:31:49 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 10 09:31:50 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <47FDF3AA.8080604@xp2.de> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <47FDF3AA.8080604@xp2.de> Message-ID: > An idea would be: make a color/UI scheme for dazzle that looks like the old client, and let the user decide to switch to BRIGHT colors and changes. Add an UI selection dropdownbox somwhere for with SL included and user created UIs. I *think* I've worked out the code changes needed to do precisely that, and have downloaded Harold Brown's scheme to test switching between the two. My changes even compile but... As usual, there is a delay between the binary drop of an RC and the source drops, so I'm having to work with the code in the repository which has missing files (as usual but I think I've worked around that - luckily the new joystick device code can be disabled with a undef), and doesn't include the libraries, so I'm stuck at the link step unless someone wants to point me at the libboost binaries for VS2005 (as I really do not want to have to compile those from scratch life is too short). Sorry, Harold, for another gripe, but does LL really wonder why the open source effort is shrinking rather than growing (or jumping ship to work on non-LL Virtual World projects like OpenSim, OpenCroquet or Wonderland) when they put so many obstacles in the way? Matthew _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/b2d43108/attachment.htm From lenglish5 at cox.net Thu Apr 10 09:55:56 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Apr 10 09:55:59 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FDB070.60603@cox.net> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> <47FDB070.60603@cox.net> Message-ID: <47FE469C.7080201@cox.net> Lawson English wrote: > Paul Oppenheim (Poppy Linden) wrote: > [...] > >> Unfortunately it's really hard work for what may be seen as little >> benefit. A case needs to be made that a modular architecture is more >> important than, say, agni DB scalability, inventory loss, LSL >> refactoring, build system refactoring, or whatever else engineering >> is working on. (Contrary to belief, not everyone is working on >> "flashy new features" no matter how often people repeat that meme >> with no actual internal information.) It's also more difficult than >> your average task, because you're essentially developing an API, >> which you Better Not Screw Up. > > Well, thing is, it could be done in parallel with everything else if > the APIs were properly documented (those who have ears, let them > hear...). > I meant "if the *protocols* were documented properly," not the API. The API in the viewercan change quite drastically as long as the protocols are the same (look at libsl). Problem is, without well-documented protocols that are independent of the implementation, we're left with the buggy un-re-factored client as the de facto protocol doc, which kinda makes it impossible to refactor the client efficiently. > L. From aimee at ama-zing.co.uk Thu Apr 10 10:10:20 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Apr 10 10:10:30 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080410172044.5cb31e9b.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> Message-ID: <02788528-5034-4D1C-B3CD-8104D3BE19B9@ama-zing.co.uk> On Apr 10, 2008, at 16:20, Henri Beauchamp wrote: > On Thu, 10 Apr 2008 10:47:07 +0000, Matthew Dowd wrote: > >> ii) that the new scheme far from being "more accessible and >> pleasing", actually causes eye strain. This is also captured >> in jira, had anyone from the UI team bothered to check, as >> https://jira.secondlife.com/browse/VWR-5080 , and in there one >> of the comments provides medical and documentary evidence why >> the scheme chosen by LL is a potential health risk and >> accessibility problem! > > Frankly, I am curious to see any "evidence" about the health > issue, but I agree wholeheartedly that beside being distracting > to the eye, Dazzle's UI is definitely going against accessibility > basics. http://www.fast-consulting.com/color/cp_toc.htm http://books.google.co.uk/books?id=4WxYmAzo9uYC My full comments on the issue, as posted on VWR-5080, are attached below, sorry, they're a bit long. This should really be old hat to anyone that's studied HCI to even a basic level, which I know people on the UI team are well beyond in qualifications, so it is puzzling how it ever got this far. I think the trouble is, no disrespect intended, they have come from web and desktop application design, and what works well in those paradigms isn't directly applicable in a virtual world environment without some careful reinterpretation of the relationships between elements. Aimee. Aimee Trescothick - 08/Mar/08 06:02 PM > > I've been meaning to get to Ben's office hours but haven't been > able to make it yet, so I'll document this stuff here and try and > follow up in person later. > > Beyond very mild myopia I have no vision problems, however I for > one can't use Dazzle at all without getting headaches, and I'm told > I'm not alone. The health issues that must be considered when > designing user interfaces are nothing new and are well documented. > People have been studying this stuff since at least the 1950s, and > while computer interfaces may have evolved the human vision system > has not. > > There are two main issues here, the chosen colour combinations, and > the contrast between the world environment and the user interface. > > 1) Colour Selection > > It is well known that blue text on a blue background is hard to > read and causes eyestrain. Just do a Google search for "blue text > on a blue background" if you don't believe me. This is in fact a > commonly exploited trick for hiding the small print on contracts, > relying on the fact that the human eye focuses blue in front of the > retina rather than on its surface, causing blue to fade into the > background. Where the existing interface does use blue text, it's > counterbalanced with a black or grey background of sufficient > contrast for it not to be a big problem. > > 2) Environmental Contrast > > This is the big one, and also well documented; there is however a > trip-wire here when designing virtual world interfaces. The > literature talks about two types of contrast firstly between the > screen and the room, and secondly between the user interface > elements, windows etc. and the screen background. However in a > virtual world the priority is reversed; the primary focus is the > world environment, the UI windows are the background information > even though they sit on top of it. During Second Life night time, > it makes sense to reduce the light level in your room to prevent > eyestrain, however with Dazzle this now makes it worse. While > looking at in world content the eye is prevented from adapting to > the light level of what you are focusing on by the bright UI > elements in your peripheral vision. In some ways a greater analogue > exists with something like car instrumentation, rather than with > existing computer UIs; most car manufacturers now provide a dimmer > to allow the driver to adjust the dashboard illumination both for > comfort and so as not to affect their night vision. > > This is not just aesthetics, there are definite QA issues here that > need to be addressed in an objective fashion, rather that just > asking "does it look cool?" (personally I think the look of Dazzle > is somewhere about 1995). When assessing a user interface you need > to see it from the point of view of the user. While the designers > are probably sat in a typical office environment with light levels > in excess of 500-1000 lux, the majority of users are sat at home > with typical light levels around 50-100 lux. Go in to the office at > night, turn the lights off and then see how comfortable it is to use. > > While the existing colour scheme may not be considered particularly > exciting or "cool", it is in fact pretty good from a health point > of view, especially for those of us that work in world for extended > periods and during RL night. Its neutral colour scheme ensures a > safe contrast level during both SL day and night. I can understand > the fact that the Second Life viewer is seen as a product and there > is a perceived need to connect with new users, using a bright > engaging UI as a hook, but that's no good when your retention rate > drops due to increased levels of user fatigue. The fact is the > product is the world itself, a bright and busy UI will just detract > from that. > > There is a tendency among UI designers generally to think it's all > about the UI elements and making them look great and eye-catching > (it's all right there in the name - Dazzle), I'm sorry, but that's > just plain wrong. A UI should be as seamless and transparent to the > user as possible, it is the background to the content, not the > other way round. The way forward is to provide a user interface > that adapts and grows with the user, providing more visible obvious > help and hand-holding to the new user while fading into the > background for the experienced resident, allowing the large buttons > with text across the bottom to be reduced to an icon palette in the > corner for example, and first and foremost to allow the user to > choose a colour scheme that suits them and their local environment. > > I didn't set out to write an academic paper on ergonomics and > virtual environments (though if someone wants to give me a research > grant ... :) If you've read this far, I'm impressed, if you go and > read the references at the end, I'll be even more impressed :) I > don't want to be a fly in the ointment, I'm not writing this to be > obstructive, Please don't dismiss this as another "Linden Lab never > get anything right" or "I'm afraid of change" rant. I am > enthusiastic and passionate about Second Life and it's future, I > can see that there is a recognition of past mistakes and a desire > to change things for the better within the Lab, and I am > contributing this to help, not hinder. > > Most things that come up on JIRA are bugs and irritations that in > the grand scheme of things don't really matter (not to belittle > anyone's pet issue ;) but this is about peoples health. I'm not > saying my opinion means any more than anyone else's, but many > people are going to be blind to the potential consequences of > getting this wrong, and will just look at Dazzle and go "Ooooh, > shiny, me like!", then wonder why they're getting more migraines > than they used to without making the connection. > > > References > > http://www.fast-consulting.com/color/cp_toc.htm If you read nothing > else, read this. Lots of useful information and a comprehensive > list of references. > > Ergonomics in Computerized Offices By E. Grandjean published by CRC > Press. Latest edition is I think 2002, but there's a preview of the > 1987 edition online at http://books.google.co.uk/books? > id=4WxYmAzo9uYC&printsec=frontcover From aimee at ama-zing.co.uk Thu Apr 10 10:20:56 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Apr 10 10:21:04 2008 Subject: [sldev] How to search for issues in JIRA? In-Reply-To: <47FE3A20.8060507@gmail.com> References: <47FE1FE9.4050504@gmail.com> <47FE3A20.8060507@gmail.com> Message-ID: <2EF563BF-0058-4DE6-B00E-1110D1B4CEB5@ama-zing.co.uk> On Apr 10, 2008, at 17:02, Zak Escher wrote: > Actually I made a typo in my email. I meant 1.20. > > I think I have found what I was not doing correctly in the jira > searches. I was specifying the version in "Fix For" and not > "Affects Versions." Once I made that filter change, I seem to get > the list of issues Ah, you may also have missed seeing it if you were searching for unresolved issues, because I had already spotted it as a duplicate and resolved it, sorry! :) A quicker way to find you own recent issues is to just look at the bottom right corner of the JIRA home page, there's a summary named "Issues: Updated issues I've reported" there. Aimee. From secret.argent at gmail.com Thu Apr 10 10:37:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Apr 10 10:37:14 2008 Subject: [sldev] Comments on Harold's "Retro Dazzle" theme In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> Message-ID: <23A24D89-374A-4FD8-9A22-5AB27B1F5F43@gmail.com> On 2008-04-10, at 10:55, Harold Brown wrote: > Yes I hate the Dazzle UI, Yes I posted my dislike when it was first > shown, and when the Firstlook Came out. But the difference is I > didn't bitch about how LL didn't listen to me. I made a Retro Dazzle > skin with the classic UI colors and darker Dazzle interface images. It's nice, I like it. It makes Dazzle usable. I would like to suggest going back to the old map icons, and even back two generations in the menu bar icons. There's an ongoing undercurrent of dissent over Apple's decision to encapsulate the buttons in Apple Mail on Tiger, and there's a couple of applications available to revert to the old un-encapsulated icons. The reason is that encapsulating might look better, superficially, but it makes the icons harder to use and recognize by reducing the contrast between them. The encapsulated map icons have similar problems. From labrat.hb at gmail.com Thu Apr 10 10:48:25 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Apr 10 10:48:33 2008 Subject: [sldev] Comments on Harold's "Retro Dazzle" theme In-Reply-To: <23A24D89-374A-4FD8-9A22-5AB27B1F5F43@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <23A24D89-374A-4FD8-9A22-5AB27B1F5F43@gmail.com> Message-ID: If you can tell me which artwork package those menu bar icons were in. I can probably do something for it. On Thu, Apr 10, 2008 at 10:37 AM, Argent Stonecutter wrote: > On 2008-04-10, at 10:55, Harold Brown wrote: > > Yes I hate the Dazzle UI, Yes I posted my dislike when it was first > > shown, and when the Firstlook Came out. But the difference is I > > didn't bitch about how LL didn't listen to me. I made a Retro Dazzle > > skin with the classic UI colors and darker Dazzle interface images. > > > > It's nice, I like it. It makes Dazzle usable. > > I would like to suggest going back to the old map icons, and even back two > generations in the menu bar icons. There's an ongoing undercurrent of > dissent over Apple's decision to encapsulate the buttons in Apple Mail on > Tiger, and there's a couple of applications available to revert to the old > un-encapsulated icons. The reason is that encapsulating might look better, > superficially, but it makes the icons harder to use and recognize by > reducing the contrast between them. > > The encapsulated map icons have similar problems. > > From kfa at gmx.net Thu Apr 10 11:22:40 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Thu Apr 10 11:22:54 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080410172044.5cb31e9b.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> Message-ID: <47FE5AF0.6080109@gmx.net> Henri Beauchamp wrote: > I already gave up submitting bug reports to the JIRA as this proved > to be a total loss of time and energy. > I vote that some people are not allowed posting there anyway without a patch attached. Especially those that claim they're so good that by the time they spent ranting they could have squashed a few bugs. How come we have any open issues at all then. > > > Matthew... would you marry me ? > > Ok, we are that tolerant nowadays. As long as we're not forced to watch. Not sure what's the point of adding /my/ 2 cents here, better don't read on if you're pressed for time. But I feel compelled to say that I am disappointed. Can't we be a bit more civilized and behave like adults. We programmers are a proud bunch, that much is known. We squirm when we have to read someone else's code - how dare this guy writing things any other way than I would do. And often it takes a deliberate, conscious effort to accept that a large project which has grown over years looks more like an oriental bazaar than a shiny new shopping center that has been planned and built in one go. Also to accept that the originator of such a project may have different views about its future or its current priorities than you or I happen to have in this moment of time. (That's why they've given us the voting thingy.) This project has been open sourced perhaps not without the reasoning that it's grown bigger than the company that created it. Don't we all wish that Microsoft would do such a thing! Well, no harm done here since the viewer itself never was a package with a price tag. Still, that it's out in the open now doesn't mean that we own it. It is Philip's baby that we're invited to help improve, not to just take from him. Nor do we own the people who are still nurturing it, as if they were to jump upon a bark from somewhere in the rear rows. But what irks me the most is how a list that is meant for technical stuff gets hijacked by politics and poorly managed emotions. Sure I've been griping, too, because the Lindens didn't provide a build file that fits my new rig as opposed to their tried and trusted workhorse. And I asked some questions that were dumb (won't be the last time either). But I never set out to deliberately annoy everybody who reads here just to push my point across. And I wish I won't have to endure such an outburst again. I had a good portion of respect for some names I've seen around for a long time, but I think that's gotten a dent. And since you've read thus far... this 3D world is way too flat for me! I want the z limit removed altogether, and a physics engine whose gravitation behaviour can be tweaked so that we can build space stations and asteroids and entire planets! And a box of chocolates every week, hand signed by the Lindens. Cheers, Felix (who likes shopping in a bazaar much better) From tinacloud at gmx.de Thu Apr 10 11:25:43 2008 From: tinacloud at gmx.de (Zi Ree) Date: Thu Apr 10 11:26:01 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FD2C76.2060101@lindenlab.com> Message-ID: <200804102025.44749.tinacloud@gmx.de> Am Donnerstag 10 April 2008 schrieb Harold Brown: > http://www.rpgstats.com/SL/Dazzle-Retro.zip - Contains the custom > colors.xml file and darker images Excellent work, Harold! This makes the viewer at least remotely usable again. There are still a few colors missing. Are you still working on it? Because the IM/Local Chat background is dark blue, not black, and some of the Tab colors could be tweaked as well. But anyway, this was great work! Thank you very much for this adaption! Zi From matthew.dowd at hotmail.co.uk Thu Apr 10 11:31:58 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 10 11:32:00 2008 Subject: [sldev] ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: As subject! _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/401372f3/attachment.htm From sldev at free.fr Thu Apr 10 11:35:52 2008 From: sldev at free.fr (Henri Beauchamp) Date: Thu Apr 10 11:35:56 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <47FE5AF0.6080109@gmx.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> Message-ID: <20080410203552.22e899b0.sldev@free.fr> On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > Henri Beauchamp wrote: > > I already gave up submitting bug reports to the JIRA as this proved > > to be a total loss of time and energy. > > > > I vote that some people are not allowed posting there anyway without a > patch attached. Especially those that claim they're so good that by the > time they spent ranting they could have squashed a few bugs. How come we > have any open issues at all then. Be happy: http://sldev.free.fr/ I do not only criticize, I also contribute. All my patches were also submitted to the JIRA.... with little to no result. Have a nice day. From soft at lindenlab.com Thu Apr 10 11:44:12 2008 From: soft at lindenlab.com (Soft) Date: Thu Apr 10 11:44:14 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd wrote: > > As subject! I'm working out a handful of issues right now, but hopefully today. You can build something very close at current by using the existing 1.20 drop in svn and disabling the 3Dconnexion add-on. From matthew.dowd at hotmail.co.uk Thu Apr 10 12:02:41 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 10 12:02:43 2008 Subject: [sldev] RE: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: There are some addition libboost dependencies not in the 1.19 libraries archive which is preventing the build, and I was hoping not to have to download and compile boost from scratch. Matthew> Date: Thu, 10 Apr 2008 13:44:12 -0500> From: soft@lindenlab.com> To: matthew.dowd@hotmail.co.uk> Subject: Re: ETA for 1.20 source and supporting archives on the wiki?> CC: sldev@lists.secondlife.com> > On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd> wrote:> >> > As subject!> > I'm working out a handful of issues right now, but hopefully today.> You can build something very close at current by using the existing> 1.20 drop in svn and disabling the 3Dconnexion add-on. _________________________________________________________________ Amazing prizes every hour with Live Search Big Snap http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/793cc782/attachment.htm From johnniecarling at gmail.com Thu Apr 10 12:07:48 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu Apr 10 12:07:33 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <47FE5AF0.6080109@gmx.net> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> Message-ID: <200804101507.49165.johnniecarling@gmail.com> On Thursday 10 April 2008 02:22:40 pm Felix Duesenburg wrote: > This project has been open sourced perhaps not without the reasoning > that it's grown bigger than the company that created it. Don't we all > wish that Microsoft would do such a thing! Well, no harm done here since > the viewer itself never was a package with a price tag. Still, that it's > out in the open now doesn't mean that we own it. It is Philip's baby > that we're invited to help improve, not to just take from him. Nor do we > own the people who are still nurturing it, as if they were to jump upon > a bark from somewhere in the rear rows. Well said, but I'd like to make a correction. IMHO the "project" is not opensourced, the SL viewer code is open sourced, that's a big difference. Like you said SL is LL's baby, they have their own internal SVN, internal roadmaps, internal ideas for the future, etc.. If somebody wants an opensourced project, a sourceforge account is free ;) Personally I'd love to see an staroffice, openoffice.org type of relationship, but that's just me. Johnnie Carling From matthew.dowd at hotmail.co.uk Thu Apr 10 12:28:52 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 10 12:28:55 2008 Subject: [sldev] RE: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: Mmmm, intriguing - there is a binary installer for Windows but boost.org doesn't mention it anywhere so you end up finding the link for it by downloading the source, and reading the installation instructions.... Matthew From: matthew.dowd@hotmail.co.ukTo: soft@lindenlab.comDate: Thu, 10 Apr 2008 19:02:41 +0000CC: sldev@lists.secondlife.comSubject: [sldev] RE: ETA for 1.20 source and supporting archives on the wiki? There are some addition libboost dependencies not in the 1.19 libraries archive which is preventing the build, and I was hoping not to have to download and compile boost from scratch. Matthew> Date: Thu, 10 Apr 2008 13:44:12 -0500> From: soft@lindenlab.com> To: matthew.dowd@hotmail.co.uk> Subject: Re: ETA for 1.20 source and supporting archives on the wiki?> CC: sldev@lists.secondlife.com> > On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd> wrote:> >> > As subject!> > I'm working out a handful of issues right now, but hopefully today.> You can build something very close at current by using the existing> 1.20 drop in svn and disabling the 3Dconnexion add-on. Try Messenger on your mobile. Text MSN to 63463 Now. _________________________________________________________________ Amazing prizes every hour with Live Search Big Snap http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/534ed252/attachment.htm From whitequill.bj at gmail.com Thu Apr 10 13:34:51 2008 From: whitequill.bj at gmail.com (Bj Raz) Date: Thu Apr 10 13:35:00 2008 Subject: [sldev] Re: Dazzle / Windlight merge? In-Reply-To: <6065A193-F735-4ABB-900A-3F61F7C84159@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <6065A193-F735-4ABB-900A-3F61F7C84159@gmail.com> Message-ID: I heartily agree with the removal of the 768 meter limitation. I put a sky box above this limit and I can't TP into it. LMs don't work either for me. I ended up writing a script and using an object on the ground to get into my Home in the sky. On Wed, Apr 9, 2008 at 6:30 AM, Argent Stonecutter wrote: > On 2008-04-09, at 00:46, Ramzi wrote: > > > W/r/t optional viewers -- I can say that Linden Lab heard great Resident > > feedback recently about the advantages to having 2 supported viewer versions > > available whenever possible. Listening to that feedback is what led to > > making 1.19.0.5 the minimum version /only after/ 1.19.1 was released > > about a week ago. > > > > The problem is that 1.19.* will not support building over 768 meters, and > has related problems (for example it truncates home position and teleport > destinations from landmarks to 768 meters), so whether 1.20 is "optional" or > not, it will be necessary once people start taking advantage of Havok for > building. > > If Dazzle is going to be in 1.20, then please, could we have one more 1.19 > release with the 768 meter limitation removed? > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/0a8d4380/attachment.htm From tom at streamsense.net Thu Apr 10 13:41:35 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 10 13:42:01 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista Message-ID: <47FE7B7F.9040903@streamsense.net> Hi folks, I am having terrible trouble with the new 1.20 RC, the client seems to absolutely destabilise my nvidia drivers. First of all i see small freezes, then these freezes start becoming more pronounced, and then the screen starts blanking once every 10 seconds (with the vista "the display driver stopped responding and has recovered" notice).. and then this happens every 5 seconds.. and then the system hangs. I'm using the 1.19.1 client with total stability and no display driver issues (as well as other games i've tried to make sure it's not my system at fault). Has anyone else experienced anything of this nature? Here's my environment: CPU: AMD (Athlon XP X2 5000+) (2611 MHz) Memory: 3071 MB OS Version: Microsoft Windows Vista (Build 6000) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 8800 GTX/PCI/SSE2/3DNOW! I'm also using the latest nVidia drivers (i was using older drivers, and upgraded to see if it fixed the problem, it did not.) Cheers Tom From soft at lindenlab.com Thu Apr 10 15:24:23 2008 From: soft at lindenlab.com (Soft) Date: Thu Apr 10 15:24:28 2008 Subject: [sldev] VWR-2765 Mozilla libraries interfer with memory types tracking (Client => Consoles => Memory) Message-ID: I don't have the bandwidth to look into this, but it came up in today's open source meeting and looked important, so I thought I'd try bouncing one off the list: http://jira.secondlife.com/browse/VWR-2765 VWR-2765 Mozilla libraries interfer with memory types tracking (Client => Consoles => Memory) >From the description, I'm guessing we're overloading new and delete in the preprocessor if some #defines are set, and then we're including some headers that are also included when building llmozlib2. The result would be that we have some objects being created with one new/delete scheme, and freed with another. Anyone want to verify that this is what's happened? If so, is it as simple as moving some functions using new/delete out of headers, or is the solution more disgusting? From greg at lindenlab.com Thu Apr 10 15:40:40 2008 From: greg at lindenlab.com (Greg Tomko-Pavia (Periapse)) Date: Thu Apr 10 15:40:42 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FE7B7F.9040903@streamsense.net> References: <47FE7B7F.9040903@streamsense.net> Message-ID: <47FE9768.8050808@lindenlab.com> Yes, it does appear that there is a problem with the 1.20.0 rc and some nvidia drivers. It was discovered earlier today as the Crash Hunters team took a look at the early data from the crash reporter for 1.20 and found a new and disturbing spike. All the crashes occur in the driver dll itself, so we don't get any useful stack information on it. At this point we do not have a repro for the bug, so our best hope for finding information on it is going to come from resident JIRA submissions. Thomas, can you please file a JIRA and include a logfile from a session that crashed? Thx, --Per Thomas Grimshaw wrote: > Hi folks, > > I am having terrible trouble with the new 1.20 RC, the client seems to > absolutely destabilise my nvidia drivers. > > First of all i see small freezes, then these freezes start becoming > more pronounced, and then the screen starts blanking once every 10 > seconds (with the vista "the display driver stopped responding and has > recovered" notice).. and then this happens every 5 seconds.. and then > the system hangs. > > I'm using the 1.19.1 client with total stability and no display driver > issues (as well as other games i've tried to make sure it's not my > system at fault). > > Has anyone else experienced anything of this nature? > > Here's my environment: > > CPU: AMD (Athlon XP X2 5000+) (2611 MHz) > Memory: 3071 MB > OS Version: Microsoft Windows Vista (Build 6000) > Graphics Card Vendor: NVIDIA Corporation > Graphics Card: GeForce 8800 GTX/PCI/SSE2/3DNOW! > > I'm also using the latest nVidia drivers (i was using older drivers, > and upgraded to see if it fixed the problem, it did not.) > > Cheers > > Tom > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080410/a622cf0e/signature.pgp From tom at streamsense.net Thu Apr 10 15:42:42 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 10 15:43:06 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FE9768.8050808@lindenlab.com> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com> Message-ID: <47FE97E2.8030403@streamsense.net> Greg Tomko-Pavia (Periapse) wrote: > Yes, it does appear that there is a problem with the 1.20.0 rc and some > nvidia drivers. It was discovered earlier today as the Crash Hunters > team took a look at the early data from the crash reporter for 1.20 and > found a new and disturbing spike. All the crashes occur in the driver > dll itself, so we don't get any useful stack information on it. At this > point we do not have a repro for the bug, so our best hope for finding > information on it is going to come from resident JIRA submissions. > Thomas, can you please file a JIRA and include a logfile from a session > that crashed? > Thx, > --Per Yes, I will of course file a Jira. Some early information which might be of help to you though, disabling atmospheric shaders seems to help the issue immensely (still unstable though). ~Tom From ed at anuff.com Thu Apr 10 15:50:15 2008 From: ed at anuff.com (Ed Anuff) Date: Thu Apr 10 15:50:17 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista Message-ID: Seeing the same thing, also with an 8800GTX, post the jira # here once you open it. On Thu, Apr 10, 2008 at 3:43 PM, wrote: > > Thomas Grimshaw wrote: > > Hi folks, > > > > I am having terrible trouble with the new 1.20 RC, the client seems to > > absolutely destabilise my nvidia drivers. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/2c73489f/attachment.htm From tom at streamsense.net Thu Apr 10 16:14:57 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 10 16:15:24 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: References: Message-ID: <47FE9F71.9050001@streamsense.net> Ed Anuff wrote: > Seeing the same thing, also with an 8800GTX, post the jira # here once > you open it. ... I would but it seems the Jira site is proactively rejecting my login... of all my characters. If someone else can file for this issue, please do From periapse at lindenlab.com Thu Apr 10 16:28:48 2008 From: periapse at lindenlab.com (Periapse Linden) Date: Thu Apr 10 16:28:52 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FE9F71.9050001@streamsense.net> References: <47FE9F71.9050001@streamsense.net> Message-ID: <47FEA2B0.1070109@lindenlab.com> It's not you, Thomas. I couldn't log in to JIRA either. I've notified web and they are working on the problem. The JIRA is hosted by an external provider, so we may have to contact them. Thomas Grimshaw wrote: > Ed Anuff wrote: >> Seeing the same thing, also with an 8800GTX, post the jira # here >> once you open it. > ... I would but it seems the Jira site is proactively rejecting my > login... of all my characters. > > If someone else can file for this issue, please do > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tom at streamsense.net Thu Apr 10 16:29:59 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 10 16:30:22 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FEA2B0.1070109@lindenlab.com> References: <47FE9F71.9050001@streamsense.net> <47FEA2B0.1070109@lindenlab.com> Message-ID: <47FEA2F7.2050904@streamsense.net> Periapse Linden wrote: > The JIRA is hosted by an > external provider Hmm.. not to sound overly paranoid, but does this mean this external provider also has every users' login details? Tom From periapse at lindenlab.com Thu Apr 10 16:32:41 2008 From: periapse at lindenlab.com (Periapse Linden) Date: Thu Apr 10 16:32:44 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FEA2F7.2050904@streamsense.net> References: <47FE9F71.9050001@streamsense.net> <47FEA2B0.1070109@lindenlab.com> <47FEA2F7.2050904@streamsense.net> Message-ID: <47FEA399.9090407@lindenlab.com> No! Definitely not. We have an authentication server behind our firewall that handles login. In fact, that server was the problem. It's now fixed and I was able to log in to JIRA. Thomas Grimshaw wrote: > Periapse Linden wrote: >> The JIRA is hosted by an >> external provider > Hmm.. not to sound overly paranoid, but does this mean this external > provider also has every users' login details? > > Tom From tom at streamsense.net Thu Apr 10 16:58:16 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 10 16:58:49 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FE9768.8050808@lindenlab.com> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com> Message-ID: <47FEA998.2080308@streamsense.net> http://jira.secondlife.com/browse/VWR-6343 Jira for this issue. From soft at lindenlab.com Thu Apr 10 17:07:33 2008 From: soft at lindenlab.com (Soft) Date: Thu Apr 10 17:07:50 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FEA998.2080308@streamsense.net> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com> <47FEA998.2080308@streamsense.net> Message-ID: On Thu, Apr 10, 2008 at 6:58 PM, Thomas Grimshaw wrote: > http://jira.secondlife.com/browse/VWR-6343 > > Jira for this issue. This is probably related. From our favorite Solaris developer: You might want to pass the following to the internal developers. It looks like LLRenderPass::pushBatch() may be sending corrupt/bad data to the GL library. On Solaris, we're using Nvidia's GL library and that basically a recomiple from their Linux drivers so I don't think the crash I'm encountering is local to Solaris. In any case, once I get logged in, the viewer immediately tips over. Here's the tail end of the log: 2008-04-10T12:42:00Z WARNING: dispatch: Ignoring unknown message EstablishAgentCommunication 2008-04-10T12:42:03Z INFO: setStartupState: Startup state changing from STATE_PRECACHE to STATE_WEARABLES_WAIT 2008-04-10T12:42:03Z INFO: setStartupState: Startup state changing from STATE_WEARABLES_WAIT to STATE_CLEANUP 2008-04-10T12:42:04Z INFO: setStartupState: Startup state changing from STATE_CLEANUP to STATE_STARTED 2008-04-10T12:42:04Z INFO: idle_startup: Doing first audio_update_volume... 2008-04-10T12:42:04Z INFO: idle_startup: Done first audio_update_volume. 2008-04-10T12:42:04Z INFO: updateGeometry: WL Skydome strips in 26 batches. Program received signal SIGSEGV, Segmentation fault. Here's the stack trace: 0xfd0c1760 in _nv001457gl () from /usr/lib/libGLcore.so.1 (gdb) where #0 0xfd0c1760 in _nv001457gl () from /usr/lib/libGLcore.so.1 #1 0xfd13cfbe in _nv001457gl () from /usr/lib/libGLcore.so.1 #2 0x00000008 in ?? () #3 0x00000441 in ?? () #4 0x00030101 in ?? () #5 0x0c7eaea0 in ?? () #6 0x41e756f5 in ?? () #7 0x3e6ac6f6 in ?? () #8 0xfd0c1740 in _nv001457gl () from /usr/lib/libGLcore.so.1 . . . #167 0x085291e4 in LLRenderPass::pushBatch (this=Cannot access memory at address 0x449 ) at ... /newview/lldrawpool.cpp:440 Previous frame inner to this frame (corrupt stack?) Since I don't have the source for libGL I'm stuck here. From brad at lindenlab.com Thu Apr 10 17:38:06 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Thu Apr 10 17:36:21 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FE97E2.8030403@streamsense.net> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com> <47FE97E2.8030403@streamsense.net> Message-ID: <47FEB2EE.8040406@lindenlab.com> Thomas Grimshaw wrote: > Yes, I will of course file a Jira. Some early information which might > be of help to you though, disabling atmospheric shaders seems to help > the issue immensely (still unstable though). > The atmospheric shaders bit is Interesting, I'd be curious to hear how the behavior interacts with the Enable VBOs checkbox on the hardware settings menu, and the RenderMaxVBO debug setting (from the Advanced menu -> Debug Settings...). -Brad From dahliatrimble at gmail.com Thu Apr 10 19:48:51 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Apr 10 19:48:53 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: There is a reason blue text is hard to see: the human retina has far fewer of the blue light sensitive cone cells than for red or green light. Younger people with excellent vision may not have difficulty using the Dazzle UI with the blue text, but older people or those with compromised vision won't find it as easy. Personally I find it quite difficult to read text with the Dazzle UI so I dont use it. I hope when it ships that more thought has gone into the UI design and that changing it to allow for comfortable use is not too difficult. I wouldnt want to go through the process of googling for third party fixes and jumping through hoops every time a new viewer is released just so I can read the text it displays. On Tue, Apr 8, 2008 at 9:54 AM, Argent Stonecutter wrote: > On 2008-04-08, at 10:00, Tofu Linden wrote: > > > In this case, because 1.20 is due out Real Soon Now and has Dazzle, > > Windlight and lots more. :) > > > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080410/54f312d4/attachment.htm From davep at lindenlab.com Thu Apr 10 19:50:58 2008 From: davep at lindenlab.com (Dave Parks) Date: Thu Apr 10 19:51:01 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FEB2EE.8040406@lindenlab.com> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com><47FE97E2.8030403@streamsense.net> <47FEB2EE.8040406@lindenlab.com> Message-ID: <47FED212.9070707@lindenlab.com> I think this is being caused by the extra impostor updates that are happening in 1.20. Unstable render pipe + more passes through the pipe = more crashes. Try disabling avatar impostors and see if that helps. It looks like some part of the render pipe is leaving a vertex data stream enabled for reading, and subsequent calls occasionally read off the end of the stream. I have work in an internal branch (maint-render) that protects vertex data streams using LLVertexBuffer (removes willy nilly calls to glEnable/DisableClientState, glClientActiveTexture, and glDrawRangeElements). Time will tell if this is the culprit. Moving forward, we'll be looking at removing all GL dependencies from the newview project and creating an API agnostic interface to the graphics card. This is an early step in that direction, hot on the heels of the use of gGL.begin/gGL.end vs. glBegin/glEnd. Brad Kittenbrink (Brad Linden) wrote: > Thomas Grimshaw wrote: >> Yes, I will of course file a Jira. Some early information which might >> be of help to you though, disabling atmospheric shaders seems to help >> the issue immensely (still unstable though). >> > The atmospheric shaders bit is Interesting, I'd be curious to hear how > the behavior interacts with the Enable VBOs checkbox on the hardware > settings menu, and the RenderMaxVBO debug setting (from the Advanced > menu -> Debug Settings...). > > -Brad > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tateru.nino at gmail.com Thu Apr 10 22:42:31 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Apr 10 22:47:20 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> Message-ID: <47FEFA47.5090302@gmail.com> Wait a second. It's BLUE? I thought it was shades of silver. Maybe I need my eyes checked up again. They've seen better days. Dahlia Trimble wrote: > There is a reason blue text is hard to see: the human retina has far > fewer of the blue light sensitive cone cells than for red or green > light. Younger people with excellent vision may not have difficulty > using the Dazzle UI with the blue text, but older people or those with > compromised vision won't find it as easy. Personally I find it quite > difficult to read text with the Dazzle UI so I dont use it. I hope > when it ships that more thought has gone into the UI design and that > changing it to allow for comfortable use is not too difficult. I > wouldnt want to go through the process of googling for third party > fixes and jumping through hoops every time a new viewer is released > just so I can read the text it displays. > > On Tue, Apr 8, 2008 at 9:54 AM, Argent Stonecutter > > wrote: > > On 2008-04-08, at 10:00, Tofu Linden wrote: > > In this case, because 1.20 is due out Real Soon Now and has > Dazzle, > Windlight and lots more. :) > > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > Because I find Dazzle physically painful to use. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dahliatrimble at gmail.com Fri Apr 11 00:15:28 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Apr 11 00:15:33 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: <47FEFA47.5090302@gmail.com> References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FEFA47.5090302@gmail.com> Message-ID: Oops maybe I need to get my memory checked? I tried Dazzle when the first "first look" came out for it, and I remember I liked the graphics rendering but the user interface was painfully bright, distracting, and quite difficult to read, and because of that I hadn't used it since. My comment was based that memory and on reading prior comments that mentioned cyan and blue, so I may have confused the colors. My apologies for the error. On Thu, Apr 10, 2008 at 10:42 PM, Tateru Nino wrote: > Wait a second. It's BLUE? > > I thought it was shades of silver. Maybe I need my eyes checked up again. > They've seen better days. > > Dahlia Trimble wrote: > > > There is a reason blue text is hard to see: the human retina has far > > fewer of the blue light sensitive cone cells than for red or green light. > > Younger people with excellent vision may not have difficulty using the > > Dazzle UI with the blue text, but older people or those with compromised > > vision won't find it as easy. Personally I find it quite difficult to read > > text with the Dazzle UI so I dont use it. I hope when it ships that more > > thought has gone into the UI design and that changing it to allow for > > comfortable use is not too difficult. I wouldnt want to go through the > > process of googling for third party fixes and jumping through hoops every > > time a new viewer is released just so I can read the text it displays. > > > > On Tue, Apr 8, 2008 at 9:54 AM, Argent Stonecutter < > > secret.argent@gmail.com > wrote: > > > > On 2008-04-08, at 10:00, Tofu Linden wrote: > > > > In this case, because 1.20 is due out Real Soon Now and has > > Dazzle, > > Windlight and lots more. :) > > > > > > Is the Dazzle bright color scheme going to be mandatory to get 1.20? > > > > Because I find Dazzle physically painful to use. > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080411/1a65a90b/attachment.htm From tateru.nino at gmail.com Fri Apr 11 00:23:18 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Apr 11 00:28:05 2008 Subject: [sldev] Dazzle / Windlight merge? In-Reply-To: References: <47FB64E1.7060703@streamsense.net> <47FB887C.4010709@lindenlab.com> <64DFF780-D995-46EB-8D69-C8B67B046F56@gmail.com> <47FEFA47.5090302@gmail.com> Message-ID: <47FF11E6.80509@gmail.com> No - you're right. It _is_ blue. As it turns out I have to concentrate to tell that. Plus, I keep squinting. Dahlia Trimble wrote: > Oops maybe I need to get my memory checked? I tried Dazzle when the > first "first look" came out for it, and I remember I liked the > graphics rendering but the user interface was painfully bright, > distracting, and quite difficult to read, and because of that I hadn't > used it since. My comment was based that memory and on reading prior > comments that mentioned cyan and blue, so I may have confused the > colors. My apologies for the error. > > > > On Thu, Apr 10, 2008 at 10:42 PM, Tateru Nino > wrote: > > Wait a second. It's BLUE? > > I thought it was shades of silver. Maybe I need my eyes checked up > again. They've seen better days. > > Dahlia Trimble wrote: > > There is a reason blue text is hard to see: the human retina > has far fewer of the blue light sensitive cone cells than for > red or green light. Younger people with excellent vision may > not have difficulty using the Dazzle UI with the blue text, > but older people or those with compromised vision won't find > it as easy. Personally I find it quite difficult to read text > with the Dazzle UI so I dont use it. I hope when it ships that > more thought has gone into the UI design and that changing it > to allow for comfortable use is not too difficult. I wouldnt > want to go through the process of googling for third party > fixes and jumping through hoops every time a new viewer is > released just so I can read the text it displays. > > On Tue, Apr 8, 2008 at 9:54 AM, Argent Stonecutter > > >> wrote: > > On 2008-04-08, at 10:00, Tofu Linden wrote: > > In this case, because 1.20 is due out Real Soon Now and has > Dazzle, > Windlight and lots more. :) > > > Is the Dazzle bright color scheme going to be mandatory to > get 1.20? > > Because I find Dazzle physically painful to use. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From seg at haxxed.com Fri Apr 11 02:27:18 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 11 02:29:20 2008 Subject: [sldev] LL: Most major projects done? Time to return to haptics :-) In-Reply-To: References: Message-ID: <1207906038.12371.1.camel@localhost.localdomain> On Tue, 2008-04-08 at 03:19 -0500, Dale Mahalko wrote: > Poor LL may be running out of incredibly huge and ambitious things to > occupy their time with these majors out of the way. So let me make a > small suggestion for your next big project. :-) > I see this exosuit concept as possibly the ultimate virtual reality > haptics interface, if it were reimplemented in a different way for a > completely different purpose. Rather than using it to lift physical > objects, the exosuit could become the ultimate haptics interface. > to match (or map to) your physical facial expressions. And I want a pony. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080411/84d2c21b/attachment.pgp From sempuki1 at gmail.com Fri Apr 11 02:42:38 2008 From: sempuki1 at gmail.com (Ryan McDougall) Date: Fri Apr 11 02:43:11 2008 Subject: [sldev] vivox.com hard-coded in viewer? Message-ID: <1207906958.22021.53.camel@localhost.localdomain> Hello, I am running the SL viewer on opensim, and I have set the accout management server and sip domain caps in open sim. However I still get a vivox.com URI sent to me. If it is hard-coded, is it possible to treat this as a bug, and have it fixed? Cheers, From matthew.dowd at hotmail.co.uk Fri Apr 11 03:10:09 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Apr 11 03:10:11 2008 Subject: [sldev] RE: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: No joy I'm afraid - I've install what I think is the right version of boost - it all compiles and links but when I run it on the first call to the boost signal library it bombs out with a memory violation... Matthew> Date: Thu, 10 Apr 2008 13:44:12 -0500> From: soft@lindenlab.com> To: matthew.dowd@hotmail.co.uk> Subject: Re: ETA for 1.20 source and supporting archives on the wiki?> CC: sldev@lists.secondlife.com> > On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd> wrote:> >> > As subject!> > I'm working out a handful of issues right now, but hopefully today.> You can build something very close at current by using the existing> 1.20 drop in svn and disabling the 3Dconnexion add-on. _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080411/f7d233c5/attachment.htm From seg at haxxed.com Fri Apr 11 04:02:09 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 11 04:04:08 2008 Subject: [sldev] Re: Feature freeze In-Reply-To: <47FAE718.7080209@lindenlab.com> References: <347b550f0804070503i52fcc257s7ad2e0687c40225@mail.gmail.com> <20080407165104.214aaf54.sldev@free.fr> <47FA9916.7010605@cox.net> <47FAE718.7080209@lindenlab.com> Message-ID: <1207911729.12371.6.camel@localhost.localdomain> On Mon, 2008-04-07 at 20:31 -0700, Paul Oppenheim (Poppy Linden) wrote: > It's also more difficult than your average task, because you're > essentially developing an API, which you Better Not Screw Up. You will never get it right the first time. Embrace change. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080411/124a4298/attachment.pgp From seg at haxxed.com Fri Apr 11 04:04:23 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 11 04:06:23 2008 Subject: [sldev] 1.20 wreaking havok with nvidia drivers under vista In-Reply-To: <47FED212.9070707@lindenlab.com> References: <47FE7B7F.9040903@streamsense.net> <47FE9768.8050808@lindenlab.com><47FE97E2.8030403@streamsense.net> <47FEB2EE.8040406@lindenlab.com> <47FED212.9070707@lindenlab.com> Message-ID: <1207911863.12371.8.camel@localhost.localdomain> On Thu, 2008-04-10 at 19:50 -0700, Dave Parks wrote: > Moving forward, we'll be looking at removing all GL dependencies from > the newview project and creating an API agnostic interface to the > graphics card. This is an early step in that direction, hot on the > heels of the use of gGL.begin/gGL.end vs. glBegin/glEnd. Does this mean we will be seeing Second Life on Xbox 360? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080411/ff260982/attachment.pgp From annagulaev at gmail.com Fri Apr 11 05:05:30 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri Apr 11 05:05:34 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) Message-ID: On 4/10/08, Felix Duesenburg wrote: > > I want the z limit removed altogether, and a physics engine whose > gravitation behaviour can be tweaked so that we can build space stations and > asteroids and entire planets! Yes! Off-topic, but I've wanted to build a large drum-shaped station. See the jogging scene of 2001 if you don't know what I mean. Can Havok4 do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080411/c0a63ba1/attachment-0001.htm From gigstaggart at gmail.com Fri Apr 11 05:22:10 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Apr 11 05:22:13 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) In-Reply-To: References: Message-ID: <47FF57F2.3060402@gmail.com> Anna Gulaev wrote: > Yes! Off-topic, but I've wanted to build a large drum-shaped station. > See the jogging scene of 2001 if you don't know what I mean. Can Havok4 > do that? > It doesn't work without spinning air. When a space station starts spinning, if there is no air to accelerate the occupants along with it, then it's just spinning around them floating in the center. You could partition the drum and slam the occupants against an interior wall to accelerate them, but havok has fake "drag" (in effect, static air) that would constantly decelerate them. So yeah, this isn't going to work into the foreseeable future. -Jason From ordinal.malaprop at fastmail.fm Fri Apr 11 05:53:54 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Apr 11 05:53:58 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) In-Reply-To: <47FF57F2.3060402@gmail.com> References: <47FF57F2.3060402@gmail.com> Message-ID: <94DEB97E-6A01-4CB0-BBB4-7E957D38FF99@fastmail.fm> On 11 Apr 2008, at 13:22, Jason Giglio wrote: > Anna Gulaev wrote: >> Yes! Off-topic, but I've wanted to build a large drum-shaped station. >> See the jogging scene of 2001 if you don't know what I mean. Can >> Havok4 >> do that? >> > > It doesn't work without spinning air. When a space station starts > spinning, if there is no air to accelerate the occupants along with > it, > then it's just spinning around them floating in the center. > > You could partition the drum and slam the occupants against an > interior > wall to accelerate them, but havok has fake "drag" (in effect, static > air) that would constantly decelerate them. So yeah, this isn't going > to work into the foreseeable future. Boooooo. Configurable, ideally scriptable gravity would be terrific though, just with point masses (and a cut-off in the attraction between smaller masses I would assume). A lot of the effect of that, though, would depend on avatars being able to rotate properly in all axes, which won't happen at the moment. Walking halfway around your asteroid and ending up standing on your head would be a little underwhelming. From alissa_sabre at yahoo.co.jp Fri Apr 11 06:56:52 2008 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Apr 11 06:57:05 2008 Subject: [sldev] Revision number for 1.20.0 RC viewer Message-ID: <9mds8ds4s0odz4L1Pe04s04d.alissa_sabre@yahoo.co.jp> On the "Community: Test Software" page on the SL web site (http://secondlife.com/community/downloads-optional.php), the version of the latest RC viewers are written as: 1.20.0.84331. However, the download links point to files of name *_1-20-0-84432_* (or *_1_20_0_84432_*). When I started the viewer, it calls itself 1.20.0.84432. The difference of the fourth number (I believe it is the SVN revision number) is confusing. I hope the web page is updated appropriately. Alissa Sabre -------------------------------------- GANBARE! NIPPON! Win your ticket to Olympic Games 2008. http://pr.mail.yahoo.co.jp/ganbare-nippon/ From secret.argent at gmail.com Fri Apr 11 07:00:21 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 11 07:00:37 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) In-Reply-To: <94DEB97E-6A01-4CB0-BBB4-7E957D38FF99@fastmail.fm> References: <47FF57F2.3060402@gmail.com> <94DEB97E-6A01-4CB0-BBB4-7E957D38FF99@fastmail.fm> Message-ID: <78B1C19B-9A0E-46E1-80AC-B539E113E2B1@gmail.com> On 2008-04-11, at 07:53, ordinal.malaprop@fastmail.fm wrote: > A lot of the effect of that, though, would depend on avatars being > able to rotate properly in all axes, which won't happen at the > moment. Walking halfway around your asteroid and ending up standing > on your head would be a little underwhelming. You'd have to do it with vehicles. From ordinal.malaprop at fastmail.fm Fri Apr 11 07:04:52 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Apr 11 07:04:56 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) In-Reply-To: <78B1C19B-9A0E-46E1-80AC-B539E113E2B1@gmail.com> References: <47FF57F2.3060402@gmail.com> <94DEB97E-6A01-4CB0-BBB4-7E957D38FF99@fastmail.fm> <78B1C19B-9A0E-46E1-80AC-B539E113E2B1@gmail.com> Message-ID: On 11 Apr 2008, at 15:00, Argent Stonecutter wrote: > On 2008-04-11, at 07:53, ordinal.malaprop@fastmail.fm wrote: >> A lot of the effect of that, though, would depend on avatars being >> able to rotate properly in all axes, which won't happen at the >> moment. Walking halfway around your asteroid and ending up standing >> on your head would be a little underwhelming. > > You'd have to do it with vehicles. Actually, you could simulate the whole thing with vehicles, a bit, now. Have everybody sit on a "space suit" vehicle, have them with full buoyancy and a few movement controls for attitude jets, then script them to track local masses and apply the correct velocity. Mobile masses could be vehicles too working on the same principle. *has work to do* *must not start playing with this now* From monkowsk at watson.ibm.com Fri Apr 11 09:03:10 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Apr 11 09:03:20 2008 Subject: [sldev] vivox.com hard-coded in viewer? In-Reply-To: <1207906958.22021.53.camel@localhost.localdomain> References: <1207906958.22021.53.camel@localhost.localdomain> Message-ID: <47FF8BBE.2000705@watson.ibm.com> I'm not exactly sure what you're looking for, but there is this VivoxDebugServerName bhd.vivox.com Hostname of the vivox account server to use for voice when not connected to Agni. Mike Ryan McDougall wrote: > Hello, > > I am running the SL viewer on opensim, and I have set the accout > management server and sip domain caps in open sim. However I still get a > vivox.com URI sent to me. > > If it is hard-coded, is it possible to treat this as a bug, and have it > fixed? > > Cheers, > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Fri Apr 11 14:31:09 2008 From: soft at lindenlab.com (Soft) Date: Fri Apr 11 14:31:13 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: There's definitely still something amiss. I'm running an export on all the branches right now, but not yet calling RC complete. We're finishing up quarterly reviews here, then I'll get back to banging on this, see if I can't get us happily building on all three, or I'll at least publish a list of what I need help on. Sorry about the delay. On Fri, Apr 11, 2008 at 5:10 AM, Matthew Dowd wrote: > > No joy I'm afraid - I've install what I think is the right version of boost > - it all compiles and links but when I run it on the first call to the boost > signal library it bombs out with a memory violation... > > > Matthew > > > Date: Thu, 10 Apr 2008 13:44:12 -0500 > > From: soft@lindenlab.com > > To: matthew.dowd@hotmail.co.uk > > Subject: Re: ETA for 1.20 source and supporting archives on the wiki? > > CC: sldev@lists.secondlife.com > > > > > On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd > > wrote: > > > > > > As subject! > > > > I'm working out a handful of issues right now, but hopefully today. > > You can build something very close at current by using the existing > > 1.20 drop in svn and disabling the 3Dconnexion add-on. > > > ________________________________ > Have you played Fishticuffs? Get fish-slapping on Messenger From yoz at lindenlab.com Fri Apr 11 15:16:11 2008 From: yoz at lindenlab.com (Yoz Grahame) Date: Fri Apr 11 15:16:16 2008 Subject: [sldev] Plotting Data on SLURL In-Reply-To: References: <84156973-5AEC-4 C09-928B-1216DA1711EF@lindenlab.com> Message-ID: <7C8883A0-6EA0-434F-8C4B-ECF72CDCB82D@lindenlab.com> (Sorry for taking so long over this reply - things have been a mite hectic over here) On Apr 7, 2008, at 11:40 AM, Harold Brown wrote: > [[ Forgot to send to list ]] > > Is there any further word on updates to the mapAPI system? > > As of right now not all regions can be displayed, nor are the tile > sets exactly the freshest the further you zoom out. > > I have my own API wrapper made for OpenLayers ( > http://www.openlayers.org ), using my custom TML service that uses the > SL backend (with some small issues). The wrapper is fairly complete, > but I haven't continued work as I don't know what direction LL will be > going with the mapAPI system. > > You can view a demo of the wrapper at: > http://www.mysldev.com/OpenLayer/oslurl.html > > The Region Names are a virtual TML service that generates an image > dynamically for the region name. Let's separate out the various components of the SL map system for this conversation: 1: The map tile generator. This is a nasty legacy system which is desperately in need of an overhaul, and also the main cause of some tiles being out of date. Unfortunately, right now, those who are most able to fix it are taken up with various big scaling and stability tasks. We do have the ability to fire off regeneration of specific tiles, though it still takes a day or two for the fresh tiles to be fully replicated across servers. 2: The backend service which makes the map tiles available to the web servers. Another legacy service which we'd rather didn't exist - ideally the web service hosts should be able to pull web-ready tiles on demand. 3: The front-facing web services called by the Javascript map. These are primarily used for translating between X+Y coords and region names. We have no problems with anyone calling these from any app, within the bounds of sensible usage (i.e. non-painful load levels). We have a long-term aim of making more and better web services available to developers, a process we're intending to accelerate this year. 4: The Javascript API used by map pages, which lives in slmapapi.js and sits on top of the GMaps API. This is the second version of the Javascript API. We chose GMaps as the underlying API as it's solid, has good cross-browser support and is popular amongst web developers. However, it also requires that developers acquire and use a GMaps API key - something we don't see as a significant barrier, but it does add a dependency. Harold: The OpenLayers work you're doing looks great. We currently have no specific plans for major changes to the mapAPI's existing functions (i.e. the combination of items 3 and 4 above). Generally speaking, your code should be fine for the forseeable future. If you have any specific areas of concern, if there are major dependencies which you think we should know about, or if there are particular enhancements you'd like to see, please let me know so that I can ensure they're considered in any future plans. -- Yoz Linden, Program Manager for Web & Internal Tools From mrfrans at gmail.com Fri Apr 11 16:53:02 2008 From: mrfrans at gmail.com (Frans) Date: Fri Apr 11 16:53:06 2008 Subject: [sldev] LL: Most major projects done? Time to return to haptics :-) In-Reply-To: <1207906038.12371.1.camel@localhost.localdomain> References: <1207906038.12371.1.camel@localhost.localdomain> Message-ID: <7765f2c60804111653y71a1f2aat9d816904b8dac57f@mail.gmail.com> Mitch Kapor is on it, and created something called Hands Free 3D. http://secondslog.blogspot.com/2008/04/free-your-hands.html -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080412/f4c1f00b/attachment.htm From mrfrans at gmail.com Fri Apr 11 16:59:30 2008 From: mrfrans at gmail.com (Frans) Date: Fri Apr 11 16:59:33 2008 Subject: [sldev] Centrifugal Gravity (was: What is the point...) In-Reply-To: References: <47FF57F2.3060402@gmail.com> <94DEB97E-6A01-4CB0-BBB4-7E957D38FF99@fastmail.fm> <78B1C19B-9A0E-46E1-80AC-B539E113E2B1@gmail.com> Message-ID: <7765f2c60804111659o13823e6dj605d4154205639a7@mail.gmail.com> This might be a interesting article to read, about how the gravity worked in Super Mario Galaxy. http://www.gamasutra.com/view/feature/3593/games_demystified_super_mario_.php not that you will be able to do it in LSL, but someone brave might try somethings with opensource server and viewer. Actually, you could simulate the whole thing with vehicles, a bit, now. Have > everybody sit on a "space suit" vehicle, have them with full buoyancy and a > few movement controls for attitude jets, then script them to track local > masses and apply the correct velocity. Mobile masses could be vehicles too > working on the same principle. > > *has work to do* > *must not start playing with this now* > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Jeroen Frans The Vesuvius Group http://www.thevesuviusgroup.com http://www.linkedin.com/in/mrfrans SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080412/e51fa078/attachment.htm From soft at lindenlab.com Fri Apr 11 19:19:50 2008 From: soft at lindenlab.com (Soft) Date: Fri Apr 11 19:19:53 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: I'm pushing Mac and Windows 1.20 shortly - I've got those building and running happily. Note that if you're copying in GL headers manually under Windows, you can/should stop now. I'm exporting some OSS-friendly headers, so that's one fewer thing to download. I updated the VS2003 wiki to reflect this. Linux is still being a PITA, and I'll have to look at it more in the morning. I think I'm running into the same boost issues that others have mentioned, and I'm not sure if it's a different compiler version issue or what yet. I'm seeing many of these: `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE15match_startmarkEv' referenced in section `.rodata' of /home/soft/ll/public/linden/libraries/i686-linux/lib_release_client/libboost_regex-gcc34-mt.a(instances.o): defined in discarded section collect2: ld returned 1 exit status On Fri, Apr 11, 2008 at 4:31 PM, Soft wrote: > There's definitely still something amiss. I'm running an export on all > the branches right now, but not yet calling RC complete. We're > finishing up quarterly reviews here, then I'll get back to banging on > this, see if I can't get us happily building on all three, or I'll at > least publish a list of what I need help on. > > Sorry about the delay. > > On Fri, Apr 11, 2008 at 5:10 AM, Matthew Dowd > > > wrote: > > > > No joy I'm afraid - I've install what I think is the right version of boost > > - it all compiles and links but when I run it on the first call to the boost > > signal library it bombs out with a memory violation... > > > > > > Matthew > > > > > Date: Thu, 10 Apr 2008 13:44:12 -0500 > > > From: soft@lindenlab.com > > > To: matthew.dowd@hotmail.co.uk > > > Subject: Re: ETA for 1.20 source and supporting archives on the wiki? > > > CC: sldev@lists.secondlife.com > > > > > > > > On Thu, Apr 10, 2008 at 1:31 PM, Matthew Dowd > > > wrote: > > > > > > > > As subject! > > > > > > I'm working out a handful of issues right now, but hopefully today. > > > You can build something very close at current by using the existing > > > 1.20 drop in svn and disabling the 3Dconnexion add-on. > > > > > > ________________________________ > > Have you played Fishticuffs? Get fish-slapping on Messenger > From robin.cornelius at gmail.com Sat Apr 12 02:45:49 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Apr 12 02:46:02 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> Message-ID: <480084CD.6060000@gmail.com> Soft wrote: > I'm pushing Mac and Windows 1.20 shortly - I've got those building and > running happily. > Linux is still being a PITA, and I'll have to look at it more in the > morning. I think I'm running into the same boost issues that others > have mentioned, and I'm not sure if it's a different compiler version > issue or what yet. I'm seeing many of these: > > `.gnu.linkonce.t._ZN5boost9re_detail12perl_matcherIN9__gnu_cxx17__normal_iteratorIPKcSsEESaINS_9sub_matchIS6_EEENS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE15match_startmarkEv' > referenced in section `.rodata' of > /home/soft/ll/public/linden/libraries/i686-linux/lib_release_client/libboost_regex-gcc34-mt.a(instances.o): > defined in discarded section collect2: ld returned 1 exit status There is some strangeness with the boost libraries. I've got it built on debian but i had to make scons changes. Firstly you were specifying the soname to link to (well not quite the soname but a compiler specific version of the library), which is a bit naughty. This is what i changed in SConstruct @@ -301,7 +300,7 @@ if standalone: include_dirs += [d[2:] for d in pkgconfig('--cflags-only-I').split()] - client_external_libs += [ 'boost_program_options-gcc34-mt', 'boost_signals-gcc34-mt', 'boost_regex-gcc34-mt'] + client_external_libs += [ 'boost_program_options', 'boost_signals', 'boost_regex'] On a well managed distro I presume that the actual libboost installed reflected the gcc compiler version selected. So on debian if i update alternatives to use gcc-3.4 i get the correct boost libraries for anything i build. In the libs package you should probably supply a libboost_program_options.so that is simlinked to your actual libboost_program_options-gcc34-mt and probably change the gcc command to gcc-3.4 to force non standalone users to use 3.4 or else boost hell will let loose. The only thing i can think of for your problem is that your gcc and your boost libraries don't match. Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080412/8e865957/signature.pgp From tateru.nino at gmail.com Sat Apr 12 02:49:53 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Apr 12 02:54:42 2008 Subject: [sldev] Interest list / draw distance anomaly Message-ID: <480085C1.4010901@gmail.com> I'm not sure if this qualifies as an issue at this stage, so I'm taking a moment to get some impressions from the technically ept. Using the 1.19.1 and 1.20 (when I can get that to not crash quite quickly) viewers, I usually have my draw distance set well up (often at 512), and until - I'm not sure when, a week or so ago perhaps - until recently, everything behaved as one might expect. Then things changed. Suddenly geometry and even terrain that was well within the draw distance would stop appearing. My sphere of drawability became a squooshed potato shape, with terrain sometimes cutting short suspiciously at property lines, half builds within a hundred or two hundred metres rezzing while the other half did not. Moving helps. Dialling down my draw distance and then boosting it back up again helps sometimes too. It is as if the interest list has drained before I got everything on it, and that I have to do something to signal the sim that my sphere of interest has changed before I can get the remainder of the drawable land and objects. Fair enough - this could be just me - but I suspect the onset coincided with a server update (though it seems more common in some simulators than in others). Is this just me, or is anyone else seeing this? If it's not just me, it's probably a JIRA candidate. From carjay at gmx.net Sat Apr 12 04:46:06 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Apr 12 04:46:10 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: <480084CD.6060000@gmail.com> References: <47FE1FE9.4050504@gmail.com> <480084CD.6060000@gmail.com> Message-ID: <4800A0FE.8050201@gmx.net> Robin Cornelius wrote: > The only thing i can think of for your problem is that your gcc and your > boost libraries don't match. > I built against the system boost libs, too and also only changed the libnames as Robin did and it gave me no trouble (on x86_64). Could it be a bug in the linker triggered by static linking? Regards, Carsten From soft at lindenlab.com Sat Apr 12 07:15:48 2008 From: soft at lindenlab.com (Soft) Date: Sat Apr 12 07:15:50 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: <4800A0FE.8050201@gmx.net> References: <47FE1FE9.4050504@gmail.com> <480084CD.6060000@gmail.com> <4800A0FE.8050201@gmx.net> Message-ID: On Sat, Apr 12, 2008 at 6:46 AM, Carsten Juttner wrote: > Robin Cornelius wrote: > > > The only thing i can think of for your problem is that your gcc and your > > boost libraries don't match. > > > > > > I built against the system boost libs, too and also only changed the > libnames as Robin did and it gave me no trouble (on x86_64). > > Could it be a bug in the linker triggered by static linking? Possible. Poppy Linden spotted this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625 For now, I'll match up to the same compiler toolchain used to build the released viewer, which is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) (yes, I know!) and ensure the open source build is good there. If it's all good, the only version I'm going to worry about past that is gcc 4.1, which carries the fix to the above issue. I'd like us to be more ready for whenever the hell we get off Debian Sarge, anyway. From secret.argent at gmail.com Sat Apr 12 08:47:02 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 12 08:47:11 2008 Subject: [sldev] Sun Claims Big Leap with MySQL Upgrade Next Week In-Reply-To: References: <47FE1FE9.4050504@gmail.com> <480084CD.6060000@gmail.com> <4800A0FE.8050201@gmx.net> Message-ID: <2F811BD6-C702-4BAD-9EA3-68B758127A2C@gmail.com> http://www.cio.com/article/333613/ Sun_Claims_Big_Leap_with_MySQL_Upgrade_Next_Week Hope Linden Labs is keeping an eye on this. ^^ From aimee at ama-zing.co.uk Sat Apr 12 15:22:20 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Apr 12 15:22:31 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac Message-ID: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> After compiling the 1.20 RC in Xcode (where it runs fine), running Second Life.app from the finder pops up a dialog saying: "Second Life found an error parsing the command line. Please see: http://wiki.[blah blah] Error: unknown option -p". ... and then dies. Removing all my settings files and scratching my head a lot seem to make no difference. I get the feeling I'm missing something obvious :) anyone point me in the right direction to where the -p is coming from? Relevant bit of the log attached below. Thanks, Aimee. (SL name: Aimee Trescothick) 2008-04-12T22:17:54Z INFO: initConfiguration: Loading settings file list/Applications/Second Life/Second Life.app/Contents/Resources/ app_settings/settings_files.xml 2008-04-12T22:17:54Z INFO: loadSettingsFromDirectory: Loaded settings file /Applications/Second Life/Second Life.app/Contents/Resources/ app_settings/settings_crash_behavior.xml 2008-04-12T22:17:54Z INFO: loadSettingsFromDirectory: Loaded settings file /Applications/Second Life/Second Life.app/Contents/Resources/ app_settings/settings.xml 2008-04-12T22:17:54Z INFO: loadSettingsFromDirectory: Loaded settings file /Applications/Second Life/Second Life.app/Contents/Resources/ app_settings/settings_per_account.xml 2008-04-12T22:17:54Z WARNING: loadFromFile: Cannot find file /Users/ aimee/Library/Application Support/SecondLife/user_settings/ settings_crash_behavior.xml to load. 2008-04-12T22:17:54Z WARNING: loadSettingsFromDirectory: Cannot load / Users/aimee/Library/Application Support/SecondLife/user_settings/ settings_crash_behavior.xml - No settings found. 2008-04-12T22:17:54Z WARNING: loadFromFile: Cannot find file /Users/ aimee/Library/Application Support/SecondLife/user_settings/ settings.xml to load. 2008-04-12T22:17:54Z WARNING: loadSettingsFromDirectory: Cannot load / Users/aimee/Library/Application Support/SecondLife/user_settings/ settings.xml - No settings found. 2008-04-12T22:17:54Z WARNING: loadFromFile: Cannot find file /Users/ aimee/Library/Application Support/SecondLife/user_settings/ settings_per_account.xml to load. 2008-04-12T22:17:54Z WARNING: loadSettingsFromDirectory: Cannot load / Users/aimee/Library/Application Support/SecondLife/user_settings/ settings_per_account.xml - No settings found. 2008-04-12T22:17:54Z WARNING: parseAndStoreResults: Caught Error:unknown option -p 2008-04-12T22:17:54Z WARNING: initConfiguration: Error parsing command line options. Command Line options ignored. 2008-04-12T22:17:54Z INFO: initConfiguration: Command line usage: -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080412/229e9348/attachment.htm From secret.argent at gmail.com Sat Apr 12 16:57:04 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 12 16:57:11 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> Message-ID: On 2008-04-12, at 17:22, Aimee Walton wrote: > Removing all my settings files and scratching my head a lot seem to > make no difference. I get the feeling I'm missing something > obvious :) anyone point me in the right direction to where the -p > is coming from? Relevant bit of the log attached below. Look in Contents/Resources/arguments.txt? From sammy.frederix at gmail.com Sat Apr 12 17:46:50 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Sat Apr 12 17:46:59 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> Message-ID: <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> [Resending to the list. oops] On 13/04/2008, at 9:57 AM, Argent Stonecutter wrote: > On 2008-04-12, at 17:22, Aimee Walton wrote: >> Removing all my settings files and scratching my head a lot seem to >> make no difference. I get the feeling I'm missing something >> obvious :) anyone point me in the right direction to where the -p >> is coming from? Relevant bit of the log attached below. > Look in Contents/Resources/arguments.txt? It's Empty (I haven't actually looked into it beyond this, but I can see the same behaviour). From aimee at ama-zing.co.uk Sat Apr 12 18:05:22 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Apr 12 18:05:32 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> Message-ID: On Apr 13, 2008, at 01:46, Sammy Frederix wrote: > > On 13/04/2008, at 9:57 AM, Argent Stonecutter wrote: >> On 2008-04-12, at 17:22, Aimee Walton wrote: >>> Removing all my settings files and scratching my head a lot seem >>> to make no difference. I get the feeling I'm missing something >>> obvious :) anyone point me in the right direction to where the -p >>> is coming from? Relevant bit of the log attached below. >> Look in Contents/Resources/arguments.txt? > > It's Empty (I haven't actually looked into it beyond this, but I > can see the same behaviour). Ah, both glad and sad to see I'm not the only one :) arguments.txt was my first port of call, it's empty. I have a suspicion the erroneous -p is being created by something going off track during the parsing rather than actually being passed in, though I could be barking up the wrong tree. It's only when Second Life.app is run from the finder that it fails. Running from Xcode or running Second\ Life.app/Contents/MacOS/Second\ Life from the shell works fine. Aimee. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080413/9ebd1183/attachment.htm From sammy.frederix at gmail.com Sat Apr 12 21:25:04 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Sat Apr 12 21:25:16 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> Message-ID: <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> On 13/04/2008, at 11:05 AM, Aimee Walton wrote: >>> On 2008-04-12, at 17:22, Aimee Walton wrote: >>>> Removing all my settings files and scratching my head a lot seem >>>> to make no difference. I get the feeling I'm missing something >>>> obvious :) anyone point me in the right direction to where the -p >>>> is coming from? Relevant bit of the log attached below. >> > Ah, both glad and sad to see I'm not the only one :) > arguments.txt was my first port of call, it's empty. > > I have a suspicion the erroneous -p is being created by something > going off track during the parsing rather than actually being passed > in, though I could be barking up the wrong tree. It's only when > Second Life.app is run from the finder that it fails. Running from > Xcode or running Second\ Life.app/Contents/MacOS/Second\ Life from > the shell works fine. While I haven't spent any time on this, I did remember that when you have a really wide terminal window, and type ps -ax you get entries like (Sorry for the extra long lines): 129 ?? 0:43.53 /System/Library/CoreServices/Finder.app/ Contents/MacOS/Finder -psn_0_49164 136 ?? 61:30.74 /Applications/Safari.app/Contents/MacOS/ Safari -psn_0_65552 138 ?? 0:01.76 /Applications/SMARTReporter.app/Contents/ MacOS/SMARTReporter -psn_0_69649 140 ?? 0:00.13 /Applications/iTunes.app/Contents/Resources/ iTunesHelper.app/Contents/MacOS/iTunesHelper -psn_0_77843 Running the released 1.19.1(4) build, I end up with: 62365 ?? 0:00.70 /Applications/Second Life.app/Contents/MacOS/ Second Life -psn_0_1286458 and the freshly built client also gets started with that parameter And when I open the newly build version from the finder (or using open linden/indra/newview/build/Deployment/Second\ Life.app): 62392 ?? 0:00.58 /Users/home/linden/indra/newview/build/ Development/Second Life.app/Contents/MacOS/Second Life -psn_0_1294652 And if I use the command line: $ linden/indra/newview/build/Deployment/Second\ Life.app/Contents/ MacOS/Second\ Life I get: 62408 ttys002 0:00.60 linden/indra/newview/build/Deployment/Second Life.app/Contents/MacOS/Second Life And the same for starting from Xcode. It's not passing the -psn paramater. That's where I suspect the -p is coming from. Now to find out why it's no longer being ignored. I'm compiling from Branch_1-20-Viewer. Regards, Sammy From aimee at ama-zing.co.uk Sat Apr 12 22:29:54 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Apr 12 22:30:04 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> Message-ID: On Apr 13, 2008, at 05:25, Sammy Frederix wrote: > While I haven't spent any time on this, I did remember that when > you have a really wide terminal window, and type ps -ax you get > entries like (Sorry for the extra long lines): > 129 ?? 0:43.53 /System/Library/CoreServices/Finder.app/ > Contents/MacOS/Finder -psn_0_49164 > 136 ?? 61:30.74 /Applications/Safari.app/Contents/MacOS/ > Safari -psn_0_65552 > 138 ?? 0:01.76 /Applications/SMARTReporter.app/Contents/ > MacOS/SMARTReporter -psn_0_69649 > 140 ?? 0:00.13 /Applications/iTunes.app/Contents/ > Resources/iTunesHelper.app/Contents/MacOS/iTunesHelper -psn_0_77843 Aaaaaaaaaah! Yes, of course, the opening from the finder means they get passed the Process Serial Number, doh! I guess there's some validation been added to the command line parsing in the overhaul of the setting system. Aimee. From annagulaev at gmail.com Sun Apr 13 05:02:04 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun Apr 13 05:02:06 2008 Subject: [sldev] Interest list / draw distance anomaly In-Reply-To: <480085C1.4010901@gmail.com> References: <480085C1.4010901@gmail.com> Message-ID: On 4/12/08, Tateru Nino wrote: > > ...Suddenly geometry and even terrain that was well within the draw > distance would stop appearing. Are you sure this is a viewer issue? I've seen this with 1.19.1, but I've also seen something similar with code based on 1.18.4.3 that hasn't been re-compiled in ages. I only saw it once and didn't investigate further. The draw distance seemed to be way off (set for 128, not seeing things much closer than that), and at one point the ground was rendering so badly that the ground under my avatar didn't show. I'll get a screen shot if I see it again. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080413/14487c06/attachment-0001.htm From tateru.nino at gmail.com Sun Apr 13 05:14:37 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Apr 13 05:19:31 2008 Subject: [sldev] Interest list / draw distance anomaly In-Reply-To: References: <480085C1.4010901@gmail.com> Message-ID: <4801F92D.4010705@weblogsinc.com> Anna Gulaev wrote: > On 4/12/08, *Tateru Nino* wrote: > > ...Suddenly geometry and even terrain that was well within the > draw distance would stop appearing. > > > Are you sure this is a viewer issue? I've seen this with 1.19.1, but > I've also seen something similar with code based on 1.18.4.3 > that hasn't been re-compiled in ages. I only saw it > once and didn't investigate further. The draw distance seemed to be > way off (set for 128, not seeing things much closer than that), and at > one point the ground was rendering so badly that the ground under my > avatar didn't show. I'll get a screen shot if I see it again. My gut instinct is to look towards the server end first. -- Tateru Nino http://www.massively.com/ From carjay at gmx.net Sun Apr 13 07:20:00 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Apr 13 07:19:53 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> Message-ID: <48021690.4060203@gmx.net> Sammy Frederix wrote: > That's where I suspect the -p is coming from. Now to find out why it's > no longer being ignored. > I'm compiling from Branch_1-20-Viewer. That unknown command line options are no longer ignored has been added by the recent changes only. I know that it wasn't the case before since I always mess up the options (too used to the convention of prefixing "--" to long command options) and noticing only later after login which of course required a relog. :) Regards, Carsten From aimee at ama-zing.co.uk Sun Apr 13 07:54:41 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sun Apr 13 07:54:54 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <48021690.4060203@gmx.net> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> <48021690.4060203@gmx.net> Message-ID: On Apr 13, 2008, at 15:20, Carsten Juttner wrote: > I know that it wasn't the case before since I always mess up the > options (too used to the convention of prefixing "--" to long > command options) ... which is now correct it seems :) From the log ... 2008-04-13T14:51:24Z INFO: initConfiguration: Command line usage: --autologin log in as last saved user --channel arg n/a --console arg n/a --cooperative arg Yield some idle time to local host. --crashonstartup Crashes on startup. For QA use. --debugviews n/a --drop arg n/a ... etc. Aimee. From carjay at gmx.net Sun Apr 13 11:21:47 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Apr 13 11:21:54 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> <48021690.4060203@gmx.net> Message-ID: <48024F3B.3060701@gmx.net> Aimee Walton wrote: > On Apr 13, 2008, at 15:20, Carsten Juttner wrote: > >> I know that it wasn't the case before since I always mess up the >> options (too used to the convention of prefixing "--" to long command >> options) > > ... which is now correct it seems :) > Ah, great :) The command line parsing was switched to boost::program_options so it is obviously more flexible now. Regards, Carsten From kfa at gmx.net Sun Apr 13 14:07:04 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 13 14:07:12 2008 Subject: [sldev] Build error Message-ID: <480275F8.7030301@gmx.net> Just pulled the latest release source from svn (Last Changed Rev: 84702), together with the libraries package from Branch_1-19-1-Viewer (r84244), I receive the following error: 4>c:\sl\latest\linden\indra\newview\llcommandlineparser.cpp(240) : error C2259: 'LLCLPValue' : cannot instantiate abstract class 4> due to following members: 4> 'bool boost::program_options::value_semantic::is_zero_tokens(void) const' : is abstract 4> c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(37) : see declaration of 'boost::program_options::value_semantic::is_zero_tokens' 4> 'bool boost::program_options::value_semantic::is_implicit(void) const' : is abstract 4> c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(47) : see declaration of 'boost::program_options::value_semantic::is_implicit' 4> 'bool boost::program_options::value_semantic::is_multitoken(void) const' : is abstract 4> c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(50) : see declaration of 'boost::program_options::value_semantic::is_multitoken' 4>Build log was saved at "file://c:\SL\latest\linden\indra\newview\Release\BuildLog.htm" 4>newview - 1 error(s), 0 warning(s) Not sure where to start looking? Felix From lists at hippygeek.co.uk Sun Apr 13 15:31:30 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Sun Apr 13 15:32:06 2008 Subject: [sldev] [AWG] Comments on SLGOGP Draft 1 Message-ID: <480289C2.5010703@hippygeek.co.uk> Dear list, I've just been reading the first draft of the Open Grid Protocol and listening to the audio recording of the second Architecture Working Group meeting and it has got me interested. == Quick Introduction == By way of introduction I am an undergraduate at the University of Birmingham [1] reading MEng Computer Interactive Systems and my final year masters project next year will hopefully be on 3D Web technology. I'm also currently in the very early stages of founding Krellian [2] and the not-for-profit Krellian Foundation [3]. I have never been involved in any standardisation work before but am an advocate of open standards and have an interest in online 3D worlds. Although an occasional Second Life user I know very little about the current Second Life architecture and come from a web programming background, so tend to see online virtual worlds as the "3D Web", a direct extension of the existing web. I think this is a slightly different way of looking at things than the current approach taken by Second Life. What most interests me about the AWG discussions is how open the group appears to be to utilising relevant existing standards rather than attempting to re-invent new ones. == Existing Standards == I am very happy to see RESTful use of HTTP and the possibility of using FOAF [4] & XFN [5] as a semantic web style approach to describing relationships between users is interesting. Although it was commented that something broader than OpenID [6] is required for authentication, I think that a similar open authentication mechanism is essential. There are certainly surface similarities in the way the agent is described by a URI. XDI [7] and SAML [8] also spring to mind. A particularly interesting technology mentioned was XMPP. The obvious application of this is for Instant Messaging and presence, but I think the most important use is as a general point-to-point protocol. I have thought about using XMPP in realtime web apps before to overcome the limitations and asynchronous nature of HTTP, but have never actually come close to implementing it. In my opinion using XMPP would certainly be preferable to inventing a new TCP or UDP based protocol in cases where HTTP is not suitable, providing it stands up to the requirements. I understand XMPP [9] to be very extensible. It seems odd to discuss open standards for the 3D Web without mentioning the Web3D Consortium [10] and X3D. Are there representatives from Web3D involved in the discussions and how would X3D fit into this proposed architecture? == Scope and general approach == Overall the basic structure of the proposed protocols is similar to the way I envisaged the 3D Web on my web site [11] (apologies for referring to Second Life as the "AOL of the 3D Web" on that page :P ). In that design concept I called the "Viewer" a "3D Web Browser", the "Agent Domain" an "Avatar Server" and the "Region Domain" simply the "3D Web Server". I also covered a lot of relevant points in my response [12] to a blog post by Bob Sutor of IBM where he listed the requirements of his ideal virtual world. I can not find a clear definition of the scope of the AWG specification. The current standardisation approach seems very bottom-up, focusing on matching standards to features that are known to exist in Second Life. I would be interested to see a little more top-down work to more precisely define the scope of exactly what is being standardised and how this fits into the wider world of Internet standards. For example, I personally feel that although instant messaging and the concept of currency are inevitably used in online virtual worlds, they are not a required part of the core specification. Currency and instant messaging in a 3D world should simply be a 3D front end to existing systems (in the same way that meebo.com is a front end to a jabber service, the web browser does not need to support XMPP). This is probably quite obvious but I also think there should be no *enforcement* of a topology which requires that virtual spaces have a constant position relative to each other (i.e. "teleporting" should be the same as clicking on hyperlinks in text web pages, where you jump between spaces rather than having to navigate around them spatially as in the real world). That way, the closeness of two spaces is measured by interest rather than spatial dimensions. == Context == Something which interests me personally is how the 3D Web fits in the context of the rest of the World Wide Web and the rest of the Internet. I would like to see a World Wide Web where a URI identifies a resource, but that resource can have many representations. Those representations may include rich text (XHTML), 2D vector graphics (SVG), a speech dialogue (VoiceXML) or an interactive 3D world (X3D?). Content Negotiation in HTTP could then be used to negotiate a representation format between the web server and web user agent (or the "region domain" and "agent domain"). The user could switch between these different representations based on hardware capabilities, personal abilities and current user environment. This may require certain distinctions between the server and user agent which are not currently part of the AWG proposed protocols. Would this be something that could form the basis for a "Device Independence" Viewpoint Advocacy Group? Regards Ben Francis 1. http://www.bham.ac.uk 2. http://krellian.com 3. http://krellian.org 4. http://www.foaf-project.org/ 5. http://gmpg.org/xfn/ 6. http://openid.net/ 7. http://www.xdi.org/ 8. http://wiki.oasis-open.org/security/SAMLV1 9. http://www.xmpp.org/ 10. http://web3d.org 11. http://www.tola.me.uk/concepts/2007/3d_web 12. http://www.tola.me.uk/2007/06/09/bobs_3d_web From dahliatrimble at gmail.com Sun Apr 13 17:03:47 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun Apr 13 17:03:50 2008 Subject: [sldev] [AWG] Comments on SLGOGP Draft 1 In-Reply-To: <480289C2.5010703@hippygeek.co.uk> References: <480289C2.5010703@hippygeek.co.uk> Message-ID: On Sun, Apr 13, 2008 at 3:31 PM, Ben Francis wrote: (edited for the sake of brevity and context) > > I can not find a clear definition of the scope of the AWG specification. > The current standardisation approach seems very bottom-up, focusing on > matching standards to features that are known to exist in Second Life. I > would be interested to see a little more top-down work to more precisely > define the scope of exactly what is being standardised and how this fits > into the wider world of Internet standards. For example, I personally feel > that although instant messaging and the concept of currency are inevitably > used in online virtual worlds, they are not a required part of the core > specification. Currency and instant messaging in a 3D world should simply be > a 3D front end to existing systems (in the same way that meebo.com is a > front end to a jabber service, the web browser does not need to support > XMPP). I've raised this issue a few times in the past and the response has always been along the lines of "We want to understand and document the current protocols before we try to design anything new". It also appears that the AWG is starting to deviate from this initial documentation strategy but most of the players are coming from the perspective of users, engineers, or open source contributors of Second Life and similar implementations (Opensim), so it makes sense that the current proposals will have a lot of bias towards the Second LIfe protocol implementation. If you see too many implementation specific details in the current documents, I know some of us will be interested in hearing what alternatives you have in mind. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080413/65bf51cd/attachment.htm From matthew.dowd at hotmail.co.uk Mon Apr 14 00:34:40 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 14 00:34:42 2008 Subject: [sldev] Build error In-Reply-To: <480275F8.7030301@gmx.net> References: <480275F8.7030301@gmx.net> Message-ID: You need updated boost libraries - for windows check here http://www.boost-consulting.com/products/free However, with these (on VS2005), I finally managed to get a successful compile. However, on running the viewer crashes with a memory violation somewhere within the boost::signal library, so I'm waiting on Soft to upload hopefully working packages to the wiki. Its somewhat frustrating, as I *think* I have the bulk of the code read to allow selecting different skins from within the viewer, but can't actually test whether what I have works or just makes a collosal mess! Matthew> Date: Sun, 13 Apr 2008 17:07:04 -0400> From: kfa@gmx.net> To: sldev@lists.secondlife.com> Subject: [sldev] Build error> > Just pulled the latest release source from svn (Last Changed Rev: > 84702), together with the libraries package from Branch_1-19-1-Viewer > (r84244), I receive the following error:> > 4>c:\sl\latest\linden\indra\newview\llcommandlineparser.cpp(240) : error > C2259: 'LLCLPValue' : cannot instantiate abstract class> 4> due to following members:> 4> 'bool > boost::program_options::value_semantic::is_zero_tokens(void) const' : is > abstract> 4> > c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(37) > : see declaration of > 'boost::program_options::value_semantic::is_zero_tokens'> 4> 'bool > boost::program_options::value_semantic::is_implicit(void) const' : is > abstract> 4> > c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(47) > : see declaration of 'boost::program_options::value_semantic::is_implicit'> 4> 'bool > boost::program_options::value_semantic::is_multitoken(void) const' : is > abstract> 4> > c:\sl\latest\linden\libraries\include\boost\program_options\value_semantic.hpp(50) > : see declaration of 'boost::program_options::value_semantic::is_multitoken'> 4>Build log was saved at > "file://c:\SL\latest\linden\indra\newview\Release\BuildLog.htm"> 4>newview - 1 error(s), 0 warning(s)> > Not sure where to start looking?> > Felix> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080414/e5ce28f5/attachment.htm From olli_aro at yahoo.co.uk Mon Apr 14 00:53:16 2008 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Mon Apr 14 00:53:17 2008 Subject: [sldev] Plotting Data on SLURL In-Reply-To: <7C8883A0-6EA0-434F-8C4B-ECF72CDCB82D@lindenlab.com> Message-ID: >3: The front-facing web services called by the Javascript map. These >are primarily used for translating between X+Y coords and region >names. We have no problems with anyone calling these from any app, >within the bounds of sensible usage (i.e. non-painful load levels). We >have a long-term aim of making more and better web services available >to developers, a process we're intending to accelerate this year. Hi Yoz, Is this the stuff at http://secondlife.com/developers/mapapi/? I tried the example at http://secondlife.com/developers/mapapi/example-use-region-names.html, in order to test the functionality that works based on regions, but got the following error: lh[downcased_name] has no properties http://secondlife.com/apps/mapapi Line: 2719 Does this mean that the function for using the region names to create SLPoint is currently broken? Regards, Olli From lenglish5 at cox.net Mon Apr 14 01:02:12 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Apr 14 01:02:15 2008 Subject: [sldev] [AWG] Comments on SLGOGP Draft 1 In-Reply-To: <480289C2.5010703@hippygeek.co.uk> References: <480289C2.5010703@hippygeek.co.uk> Message-ID: <48030F84.9010204@cox.net> Ben Francis wrote: > Dear list, > > I've just been reading the first draft of the Open Grid Protocol and > listening to the audio recording of the second Architecture Working > Group meeting and it has got me interested. > I hope you've managed to read a few of the chatlogs of AW Groupies in-world meetings and Zero's office hours and so on, which give context to the second meeting: https://wiki.secondlife.com/wiki/AW_Groupies#Activities > == Quick Introduction == > > By way of introduction I am an undergraduate at the University of > Birmingham [1] reading MEng Computer Interactive Systems and my final > year masters project next year will hopefully be on 3D Web technology. > I'm also currently in the very early stages of founding Krellian [2] > and the not-for-profit Krellian Foundation [3]. > > I have never been involved in any standardisation work before but am > an advocate of open standards and have an interest in online 3D > worlds. Although an occasional Second Life user I know very little > about the current Second Life architecture and come from a web > programming background, so tend to see online virtual worlds as the > "3D Web", a direct extension of the existing web. I think this is a > slightly different way of looking at things than the current approach > taken by Second Life. > > What most interests me about the AWG discussions is how open the group > appears to be to utilising relevant existing standards rather than > attempting to re-invent new ones. Except where needed. You should talk to Zero Linden (Mark Lentczner of Linden Lab) and Zha Ewry (David Levine of IBM) about issues with using XMPP for IM in Second Life, especially in the super-grid that a full-blown 3D web would involve with billions of accounts, 50-100 million avatars online, etc. > > A particularly interesting technology mentioned was XMPP. The obvious > application of this is for Instant Messaging and presence, As above for IM and understand that "presence" in Second Life will have two, possibly three distinct stages, and that XMPP's "presence" may not address them as well as you might expect. > but I think the most important use is as a general point-to-point > protocol. I have thought about using XMPP in realtime web apps before > to overcome the limitations and asynchronous nature of HTTP, but have > never actually come close to implementing it. In my opinion using XMPP > would certainly be preferable to inventing a new TCP or UDP based > protocol in cases where HTTP is not suitable, providing it stands up > to the requirements. I understand XMPP [9] to be very extensible. > > It seems odd to discuss open standards for the 3D Web without > mentioning the Web3D Consortium [10] and X3D. Are there > representatives from Web3D involved in the discussions and how would > X3D fit into this proposed architecture? > Second Life is an existing system with exceedingly poor documentation and protocols that are in total flux. There's no point in seeking out standards bodies until the new protocols are in place and documented sufficiently well that they can be critiqued. As for X3D, I don't think its quite up to handling SL and other large-scale virtual worlds requirements, though I may be wrong, of course. > == Scope and general approach == > > Overall the basic structure of the proposed protocols is similar to > the way I envisaged the 3D Web on my web site [11] (apologies for > referring to Second Life as the "AOL of the 3D Web" on that page :P ). > In that design concept I called the "Viewer" a "3D Web Browser", the > "Agent Domain" an "Avatar Server" and the "Region Domain" simply the > "3D Web Server". I also covered a lot of relevant points in my > response [12] to a blog post by Bob Sutor of IBM where he listed the > requirements of his ideal virtual world. > > I can not find a clear definition of the scope of the AWG > specification. The current standardisation approach seems very > bottom-up, focusing on matching standards to features that are known > to exist in Second Life. That is because the AWG itself is dedicated to supporting the 2-year plan of Linden Lab, to open up the *Second Life* grid to third parities willing to use the protocols that are compatible with Second Life as it is projected to exist 2 years from now. Trying to accommodate virtual worlds that haven't been designed to be 100% compatible with Second Life is a much more difficult goal. The IBM-Linden Lab project to create a portable avatar standard is more along those lines. The AW Groupies theoretical discussions wander into that territory quite often as well. There are several Second Life-related projects that are looking to extend the SL capabilities in various ways not necessarily envisioned by Linden Lab, and the contact info for them is found here: https://wiki.secondlife.com/wiki/AW_Groupies#External_Resources There are other groups and organizations where Second Life isn't the central focus which may be more what you are looking for in that regard, such as Croquet/Qwak, Wonderland and so on, though of course, each of them is more closed in some ways than Second Life is expected to become. > I would be interested to see a little more top-down work to more > precisely define the scope of exactly what is being standardised and > how this fits into the wider world of Internet standards. For example, > I personally feel that although instant messaging and the concept of > currency are inevitably used in online virtual worlds, they are not a > required part of the core specification. Currency and instant > messaging in a 3D world should simply be a 3D front end to existing > systems (in the same way that meebo.com is a front end to a jabber > service, the web browser does not need to support XMPP). > As I said, the AWG's focus is on virtual worlds that are 100% compatible with Second Life. Trying to accommodate 3rd party money and IM that aren'tt compatible with Linden Lab's own offerings is a far more difficult goal --one that the AWG isn't looking at. The AW Groupies meetings discuss this, and Open Sim has a more open stance on these issues. See above for Open Sim contacts. > This is probably quite obvious but I also think there should be no > *enforcement* of a topology which requires that virtual spaces have a > constant position relative to each other (i.e. "teleporting" should be > the same as clicking on hyperlinks in text web pages, where you jump > between spaces rather than having to navigate around them spatially as > in the real world). That way, the closeness of two spaces is measured > by interest rather than spatial dimensions. > In Zero Linden's vision, a grid topography reveals asset trust: if you can walk from one grid to the next in the same way you can walk from one Second Life region to the next, it is an assurance to the avatar that asset and monetary issues behave the same in both worlds. Working with two different "grids" that may not even be grids is another issue that goes beyond the AWG's near-term goals, though TP between them should obviously be possible if they both accept the same TP protocols. > == Context == > > Something which interests me personally is how the 3D Web fits in the > context of the rest of the World Wide Web and the rest of the Internet. > > I would like to see a World Wide Web where a URI identifies a > resource, but that resource can have many representations. Those > representations may include rich text (XHTML), 2D vector graphics > (SVG), a speech dialogue (VoiceXML) or an interactive 3D world (X3D?). > Content Negotiation in HTTP could then be used to negotiate a > representation format between the web server and web user agent (or > the "region domain" and "agent domain"). The user could switch between > these different representations based on hardware capabilities, > personal abilities and current user environment. > > This may require certain distinctions between the server and user > agent which are not currently part of the AWG proposed protocols. > > Would this be something that could form the basis for a "Device > Independence" Viewpoint Advocacy Group? > > I'm sure there are plenty of people who are interested in this. You should come to AW Groupies meetings, Zero's office hours, as well as talk to the Open SIm, realXtend, openviewer people. Other virtual worlds have other contact points, but none are as open in the sense of being open source AND open protocol as the groups I've listed in the AW Groupies external links, or so I believe. AW Groupies meetings happen every Tuesday morning in-world at 9:30 am Second Life Time (Pacific Coast Time). I won't be attending this next one, but you can contact Zha Ewry or Tree Kyomoon for a group invite to get to the meeting. Zero LInden's office hours are Tuesdays at 1PM SLT and Thursdays at 8:30 AM SLT. Contacts for other groups related to Second Life are found on the AW Groupies page: https://wiki.secondlife.com/wiki/AW_Groupies Hope to see you at the various meetings. Sounds like you have a lot to contribute. Lawson (Saijanai Kuhn) From tateru.nino at gmail.com Mon Apr 14 02:33:28 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Apr 14 02:38:25 2008 Subject: [sldev] [AWG] Comments on SLGOGP Draft 1 In-Reply-To: <480289C2.5010703@hippygeek.co.uk> References: <480289C2.5010703@hippygeek.co.uk> Message-ID: <480324E8.9060305@gmail.com> Ben Francis wrote: > > It seems odd to discuss open standards for the 3D Web without > mentioning the Web3D Consortium [10] and X3D. Are there > representatives from Web3D involved in the discussions and how would > X3D fit into this proposed architecture? Virtual Worlds like Second Life, don't really have any relationship with the 3D Web closer than maybe second cousins. Just as you could say that databases and the Web have many similarities, but are very different tracks with different audiences, targets and task-specific uses. Essentially, as I understand it, the AWG and the 3D Web people are working towards different goals that are often confused with each-other as they may share many technologies and protocols, and fulfill some of each-other's targets. From tofu.linden at lindenlab.com Mon Apr 14 03:29:39 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Apr 14 03:29:38 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on thewiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com><480084CD .6060000@gmail.com> <4800A0FE.8050201@gmx.net> Message-ID: <48033213.9050306@lindenlab.com> Soft wrote: > For now, I'll match up to the same compiler toolchain used to build > the released viewer, which is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) > (yes, I know!) and ensure the open source build is good there. The released viewer actually uses... gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13sarge1) From phli.foxchase at gmail.com Mon Apr 14 03:58:17 2008 From: phli.foxchase at gmail.com (Phli Foxchase) Date: Mon Apr 14 03:58:48 2008 Subject: [sldev] Why VWR-5366 is still unasigned ? Message-ID: <388c3cc90804140358k7ef24061l30ed780f263b24a0@mail.gmail.com> Ok, I have an easy question about this bug : VWR-5366 Dragging Custom Color to Color Swatch Overriden by grab/move dialog action This bug: - is a major bug - is in 1.19.1 and in 1.20 - was found one month ago - has 62 votes - can easily be repro - can easily be fixed (I think) So why no Linden assigned it or posted on it at least ? Thank you very much and best regards. Phli Foxchase -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080414/50a0fe74/attachment.htm From phli.foxchase at gmail.com Mon Apr 14 03:58:17 2008 From: phli.foxchase at gmail.com (Phli Foxchase) Date: Mon Apr 14 03:58:59 2008 Subject: [sldev] Why VWR-5366 is still unasigned ? Message-ID: <388c3cc90804140358k7ef24061l30ed780f263b24a0@mail.gmail.com> Ok, I have an easy question about this bug : VWR-5366 Dragging Custom Color to Color Swatch Overriden by grab/move dialog action This bug: - is a major bug - is in 1.19.1 and in 1.20 - was found one month ago - has 62 votes - can easily be repro - can easily be fixed (I think) So why no Linden assigned it or posted on it at least ? Thank you very much and best regards. Phli Foxchase -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080414/50a0fe74/attachment-0001.htm From robin.cornelius at gmail.com Mon Apr 14 04:16:11 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 14 04:16:15 2008 Subject: [sldev] Re: ETA for 1.20 source and supporting archives on the wiki? In-Reply-To: References: <47FE1FE9.4050504@gmail.com> <480084CD.6060000@gmail.com> <4800A0FE.8050201@gmx.net> Message-ID: On Sat, Apr 12, 2008 at 3:15 PM, Soft wrote: > On Sat, Apr 12, 2008 at 6:46 AM, Carsten Juttner wrote: > > Robin Cornelius wrote: > > > > > The only thing i can think of for your problem is that your gcc and your > > > boost libraries don't match. > > > > > > > > > > I built against the system boost libs, too and also only changed the > > libnames as Robin did and it gave me no trouble (on x86_64). > > > > Could it be a bug in the linker triggered by static linking? > > Possible. Poppy Linden spotted this: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625 > > For now, I'll match up to the same compiler toolchain used to build > the released viewer, which is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) > (yes, I know!) and ensure the open source build is good there. If it's > all good, the only version I'm going to worry about past that is gcc > 4.1, which carries the fix to the above issue. I'd like us to be more > ready for whenever the hell we get off Debian Sarge, anyway. There is nothing wrong with tracking a stable distro ;-). Are you going to bump up to etch, or possibly lenny if that goes stable first? If possible try to track stable you only need to bump the build around every 1 - 1.5 years so it should not be too painful? I currently build my debs on etch but you have to watch out for the mesa glx libraries as they will burn you on etch so this has forced me to kind of specificy Lenny as minimum version. Probably the last thing you want is tracking unfrozen testing or unstable as your entire build may all *just stop* one day with out warning, especially when people suddenly change gcc or libc etc, or it may generate all sorts of other issues that are out of your control, where as with a reasonable stable distro to build against you can quickly identify any problem libs and backport anyway. Robin From secret.argent at gmail.com Mon Apr 14 06:06:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 14 06:06:39 2008 Subject: Croquet (Re: [sldev] [AWG] Comments on SLGOGP Draft 1) In-Reply-To: <48030F84.9010204@cox.net> References: <480289C2.5010703@hippygeek.co.uk> <48030F84.9010204@cox.net> Message-ID: <8ADB2668-1908-4AB3-9661-5EBF6A0A2A35@gmail.com> > There are other groups and organizations where Second Life isn't > the central focus which may be more what you are looking for in > that regard, such as Croquet/Qwak, Wonderland and so on, though of > course, each of them is more closed in some ways than Second Life > is expected to become. Croquet in particular is a fascinating design, one that I'm still working to understand. It seems to require complete trust from all parties since it seems to distribute arbitrary Squeak code to all the viewers. I'm not sure how it avoids erroneous messages being inadvertently reinjected with inconsistent timestamps by a single instance of croquet code, except by careful coding of the objects themselves. I don't think there's any intent that Croquet work in an insecure environment. In any case, the way it's tied to a particular Smalltalk implementation seems to rule out it becoming an open system, but the distributed simulation model is well worth studying and learning from. It's really fascinating, and I recommend everyone here read the papers at least. From secret.argent at gmail.com Mon Apr 14 06:09:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 14 06:09:34 2008 Subject: [sldev] Why VWR-5366 is still unasigned ? In-Reply-To: <388c3cc90804140358k7ef24061l30ed780f263b24a0@mail.gmail.com> References: <388c3cc90804140358k7ef24061l30ed780f263b24a0@mail.gmail.com> Message-ID: <707E3747-5739-4269-9F27-FACAAECAC9DE@gmail.com> On 2008-04-14, at 05:58, Phli Foxchase wrote: > Ok, I have an easy question about this bug : VWR-5366 Dragging > Custom Color to Color Swatch Overriden by grab/move dialog action [...] > So why no Linden assigned it or posted on it at least ? Given that this is the open source mailing list, a better question might be "has anyone here looked at it?" :) From lenglish5 at cox.net Mon Apr 14 08:25:16 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Apr 14 08:25:18 2008 Subject: Croquet (Re: [sldev] [AWG] Comments on SLGOGP Draft 1) In-Reply-To: <8ADB2668-1908-4AB3-9661-5EBF6A0A2A35@gmail.com> References: <480289C2.5010703@hippygeek.co.uk> <48030F84.9010204@cox.net> <8ADB2668-1908-4AB3-9661-5EBF6A0A2A35@gmail.com> Message-ID: <4803775C.8070604@cox.net> Argent Stonecutter wrote: >> There are other groups and organizations where Second Life isn't the >> central focus which may be more what you are looking for in that >> regard, such as Croquet/Qwak, Wonderland and so on, though of course, >> each of them is more closed in some ways than Second Life is expected >> to become. > > Croquet in particular is a fascinating design, one that I'm still > working to understand. It seems to require complete trust from all > parties since it seems to distribute arbitrary Squeak code to all the > viewers. I'm not sure how it avoids erroneous messages being > inadvertently reinjected with inconsistent timestamps by a single > instance of croquet code, except by careful coding of the objects > themselves. All objects in Croquet are of class TObject which takes care of all this stuff at that level, so unless TObject is buggy, that shouldn't be an issue. > > I don't think there's any intent that Croquet work in an insecure > environment. > There is a hack solution for it (perhaps it is more mature now) where certain data/objects can be kept private to a given client, but when I was looking at trying to integrate SL group IM with Croquet, the best solution seemed to be to keep IM completely out of the Croquet world. That seemed to be the suggestion for normal Croquet users as well: if you needed to hold a private IM session, code it outside the Croquet environment. I gave up on the project when I learned that using Croquet on a Mac over the internet made it almost impossible to link up with another Croquet user. The few times we managed to, it tended to freeze/crash within a few seconds. I'm sure things have improved in the past 7 months but don't know how much. > In any case, the way it's tied to a particular Smalltalk > implementation seems to rule out it becoming an open system, but the > distributed simulation model is well worth studying and learning from. > It's really fascinating, and I recommend everyone here read the papers > at least. > There's an active Croquet developers list also thought not nearly as active as the Squeak list itself. Lawson From sammy.frederix at gmail.com Tue Apr 15 00:12:34 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Tue Apr 15 00:12:43 2008 Subject: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <48024F3B.3060701@gmx.net> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com> <48021690.4060203@gmx.net> <48024F3B.3060701@gmx.net> Message-ID: <0A55EB24-A505-42F1-9E0E-E65662485503@gmail.com> On 14/04/2008, at 4:21 AM, Carsten Juttner wrote: > Aimee Walton wrote: >> On Apr 13, 2008, at 15:20, Carsten Juttner wrote: >>> I know that it wasn't the case before since I always mess up the >>> options (too used to the convention of prefixing "--" to long >>> command options) >> ... which is now correct it seems :) >> Ah, great :) > The command line parsing was switched to boost::program_options so > it is obviously more flexible now. Though after a quick look through the Boost documentation, I didn't see a way of telling it to ignore -psn_0_.... paramaters. Does anyone know if this can be fixed in Boost, or will I need to strip the PSN out of argv before boost parses the command line? From tofu.linden at lindenlab.com Tue Apr 15 02:18:36 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Apr 15 02:18:38 2008 Subject: [patch] Re: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <0A55EB24-A505-42F1-9E0E-E65662485503@gmail.com> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com><48021690.4060203@gmx.net ><48024F3B.3060701@gmx.net> <0A55EB24-A505-42F1-9E0E-E65662485503@gmail.com> Message-ID: <480472EC.3010305@lindenlab.com> Mani Linden committed the attached patch recently. Hope it helps. Sammy Frederix wrote: > On 14/04/2008, at 4:21 AM, Carsten Juttner wrote: >> Aimee Walton wrote: >>> On Apr 13, 2008, at 15:20, Carsten Juttner wrote: >>>> I know that it wasn't the case before since I always mess up the >>>> options (too used to the convention of prefixing "--" to long >>>> command options) >>> ... which is now correct it seems :) >>> Ah, great :) >> The command line parsing was switched to boost::program_options so it >> is obviously more flexible now. > > Though after a quick look through the Boost documentation, I didn't see > a way of telling it to ignore -psn_0_.... paramaters. > > Does anyone know if this can be fixed in Boost, or will I need to strip > the PSN out of argv before boost parses the command line? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: psn.patch Type: text/x-patch Size: 7956 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080415/a50cb83d/psn.bin From soft at lindenlab.com Tue Apr 15 14:40:46 2008 From: soft at lindenlab.com (Soft) Date: Tue Apr 15 14:40:47 2008 Subject: [sldev] 1.20 RC1 source Message-ID: 1.20 RC1 with 100% less pain than RC0: Snapshot of internal branch Branch_1-20-Viewer Last Changed Rev: 84760 Last Changed Date: 2008-04-14 12:23:11 -0700 (Mon, 14 Apr 2008) Supplementary files: http://secondlife.com/developers/opensource/downloads/2008/04/md5sums-Branch_1-20-Viewer-r84760.txt http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-artwork-Branch_1-20-Viewer-r84760.zip http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-darwin-libs-Branch_1-20-Viewer-r84760.tar.gz http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-win32-libs-Branch_1-20-Viewer-r84760.zip http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-linux-libs-Branch_1-20-Viewer-r84760.tar.gz Source tarballs http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.tar.gz http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.zip From sldev at free.fr Tue Apr 15 14:49:05 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 15 14:49:08 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: References: Message-ID: <20080415234905.76067b55.sldev@free.fr> On Tue, 15 Apr 2008 16:40:46 -0500, Soft wrote: > 1.20 RC1 with 100% less pain than RC0: 100% less pain also happens when you get shot in the head... No time left to suffer. ;-P The binaries for the RC1 as made available for Linux crash at once with a glibc runtime error: *** glibc detected *** bin/do-not-directly-run-secondlife-bin: free(): invalid pointer: 0x0adbc660 *** Bad luck... From tom at streamsense.net Tue Apr 15 15:22:01 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Apr 15 15:22:16 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: References: Message-ID: <48052A89.1040208@streamsense.net> Soft wrote: > 1.20 RC1 with 100% less pain than RC0: > > Any word from your Solaris dev as to the GL problem he encountered? ~Tom From soft at lindenlab.com Tue Apr 15 15:52:22 2008 From: soft at lindenlab.com (Soft) Date: Tue Apr 15 15:52:25 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: <20080415234905.76067b55.sldev@free.fr> References: <20080415234905.76067b55.sldev@free.fr> Message-ID: On Tue, Apr 15, 2008 at 4:49 PM, Henri Beauchamp wrote: > On Tue, 15 Apr 2008 16:40:46 -0500, Soft wrote: > > > 1.20 RC1 with 100% less pain than RC0: > > 100% less pain also happens when you get shot in the head... > No time left to suffer. ;-P > > The binaries for the RC1 as made available for Linux crash > at once with a glibc runtime error: > > *** glibc detected *** bin/do-not-directly-run-secondlife-bin: free(): invalid pointer: 0x0adbc660 *** Yanking these while I find out what's up. Looks like the actual release has the same problem on Linux right now. From sammy.frederix at gmail.com Tue Apr 15 16:02:32 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Tue Apr 15 16:02:46 2008 Subject: [patch] Re: [sldev] Error:unknown option -p when compiling out of the box on Mac In-Reply-To: <480472EC.3010305@lindenlab.com> References: <3D1BB2F1-FCE0-45C5-97ED-566162135666@ama-zing.co.uk> <2D477491-95B3-46C5-96AD-A702DC47105C@gmail.com> <35D56373-36EC-423F-AAAC-8D998242CE56@gmail.com><48021690.4060203@gmx.net ><48024F3B.3060701@gmx.net> <0A55EB24-A505-42F1-9E0E-E65662485503@gmail.com> <480472EC.3010305@lindenlab.com> Message-ID: <8F59E7D9-2150-4640-B351-CE30728E7589@gmail.com> Thanks Tofu. Sadly I didn't get a chance to apply the patch before 1.20 RC1 came out, but it's defiantly fixed that version of the source. On 15/04/2008, at 7:18 PM, Tofu Linden wrote: > Mani Linden committed the attached patch recently. Hope it helps. > > Sammy Frederix wrote: >> On 14/04/2008, at 4:21 AM, Carsten Juttner wrote: >>> Aimee Walton wrote: >>>> On Apr 13, 2008, at 15:20, Carsten Juttner wrote: >>>>> I know that it wasn't the case before since I always mess up the >>>>> options (too used to the convention of prefixing "--" to long >>>>> command options) >>>> ... which is now correct it seems :) >>>> Ah, great :) >>> The command line parsing was switched to boost::program_options so >>> it is obviously more flexible now. >> Though after a quick look through the Boost documentation, I didn't >> see a way of telling it to ignore -psn_0_.... paramaters. >> Does anyone know if this can be fixed in Boost, or will I need to >> strip the PSN out of argv before boost parses the command line? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From matthew.dowd at hotmail.co.uk Wed Apr 16 04:44:20 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 16 04:44:22 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: References: Message-ID: The win32 libs link keeps giving me a 404 error. Matthew> Date: Tue, 15 Apr 2008 16:40:46 -0500> From: soft@lindenlab.com> To: sldev@lists.secondlife.com> Subject: [sldev] 1.20 RC1 source> > 1.20 RC1 with 100% less pain than RC0:> > Snapshot of internal branch Branch_1-20-Viewer> Last Changed Rev: 84760> Last Changed Date: 2008-04-14 12:23:11 -0700 (Mon, 14 Apr 2008)> > Supplementary files:> http://secondlife.com/developers/opensource/downloads/2008/04/md5sums-Branch_1-20-Viewer-r84760.txt> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-artwork-Branch_1-20-Viewer-r84760.zip> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-darwin-libs-Branch_1-20-Viewer-r84760.tar.gz> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-win32-libs-Branch_1-20-Viewer-r84760.zip> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-linux-libs-Branch_1-20-Viewer-r84760.tar.gz> > Source tarballs> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.tar.gz> http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.zip> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldevT 2ib link is giving me a 404 error! Matthew _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080416/27c4c8d9/attachment.htm From soft at lindenlab.com Wed Apr 16 04:51:52 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 16 04:51:54 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: References: Message-ID: Yes, we're re-dropping all three platforms once we've sorted out the Linux issue here. Hold tight... On Wed, Apr 16, 2008 at 6:44 AM, Matthew Dowd wrote: > > The win32 libs link keeps giving me a 404 error. > > Matthew > > > Date: Tue, 15 Apr 2008 16:40:46 -0500 > > From: soft@lindenlab.com > > To: sldev@lists.secondlife.com > > Subject: [sldev] 1.20 RC1 source > > > > > > 1.20 RC1 with 100% less pain than RC0: > > > > Snapshot of internal branch Branch_1-20-Viewer > > Last Changed Rev: 84760 > > Last Changed Date: 2008-04-14 12:23:11 -0700 (Mon, 14 Apr 2008) > > > > Supplementary files: > > > http://secondlife.com/developers/opensource/downloads/2008/04/md5sums-Branch_1-20-Viewer-r84760.txt > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-artwork-Branch_1-20-Viewer-r84760.zip > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-darwin-libs-Branch_1-20-Viewer-r84760.tar.gz > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-win32-libs-Branch_1-20-Viewer-r84760.zip > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-linux-libs-Branch_1-20-Viewer-r84760.tar.gz > > > > Source tarballs > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.tar.gz > > > http://secondlife.com/developers/opensource/downloads/2008/04/slviewer-src-Branch_1-20-Viewer-r84760.zip > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > T 2ib link is giving me a 404 error! > > Matthew > > ________________________________ > A prize an hour, 24 hours a day. Try Big Snap now! From Dana.Fagerstrom at Sun.COM Wed Apr 16 05:01:13 2008 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Wed Apr 16 05:01:21 2008 Subject: [sldev] 1.20 RC1 source In-Reply-To: <48052A89.1040208@streamsense.net> References: <48052A89.1040208@streamsense.net> Message-ID: <4805EA89.7030608@sun.com> > Any word from your Solaris dev as to the GL problem he encountered? Tom, I'm seeing the same problem as everyone else. I was able to log in once and walk around but subsequent logins crash immediately. One observation I've made is that once we step into libGL the stack addresses appear to be cyclic. That is to say there is a pattern of several function addresses that get repeated. It crashes because it eventually steps beyond stack limits. The plan for later today is to take Soft's updates and the latest nvidia driver & libGL to see what happens. BTW, for those interested, pkgs for 1.19.1.4 on Solaris are at: Solaris 10: https://solaris-sl-viewer.s3.amazonaws.com/SecondLife_i686_1_19_1_4-2008Apr07-s10.pkg.bz2 OpenSolaris/Nevada: https://solaris-sl-viewer.s3.amazonaws.com/SecondLife_i686_1_19_1_4-2008Apr07-snv.pkg.bz2 Cheers, D/Whoops From alexander.treptow at zweitgeist.com Wed Apr 16 07:35:52 2008 From: alexander.treptow at zweitgeist.com (alexander.treptow) Date: Wed Apr 16 07:36:01 2008 Subject: [sldev] Authorization with old login code Message-ID: <48060EC8.4070109@zweitgeist.com> Hi, i got an edited Second Life Viewer 1.18.2(1) so it uses the old / current login code. But now i cant connect to the grid, i get no login error. i only get a reason and a message. reason_response: "update" message_response: "Required Version: 1.19.1.4" Is this a known problem and how i can solve it, out of using a different codebase i.e. 1.19.*? To ignore the message dont solve it because the server dont send any ids with this message. so i cant work any further. thanks for help, greets, Alex From robin.cornelius at gmail.com Wed Apr 16 07:42:08 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 16 07:42:11 2008 Subject: [sldev] Authorization with old login code In-Reply-To: <48060EC8.4070109@zweitgeist.com> References: <48060EC8.4070109@zweitgeist.com> Message-ID: On Wed, Apr 16, 2008 at 3:35 PM, alexander.treptow wrote: > Hi, > i got an edited Second Life Viewer 1.18.2(1) so it uses the old / current > login code. But now i cant connect to the grid, i get no login error. i only > get a reason and a message. > > reason_response: "update" > message_response: "Required Version: 1.19.1.4" Change the channel the viewer connects with, you can do this as a command line parameter or edit llviewerversion.h and rebuild. If you connect on offical linden channel and you are not at required minimum version you will get an update message Robin From xotmid at gmail.com Wed Apr 16 07:55:33 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Wed Apr 16 07:55:46 2008 Subject: [sldev] MONO: region request. In-Reply-To: <47FCF6FF.2010802@lindenlab.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> Message-ID: Trying to get on to the beta grid for office hours but not able to log in, anyone else having issues? On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden wrote: > Yes, Tateru, as you say there are two different runtimes, LSL2 and Mono. > At launch the Mono runtime will be completely "opt-in": any LSL script that > you created or have modify permission for may be compiled to Mono. From then > on the script will run only under Mono (unless recompiled again back to > LSL2). We need this opt-in paradigm because although Mono is feature > compatible with LSL2, the same script will have different behaviors and > characteristics depending on which runtime it uses. The simple performance > differences between the two runtimes mean that scripts change behavior, and > may need modification to be useful when they switch to Mono. > > Thus in order to not break existing content, we want to ship with both > runtimes, and keep Mono opt-in. Eventually we may turn off compilation to > LSL2 bytecode. This will make Mono automatic for all new script content, > however we are unlikely to turn off the LSL2 runtime on the entire grid. > There are simply too many scripts, actively running in the world, whose > creators have left SL or who don't want to QA and release a Mono version. > > The idea which started this thread was a suggestion to allow estate or > parcel owners the ability to selectively turn off only the LSL2 runtime. > This would mean that scripted attachments using LSL2 would silently fail to > run, much like the way the current "no scripts" switch works, but only for > LSL2. I see merit in the suggestion, but I think it's simply too early to > know if such a feature would be truly useful. Mono definitely improves the > performance dramatically for scripts that do a lot of math, but has much > more humble returns for simple scripts like AOs or attachment size/color > modders. After Mono launches market pressure will develop to encourage > scripters to make Mono versions available for those calculation intensive > scripts that most benefit from Mono. This process, a kind of natural > selection, may obviate the utility of a selective LSL2 disabler. Let's > discuss this feature again after we see how Mono is adopted post launch. > > Any who want more details on our current thinking, plans, or who want to > discuss this feature request, or propose others, are welcome to attend our > Mono office hours. See the Mono betawiki page for the schedule. > > > Tateru Nino wrote: > > Robin Cornelius wrote: > > On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford wrote: > > > > I don't see why this is something that couldn't at least be considered. > Something like an option in the region estate tools "Enable LSL2 Runtime > for region" and "Enable Mono Runtime for region" with tick boxes and > such. > > > > > I though, but am probably wrong, that the mono runtime emulates the > lsl2 runtime for mono regions so that lsl2 on a mono region is > basically wrapped my mono and i recall (but again may have imagined) > that even doing this was faster than the native lsl2 engine. > > Please correct me if i have gone mad. > > > Two different runtimes. One for LSL source compiled to Mono bytecode and > one for LSL source compiled to LSL2 bytecode. That, as I understand it, is > where we're headed in the near-term. Each sim having two script runtimes. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080416/20a221eb/attachment.htm From tateru.nino at gmail.com Wed Apr 16 07:56:21 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 16 08:01:20 2008 Subject: [sldev] MONO: region request. In-Reply-To: References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> Message-ID: <48061395.2090706@weblogsinc.com> A lot of people tell me they're having login problems with certain viewer versions. It's all anecdotal at the moment, though. Just under a hundred or so reports, which isn't statistically huge. Brandon Husbands wrote: > Trying to get on to the beta grid for office hours but not able to log > in, anyone else having issues? > > On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden > > wrote: > > Yes, Tateru, as you say there are two different runtimes, LSL2 and > Mono. At launch the Mono runtime will be completely "opt-in": any > LSL script that you created or have modify permission for may be > compiled to Mono. From then on the script will run only under Mono > (unless recompiled again back to LSL2). We need this opt-in > paradigm because although Mono is feature compatible with LSL2, > the same script will have different behaviors and characteristics > depending on which runtime it uses. The simple performance > differences between the two runtimes mean that scripts change > behavior, and may need modification to be useful when they switch > to Mono. > > Thus in order to not break existing content, we want to ship with > both runtimes, and keep Mono opt-in. Eventually we may turn off > compilation to LSL2 bytecode. This will make Mono automatic for > all new script content, however we are unlikely to turn off the > LSL2 runtime on the entire grid. There are simply too many > scripts, actively running in the world, whose creators have left > SL or who don't want to QA and release a Mono version. > > The idea which started this thread was a suggestion to allow > estate or parcel owners the ability to selectively turn off only > the LSL2 runtime. This would mean that scripted attachments using > LSL2 would silently fail to run, much like the way the current "no > scripts" switch works, but only for LSL2. I see merit in the > suggestion, but I think it's simply too early to know if such a > feature would be truly useful. Mono definitely improves the > performance dramatically for scripts that do a lot of math, but > has much more humble returns for simple scripts like AOs or > attachment size/color modders. After Mono launches market pressure > will develop to encourage scripters to make Mono versions > available for those calculation intensive scripts that most > benefit from Mono. This process, a kind of natural selection, may > obviate the utility of a selective LSL2 disabler. Let's discuss > this feature again after we see how Mono is adopted post launch. > > Any who want more details on our current thinking, plans, or who > want to discuss this feature request, or propose others, are > welcome to attend our Mono office hours. See the Mono beta > wiki page for the > schedule. > > > > Tateru Nino wrote: >> Robin Cornelius wrote: >>> On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford >>> >>> wrote: >>> >>> >>>> I don't see why this is something that couldn't at least be >>>> considered. >>>> Something like an option in the region estate tools "Enable >>>> LSL2 Runtime >>>> for region" and "Enable Mono Runtime for region" with tick >>>> boxes and such. >>>> >>>> >>> >>> I though, but am probably wrong, that the mono runtime emulates the >>> lsl2 runtime for mono regions so that lsl2 on a mono region is >>> basically wrapped my mono and i recall (but again may have >>> imagined) >>> that even doing this was faster than the native lsl2 engine. >>> >>> Please correct me if i have gone mad. >>> >> Two different runtimes. One for LSL source compiled to Mono >> bytecode and one for LSL source compiled to LSL2 bytecode. That, >> as I understand it, is where we're headed in the near-term. Each >> sim having two script runtimes. >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From alexander.treptow at zweitgeist.com Wed Apr 16 08:16:00 2008 From: alexander.treptow at zweitgeist.com (alexander.treptow) Date: Wed Apr 16 08:16:09 2008 Subject: [sldev] Authorization with old login code In-Reply-To: References: <48060EC8.4070109@zweitgeist.com> Message-ID: <48061830.7060505@zweitgeist.com> Thanks for that fast help, it works ;) Alex ---------- > On Wed, Apr 16, 2008 at 3:35 PM, alexander.treptow > wrote: > >> Hi, >> i got an edited Second Life Viewer 1.18.2(1) so it uses the old / current >> login code. But now i cant connect to the grid, i get no login error. i only >> get a reason and a message. >> >> reason_response: "update" >> message_response: "Required Version: 1.19.1.4" >> > > Change the channel the viewer connects with, you can do this as a > command line parameter or edit llviewerversion.h and rebuild. If you > connect on offical linden channel and you are not at required minimum > version you will get an update message > > Robin > From periapse at lindenlab.com Wed Apr 16 10:33:53 2008 From: periapse at lindenlab.com (Periapse Linden) Date: Wed Apr 16 10:33:57 2008 Subject: [sldev] MONO: region request. In-Reply-To: <48061395.2090706@weblogsinc.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> <48061395.2090706@weblogsinc.com> Message-ID: <48063881.8050504@lindenlab.com> I'll check this out. I also am getting reports by various adult and TG residents of login issues. This is complicated by the fact that the aditi backbone was down until Babbage discovered it before the morning Mono office hour and fixed it. However I've heard reports even since then of people still being unable to successfully log in with the beta viewer, however they *can* log in to the beta grid using a Release or RC viewer. In all cases so far these are people who recently downloaded the beta viewer (as in last couple of days). I've not heard of problems from people who downloaded the beta viewer more than a week ago. It's possible that something got wedged. On Friday the aging 1.18.6.77968 beta viewer was replaced with one built off of the 1.20 codebase. Sadly, that new viewer lacked the Mono UI. The beta viewer download has been reverted back to the 1.18.6.77968 one, but maybe some setting got missed. I will re-download and install the beta viewer and try to dupe the problems I've been hearing about. --Periapse Tateru Nino wrote: > A lot of people tell me they're having login problems with certain > viewer versions. It's all anecdotal at the moment, though. Just under > a hundred or so reports, which isn't statistically huge. > > Brandon Husbands wrote: >> Trying to get on to the beta grid for office hours but not able to >> log in, anyone else having issues? >> >> On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden >> > wrote: >> >> Yes, Tateru, as you say there are two different runtimes, LSL2 and >> Mono. At launch the Mono runtime will be completely "opt-in": any >> LSL script that you created or have modify permission for may be >> compiled to Mono. From then on the script will run only under Mono >> (unless recompiled again back to LSL2). We need this opt-in >> paradigm because although Mono is feature compatible with LSL2, >> the same script will have different behaviors and characteristics >> depending on which runtime it uses. The simple performance >> differences between the two runtimes mean that scripts change >> behavior, and may need modification to be useful when they switch >> to Mono. >> >> Thus in order to not break existing content, we want to ship with >> both runtimes, and keep Mono opt-in. Eventually we may turn off >> compilation to LSL2 bytecode. This will make Mono automatic for >> all new script content, however we are unlikely to turn off the >> LSL2 runtime on the entire grid. There are simply too many >> scripts, actively running in the world, whose creators have left >> SL or who don't want to QA and release a Mono version. >> >> The idea which started this thread was a suggestion to allow >> estate or parcel owners the ability to selectively turn off only >> the LSL2 runtime. This would mean that scripted attachments using >> LSL2 would silently fail to run, much like the way the current "no >> scripts" switch works, but only for LSL2. I see merit in the >> suggestion, but I think it's simply too early to know if such a >> feature would be truly useful. Mono definitely improves the >> performance dramatically for scripts that do a lot of math, but >> has much more humble returns for simple scripts like AOs or >> attachment size/color modders. After Mono launches market pressure >> will develop to encourage scripters to make Mono versions >> available for those calculation intensive scripts that most >> benefit from Mono. This process, a kind of natural selection, may >> obviate the utility of a selective LSL2 disabler. Let's discuss >> this feature again after we see how Mono is adopted post launch. >> >> Any who want more details on our current thinking, plans, or who >> want to discuss this feature request, or propose others, are >> welcome to attend our Mono office hours. See the Mono beta >> wiki page for the >> schedule. >> >> >> >> Tateru Nino wrote: >>> Robin Cornelius wrote: >>>> On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford >>>> >>>> wrote: >>>> >>>> >>>>> I don't see why this is something that couldn't at least be >>>>> considered. >>>>> Something like an option in the region estate tools "Enable >>>>> LSL2 Runtime >>>>> for region" and "Enable Mono Runtime for region" with tick >>>>> boxes and such. >>>>> >>>>> >>>> >>>> I though, but am probably wrong, that the mono runtime emulates >>>> the >>>> lsl2 runtime for mono regions so that lsl2 on a mono region is >>>> basically wrapped my mono and i recall (but again may have >>>> imagined) >>>> that even doing this was faster than the native lsl2 engine. >>>> >>>> Please correct me if i have gone mad. >>>> >>> Two different runtimes. One for LSL source compiled to Mono >>> bytecode and one for LSL source compiled to LSL2 bytecode. That, >>> as I understand it, is where we're headed in the near-term. Each >>> sim having two script runtimes. >>> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From gigstaggart at gmail.com Wed Apr 16 12:02:48 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 16 12:02:53 2008 Subject: [sldev] sljirastats.com Linden Metrics Report Message-ID: <48064D58.5050003@gmail.com> Sljirastats.com is now several months old. Here are some interesting damn lies. Unresolved Issues (Bug and Feature) by project: VWR - 2910/6490 - 45% Unresolved SVC - 1239/2156 - 57% Unresolved WEB - 286/607 - 47% Unresolved MISC - 310/952 - 33% Unresolved SVC is the least effective project, WEB is the second worst. "Open" bugs have been on a steady climb. It started at 1547 when sljirastats.com began collecting data, and is now at 2717. This means we are averaging 8.6 additional unresolved bugs per day. This is after subtracting fixed and resolved issues. This number is a critical metric; Linden Lab is falling more and more behind every day. "Fixed Internally" has bounced around, reaching a low of about 90 issues, and is near its high right now of 140 issues. No significant trend has been observed in Fixed Internally issues. "Open Patches" started around 70, climbed to about 110, and plateaued there for several months. In the last few days about 10 patches have been resolved. 78 unresolved patches are more than 3 months old. 34 unresolved patches are more than 6 months old -23 of which are bug patches. Importation of bugs seems to be going on at a steady clip, however actual resolution of the bugs seems to be slow going. Peaks are correlated across the board with the release of new major feature branches, such as Windlight, Mono, Havok4. The week after a major feature branch comes out, we see a spike of about 100 additional issues. SVC-472 and SVC-85 remain the most hated bugs, for most of the time that sljirastats has existed. Likewise, MISC-208 is the highest voted feature request for many months, by a huge margin. -Jason From josh at lindenlab.com Wed Apr 16 13:36:36 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Apr 16 13:36:53 2008 Subject: [sldev] MONO: region request. In-Reply-To: <48063881.8050504@lindenlab.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> <48061395.2090706@weblogsinc.com> <48063881.8050504@lindenlab.com> Message-ID: <48066354.2020308@lindenlab.com> There was also a glitch where expired presence wasn't being cleared properly on the beta grid, which has been fixed. That may have been contributing to the troubles as well. Periapse Linden wrote: > I'll check this out. I also am getting reports by various adult and TG > residents of login issues. This is complicated by the fact that the > aditi backbone was down until Babbage discovered it before the morning > Mono office hour and fixed it. However I've heard reports even since > then of people still being unable to successfully log in with the beta > viewer, however they *can* log in to the beta grid using a Release or RC > viewer. In all cases so far these are people who recently downloaded the > beta viewer (as in last couple of days). I've not heard of problems from > people who downloaded the beta viewer more than a week ago. > > It's possible that something got wedged. On Friday the aging > 1.18.6.77968 beta viewer was replaced with one built off of the 1.20 > codebase. Sadly, that new viewer lacked the Mono UI. The beta viewer > download has been reverted back to the 1.18.6.77968 one, but maybe some > setting got missed. I will re-download and install the beta viewer and > try to dupe the problems I've been hearing about. > > --Periapse > > Tateru Nino wrote: > >> A lot of people tell me they're having login problems with certain >> viewer versions. It's all anecdotal at the moment, though. Just under >> a hundred or so reports, which isn't statistically huge. >> >> Brandon Husbands wrote: >> >>> Trying to get on to the beta grid for office hours but not able to >>> log in, anyone else having issues? >>> >>> On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden >>> > wrote: >>> >>> Yes, Tateru, as you say there are two different runtimes, LSL2 and >>> Mono. At launch the Mono runtime will be completely "opt-in": any >>> LSL script that you created or have modify permission for may be >>> compiled to Mono. From then on the script will run only under Mono >>> (unless recompiled again back to LSL2). We need this opt-in >>> paradigm because although Mono is feature compatible with LSL2, >>> the same script will have different behaviors and characteristics >>> depending on which runtime it uses. The simple performance >>> differences between the two runtimes mean that scripts change >>> behavior, and may need modification to be useful when they switch >>> to Mono. >>> >>> Thus in order to not break existing content, we want to ship with >>> both runtimes, and keep Mono opt-in. Eventually we may turn off >>> compilation to LSL2 bytecode. This will make Mono automatic for >>> all new script content, however we are unlikely to turn off the >>> LSL2 runtime on the entire grid. There are simply too many >>> scripts, actively running in the world, whose creators have left >>> SL or who don't want to QA and release a Mono version. >>> >>> The idea which started this thread was a suggestion to allow >>> estate or parcel owners the ability to selectively turn off only >>> the LSL2 runtime. This would mean that scripted attachments using >>> LSL2 would silently fail to run, much like the way the current "no >>> scripts" switch works, but only for LSL2. I see merit in the >>> suggestion, but I think it's simply too early to know if such a >>> feature would be truly useful. Mono definitely improves the >>> performance dramatically for scripts that do a lot of math, but >>> has much more humble returns for simple scripts like AOs or >>> attachment size/color modders. After Mono launches market pressure >>> will develop to encourage scripters to make Mono versions >>> available for those calculation intensive scripts that most >>> benefit from Mono. This process, a kind of natural selection, may >>> obviate the utility of a selective LSL2 disabler. Let's discuss >>> this feature again after we see how Mono is adopted post launch. >>> >>> Any who want more details on our current thinking, plans, or who >>> want to discuss this feature request, or propose others, are >>> welcome to attend our Mono office hours. See the Mono beta >>> wiki page for the >>> schedule. >>> >>> >>> >>> Tateru Nino wrote: >>> >>>> Robin Cornelius wrote: >>>> >>>>> On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> I don't see why this is something that couldn't at least be >>>>>> considered. >>>>>> Something like an option in the region estate tools "Enable >>>>>> LSL2 Runtime >>>>>> for region" and "Enable Mono Runtime for region" with tick >>>>>> boxes and such. >>>>>> >>>>>> >>>>>> >>>>> I though, but am probably wrong, that the mono runtime emulates >>>>> the >>>>> lsl2 runtime for mono regions so that lsl2 on a mono region is >>>>> basically wrapped my mono and i recall (but again may have >>>>> imagined) >>>>> that even doing this was faster than the native lsl2 engine. >>>>> >>>>> Please correct me if i have gone mad. >>>>> >>>>> >>>> Two different runtimes. One for LSL source compiled to Mono >>>> bytecode and one for LSL source compiled to LSL2 bytecode. That, >>>> as I understand it, is where we're headed in the near-term. Each >>>> sim having two script runtimes. >>>> >>>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robla at lindenlab.com Wed Apr 16 13:40:06 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Apr 16 13:40:19 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48064D58.5050003@gmail.com> References: <48064D58.5050003@gmail.com> Message-ID: <48066426.9020807@lindenlab.com> Hi Gigs, This is great information. Thanks for compiling it. A couple of questions/comments below: On 4/16/08 12:02 PM, Jason Giglio wrote: > "Open" bugs have been on a steady climb. It started at 1547 when > sljirastats.com began collecting data, and is now at 2717. This means > we are averaging 8.6 additional unresolved bugs per day. This is after > subtracting fixed and resolved issues. This number is a critical > metric; Linden Lab is falling more and more behind every day. > How does this compare to other open source and public projects? My suspicion is that almost every active open source project experiences net positive growth in number of open bugs. I'd like to make sure we're not being measured against an unreasonably high standard. We have a resolution internally called "someday maybe", which is one I'm personally not a fan of (since the issue isn't "resolved", just acknowledged as a wart we're going to have to live with for a while). We've recently discussed making a matching PJIRA resolution, and concluded that a) we can't, because we still want to allow votes and b) we'd get a public flogging over it. The conclusion of that discussion is to represent that as "small" priority, possibly renaming "small" to "someday maybe", or adding a new "someday maybe" priority, and I'm hoping we can actually change our internal usage to match. > SVC-472 and SVC-85 remain the most hated bugs, for most of the time that > sljirastats has existed. > Hmmm....these are also somewhat subjective without clear victory conditions. While I'm guessing the team will acknowledge that these aren't yet running at an acceptable baseline, it also strikes me that these both describe symptoms with multiple and ever-changing causes of failure that will probably always be with us in some form from time to time. For both of these, I think we need to establish a victory condition that causes these issues to be closed and stay closed, to the point where a new issue gets opened if a problem with the same symptom occurs. Otherwise, these will automatically be at the top of the list every time they get reopened, despite the fact that other issues may actually be more pressing. What are good victory conditions for these? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080416/1b92083e/signature.pgp From monkowsk at watson.ibm.com Wed Apr 16 14:45:31 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 16 14:49:26 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48066426.9020807@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> Message-ID: <4806737B.3070105@watson.ibm.com> Rob Lanphier wrote: > On 4/16/08 12:02 PM, Jason Giglio wrote: >> "Open" bugs have been on a steady climb. It started at 1547 when >> sljirastats.com began collecting data, and is now at 2717. This means >> we are averaging 8.6 additional unresolved bugs per day. This is after >> subtracting fixed and resolved issues. This number is a critical >> metric; Linden Lab is falling more and more behind every day. > > How does this compare to other open source and public projects? My > suspicion is that almost every active open source project experiences > net positive growth in number of open bugs. I'd like to make sure we're > not being measured against an unreasonably high standard. I don't think being open source would *add* to the number of unresolved bugs. Why do you think it would? I worked for many years on a consumer software project with several million customers that had on the order of a hundred or so bugs at any given time. Bug fixes were considered the top priority. It was a matter of pride to have no open bugs related to your part of the code. Linden appears to have a *very* different attitude. > We have a resolution internally called "someday maybe", which is one I'm > personally not a fan of (since the issue isn't "resolved", just > acknowledged as a wart we're going to have to live with for a while). > We've recently discussed making a matching PJIRA resolution, and > concluded that a) we can't, because we still want to allow votes and b) > we'd get a public flogging over it. The conclusion of that discussion > is to represent that as "small" priority, possibly renaming "small" to > "someday maybe", or adding a new "someday maybe" priority, and I'm > hoping we can actually change our internal usage to match. C'mon. "Someday maybe"? Right now that covers nearly all of the open issues. ;-) Mike From monkowsk at watson.ibm.com Wed Apr 16 14:27:51 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 16 15:06:36 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48066426.9020807@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> Message-ID: <48066F57.6090607@watson.ibm.com> Rob Lanphier wrote: >> SVC-472 and SVC-85 remain the most hated bugs, for most of the time that >> sljirastats has existed. > > Hmmm....these are also somewhat subjective without clear victory > conditions. While I'm guessing the team will acknowledge that these > aren't yet running at an acceptable baseline, it also strikes me that > these both describe symptoms with multiple and ever-changing causes of > failure that will probably always be with us in some form from time to > time. For both of these, I think we need to establish a victory > condition that causes these issues to be closed and stay closed, to the > point where a new issue gets opened if a problem with the same symptom > occurs. Otherwise, these will automatically be at the top of the list > every time they get reopened, despite the fact that other issues may > actually be more pressing. > > What are good victory conditions for these? Well, I read through SVC-85 and at no point did it appear to be even temporarily fixed. Usually after a Linden comment saying that "we think we fixed it" there was a response from the residents that "no, you didn't." A good victory condition would be a response the next day that said "yes, it works now." The friends list is either there or it's not. What is subjective about that? Mike Of course this doesn't affect me directly because I have no friends. :-) From monkowsk at watson.ibm.com Wed Apr 16 14:04:38 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 16 15:20:13 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48064D58.5050003@gmail.com> References: <48064D58.5050003@gmail.com> Message-ID: <480669E6.5080602@watson.ibm.com> Jason Giglio wrote: > "Fixed Internally" has bounced around, reaching a low of about 90 > issues, and is near its high right now of 140 issues. No significant > trend has been observed in Fixed Internally issues. > > "Open Patches" started around 70, climbed to about 110, and plateaued > there for several months. In the last few days about 10 patches have > been resolved. > > 78 unresolved patches are more than 3 months old. > 34 unresolved patches are more than 6 months old > -23 of which are bug patches. Jason, if you're still looking for comments on sljirastats, it would be useful to see the lists of issues in these categories. 1) All (Open/In Progress/Fixed Internally) issues (Bugs and New Features) with patches. 2) All (In Progress/Fixed Internally) issues (Bugs and New Features) (1) is useful for gathering patches that haven't made it into the source releases so we don't have to live with problems that have already been fixed. It also let's us see how long patches hang around before getting incorporated into the code. (2) is useful for knowing what's in the pipeline and LL might use it to close PJIRA issues that have been closed out on their internal JIRA. I still like looking through the Most Hated and Most Wanted. Thanks for doing this. > Importation of bugs seems to be going on at a steady clip, ... Now if we could just get them to import the bug *fixes* ;-) Mike From rdw at lindenlab.com Wed Apr 16 15:37:08 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Apr 16 15:37:11 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48066F57.6090607@watson.ibm.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <48066F57.6090607@watson.ibm.com> Message-ID: <48067F94.4040600@lindenlab.com> Mike Monkowski wrote: > Rob Lanphier wrote: >>> SVC-472 and SVC-85 remain the most hated bugs, for most of the time that >>> sljirastats has existed. >> >> Hmmm....these are also somewhat subjective without clear victory >> conditions. While I'm guessing the team will acknowledge that these >> aren't yet running at an acceptable baseline, it also strikes me that >> these both describe symptoms with multiple and ever-changing causes of >> failure that will probably always be with us in some form from time to >> time. For both of these, I think we need to establish a victory >> condition that causes these issues to be closed and stay closed, to >> the point where a new issue gets opened if a problem with the same >> symptom occurs. Otherwise, these will automatically be at the top of >> the list every time they get reopened, despite the fact that other >> issues may actually be more pressing. >> >> What are good victory conditions for these? > > Well, I read through SVC-85 and at no point did it appear to be even > temporarily fixed. Usually after a Linden comment saying that "we think > we fixed it" there was a response from the residents that "no, you > didn't." A good victory condition would be a response the next day that > said "yes, it works now." The friends list is either there or it's not. > What is subjective about that? For a start, it would be nice to split it into multiple bugs: - friends list shows (waiting) instead of friend name - friends list reports friend as offline who is actually online, or vice versa - blue notifications don't always pop up when friend goes online/offline I guess one could declare victory if they always worked for all observers. But it can be quite subjective to determine if your friend is online or not. Strangers could have confusingly similar names or avatars to your friends, there could be ghosts in the IM system, they could be "online" as far as the sim is concerned but their viewer just crashed, someone else could have their password and is logging in as them without their knowledge.... there's lots of cases where one could be confused enough to think the friends list is broken. Some of those have happened to me. So, having a victory condition of "nobody thinks its broken" seems like it would never be closed. Also, having broadly-worded bugs means that everything that is even tangentially related to the bug can keep it open. Let's say we fix the three parts of the bug and everyone agrees that they're fixed. Then the viewer gets a bug that occasionally fails to render friends in the friends list. This would be a completely different bug, and would require a completely different team to resolve, but SVC-85 is worded so broadly that it would be reopened and we'd waste days trying to debug the service side of things before realizing that it was a new bug in the viewer. So, yeah, that's what goes through my head when I think of that bug. I think we should close it in favor of a cluster of more specific bugs, but then there would be outcry that we unjustly crushed all the votes on SVC-85. -RYaN From johnniecarling at gmail.com Wed Apr 16 15:53:04 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Wed Apr 16 15:53:08 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806737B.3070105@watson.ibm.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com> Message-ID: <200804161853.04102.johnniecarling@gmail.com> On Wednesday 16 April 2008 05:45:31 pm Mike Monkowski wrote: > I worked for many years on a consumer software project with several > million customers that had on the order of a hundred or so bugs at any > given time. ?Bug fixes were considered the top priority. ?It was a > matter of pride to have no open bugs related to your part of the code. > Linden appears to have a *very* different attitude. Did your internal bug tracking system have to deal with things like this major viewer bug (VWR-6534) ? ;) Anyway, i wonder what the stats would look like if the signal to noise ratio was improved in the jira? -- Johnnie Carling From monkowsk at watson.ibm.com Wed Apr 16 16:07:31 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Apr 16 16:11:13 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48067F94.4040600@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <48066F57.6090607@watson.ibm.com> <48067F94.4040600@lindenlab.com> Message-ID: <480686B3.3000109@watson.ibm.com> Ryan Williams (Which) wrote: > So, yeah, that's what goes through my head when I think of that bug. I > think we should close it in favor of a cluster of more specific bugs, > but then there would be outcry that we unjustly crushed all the votes on > SVC-85. So don't close SVC-85 and add several more. Keep SVC-85 open, give it a title that specifically represents the major outstanding complaint (even if it's not the original complaint), add as many more as you want with other specific titles, show those as related issues, and modify the description appropriately, directing people to the other issues as well. For bonus points, copy over the relevant comments to the new issues. Mike From periapse at lindenlab.com Wed Apr 16 16:31:10 2008 From: periapse at lindenlab.com (Periapse Linden) Date: Wed Apr 16 16:31:13 2008 Subject: [sldev] MONO: region request. In-Reply-To: <48066354.2020308@lindenlab.com> References: <50362.86.10.79.229.1207744995.squirrel@webmail.terminaldischarge.net> <47FCCF77.9090709@weblogsinc.com> <47FCF6FF.2010802@lindenlab.com> <48061395.2090706@weblogsinc.com> <48063881.8050504@lindenlab.com> <48066354.2020308@lindenlab.com> Message-ID: <48068C3E.4080804@lindenlab.com> As Josh observes there were multiple issues with the beta grid today. I believe all are resolved now. Some of the login woes were due to backbone / presence issues. But the Teen issue was different. The beta viewer is based on 1.18.6 code, which includes the now vilified web-based login form. For teens to log on to the beta grid they had to specify a start location, one of two teen regions on aditi. But that smelly old viewer has a bug which improperly parses region specifications with spaces in the name. Yeah, we need a new beta grid viewer -- waiting until 1.20 stabilizes before we add the Mono UI to it for the beta grid. In the meantime Milo Linden simply added a telehub to the teen region. It now pulls them in automatically, without them having to use the broken specify region form. --Per Joshua Bell wrote: > There was also a glitch where expired presence wasn't being cleared > properly on the beta grid, which has been fixed. That may have been > contributing to the troubles as well. > > Periapse Linden wrote: >> I'll check this out. I also am getting reports by various adult and TG >> residents of login issues. This is complicated by the fact that the >> aditi backbone was down until Babbage discovered it before the morning >> Mono office hour and fixed it. However I've heard reports even since >> then of people still being unable to successfully log in with the beta >> viewer, however they *can* log in to the beta grid using a Release or RC >> viewer. In all cases so far these are people who recently downloaded the >> beta viewer (as in last couple of days). I've not heard of problems from >> people who downloaded the beta viewer more than a week ago. >> >> It's possible that something got wedged. On Friday the aging >> 1.18.6.77968 beta viewer was replaced with one built off of the 1.20 >> codebase. Sadly, that new viewer lacked the Mono UI. The beta viewer >> download has been reverted back to the 1.18.6.77968 one, but maybe some >> setting got missed. I will re-download and install the beta viewer and >> try to dupe the problems I've been hearing about. >> >> --Periapse >> >> Tateru Nino wrote: >> >>> A lot of people tell me they're having login problems with certain >>> viewer versions. It's all anecdotal at the moment, though. Just under >>> a hundred or so reports, which isn't statistically huge. >>> >>> Brandon Husbands wrote: >>> >>>> Trying to get on to the beta grid for office hours but not able to >>>> log in, anyone else having issues? >>>> >>>> On Wed, Apr 9, 2008 at 12:03 PM, Periapse Linden >>>> > wrote: >>>> >>>> Yes, Tateru, as you say there are two different runtimes, LSL2 and >>>> Mono. At launch the Mono runtime will be completely "opt-in": any >>>> LSL script that you created or have modify permission for may be >>>> compiled to Mono. From then on the script will run only under Mono >>>> (unless recompiled again back to LSL2). We need this opt-in >>>> paradigm because although Mono is feature compatible with LSL2, >>>> the same script will have different behaviors and characteristics >>>> depending on which runtime it uses. The simple performance >>>> differences between the two runtimes mean that scripts change >>>> behavior, and may need modification to be useful when they switch >>>> to Mono. >>>> >>>> Thus in order to not break existing content, we want to ship with >>>> both runtimes, and keep Mono opt-in. Eventually we may turn off >>>> compilation to LSL2 bytecode. This will make Mono automatic for >>>> all new script content, however we are unlikely to turn off the >>>> LSL2 runtime on the entire grid. There are simply too many >>>> scripts, actively running in the world, whose creators have left >>>> SL or who don't want to QA and release a Mono version. >>>> >>>> The idea which started this thread was a suggestion to allow >>>> estate or parcel owners the ability to selectively turn off only >>>> the LSL2 runtime. This would mean that scripted attachments using >>>> LSL2 would silently fail to run, much like the way the current "no >>>> scripts" switch works, but only for LSL2. I see merit in the >>>> suggestion, but I think it's simply too early to know if such a >>>> feature would be truly useful. Mono definitely improves the >>>> performance dramatically for scripts that do a lot of math, but >>>> has much more humble returns for simple scripts like AOs or >>>> attachment size/color modders. After Mono launches market pressure >>>> will develop to encourage scripters to make Mono versions >>>> available for those calculation intensive scripts that most >>>> benefit from Mono. This process, a kind of natural selection, may >>>> obviate the utility of a selective LSL2 disabler. Let's discuss >>>> this feature again after we see how Mono is adopted post launch. >>>> >>>> Any who want more details on our current thinking, plans, or who >>>> want to discuss this feature request, or propose others, are >>>> welcome to attend our Mono office hours. See the Mono beta >>>> wiki page for the >>>> schedule. >>>> >>>> >>>> >>>> Tateru Nino wrote: >>>> >>>>> Robin Cornelius wrote: >>>>> >>>>>> On Wed, Apr 9, 2008 at 1:43 PM, Nik Radford >>>>>> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> I don't see why this is something that couldn't at least be >>>>>>> considered. >>>>>>> Something like an option in the region estate tools "Enable >>>>>>> LSL2 Runtime >>>>>>> for region" and "Enable Mono Runtime for region" with tick >>>>>>> boxes and such. >>>>>>> >>>>>>> >>>>>> I though, but am probably wrong, that the mono runtime emulates >>>>>> the >>>>>> lsl2 runtime for mono regions so that lsl2 on a mono region is >>>>>> basically wrapped my mono and i recall (but again may have >>>>>> imagined) >>>>>> that even doing this was faster than the native lsl2 engine. >>>>>> >>>>>> Please correct me if i have gone mad. >>>>>> >>>>> Two different runtimes. One for LSL source compiled to Mono >>>>> bytecode and one for LSL source compiled to LSL2 bytecode. That, >>>>> as I understand it, is where we're headed in the near-term. Each >>>>> sim having two script runtimes. >>>>> >>>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Click here to unsubscribe or manage your list subscription: >>>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From robla at lindenlab.com Wed Apr 16 17:18:34 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Apr 16 17:18:41 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806737B.3070105@watson.ibm.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com> Message-ID: <4806975A.1010805@lindenlab.com> On 4/16/08 2:45 PM, Mike Monkowski wrote: > Rob Lanphier wrote: >> On 4/16/08 12:02 PM, Jason Giglio wrote: >>> "Open" bugs have been on a steady climb. It started at 1547 when >>> sljirastats.com began collecting data, and is now at 2717. This means >>> we are averaging 8.6 additional unresolved bugs per day. This is after >>> subtracting fixed and resolved issues. This number is a critical >>> metric; Linden Lab is falling more and more behind every day. >> >> How does this compare to other open source and public projects? My >> suspicion is that almost every active open source project experiences >> net positive growth in number of open bugs. I'd like to make sure >> we're not being measured against an unreasonably high standard. > > I don't think being open source would *add* to the number of > unresolved bugs. Why do you think it would? Because anyone can file issues, and you can't get the people who disagree about whether an issue is really an issue into the same room and lock them there until they agree on a resolution. With proprietary software you can. It's also more a question of observability. I'm not interested in abstract discussions about issue trackers we don't have access to. I'm interested in having a discussion about something with a public audit trail that we're all on a level playing field when we discuss pros/cons. It's also about what I've observed: Linux kernel. 1298 open issues out of 10460 since the tracker was set up in late 2002: http://bugzilla.kernel.org/ Firefox: Query timed out before I could get a result: https://bugzilla.mozilla.org/ MediaWiki: 2869 open issues out of 13768 created since the tracker was created in mid 2004. Issues I've personally been watching have sat open for years: https://bugzilla.wikimedia.org/ I think all of these are fine pieces of software that I use on a daily basis, and hope we can have the same success as these projects. Yet they are also not reaching the platonic ideal of zero net growth in open issues as near as I can tell. If there are active projects of comparable size/complexity which do achieve the zero-open growth standard that we can all observe the public bug tracker for, I'd be very interested in seeing it. While it'd be cool to be a pioneer, I'm much more interested in achieving something that is sensible to achieve given community norms. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080416/2f4a185b/signature.pgp From rdw at lindenlab.com Wed Apr 16 17:21:12 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Apr 16 17:21:14 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <480686B3.3000109@watson.ibm.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com><48066F57.6090607@watson.ibm.com> <48067F94.4040600@lindenlab.com> <480686B3.3000109@watson.ibm.com> Message-ID: <480697F8.1090805@lindenlab.com> Mike Monkowski wrote: > Ryan Williams (Which) wrote: >> So, yeah, that's what goes through my head when I think of that bug. I >> think we should close it in favor of a cluster of more specific bugs, >> but then there would be outcry that we unjustly crushed all the votes on >> SVC-85. > > So don't close SVC-85 and add several more. Keep SVC-85 open, give it a > title that specifically represents the major outstanding complaint (even > if it's not the original complaint), add as many more as you want with > other specific titles, show those as related issues, and modify the > description appropriately, directing people to the other issues as well. Yeah, this is probably the right thing to do. The result, though, is that SVC-85 never gets closed.... which I guess is fine, as long as we're not slaves to the list of unclosed bugs. :-) -RYaN From lenglish5 at cox.net Wed Apr 16 18:20:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Apr 16 18:20:52 2008 Subject: [sldev] Authorization with old login code In-Reply-To: References: <48060EC8.4070109@zweitgeist.com> Message-ID: <4806A5F1.10902@cox.net> Robin Cornelius wrote: > On Wed, Apr 16, 2008 at 3:35 PM, alexander.treptow > wrote: > >> Hi, >> i got an edited Second Life Viewer 1.18.2(1) so it uses the old / current >> login code. But now i cant connect to the grid, i get no login error. i only >> get a reason and a message. >> >> reason_response: "update" >> message_response: "Required Version: 1.19.1.4" >> > > Change the channel the viewer connects with, you can do this as a > command line parameter or edit llviewerversion.h and rebuild. If you > connect on offical linden channel and you are not at required minimum > version you will get an update message > > Robin > _______________________________________________ > For people experimenting with my login code or the code provided by libsecondlife.com, it's easier: just edit the version number in the Python data structure that is fed to the xml-rpc call. https://wiki.secondlife.com/wiki/Example_protocol_code (presence code). Lawson From gigstaggart at gmail.com Wed Apr 16 18:20:10 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 16 18:22:12 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806975A.1010805@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com> <4806975A.1010805@lindenlab.com> Message-ID: <4806A5CA.6000700@gmail.com> Rob Lanphier wrote: > Because anyone can file issues, and you can't get the people who > disagree about whether an issue is really an issue into the same room > and lock them there until they agree on a resolution. With proprietary > software you can. > > It's also about what I've observed: > > Linux kernel. 1298 open issues out of 10460 since the tracker was set > up in late 2002: > http://bugzilla.kernel.org/ This sounds like a decent ratio, about 12%. Keep in mind my 8+ bugs growth per day number is *only bugs*. I do not count feature requests in that number. > Firefox: Query timed out before I could get a result: > https://bugzilla.mozilla.org/ I'm not sure Firefox is a good example. They aren't exactly model citizens in the open source world. > MediaWiki: 2869 open issues out of 13768 created since the tracker was > created in mid 2004. Issues I've personally been watching have sat open > for years: > https://bugzilla.wikimedia.org/ This is about 20%, And I hate to keep bringing them up as my "good example", but Ghostscript is about 500,000 lines of code, which puts them in the same ballpark as say, just the SL client. They have 369 open bugs out of 4015 total filed, slightly under 10%, rillian reports they do have a very slightly positive open bug growth rate. Along with your data, it looks like this 10% open ratio for good projects keeps coming up. Linden lab is running 2717 out of 7706 across all projects, or 35% open. Even your examples were better than this. -Jason From sammy.frederix at gmail.com Wed Apr 16 20:45:26 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Wed Apr 16 20:45:37 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds Message-ID: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> Has anyone else been seeing "ERROR: assert_glerror: GL Error:invalid value" when running debug builds of the Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to take one with Control-` ? It's been happening to me on the Mac, but only with Development (Debug) builds. It crashes before the Save as dialogue box is displayed. Deployment builds get to the save as dialogue and I can save perfectly. I'm not sure if it's related to https://jira.secondlife.com/browse/VWR-3529 or not, because Deployment builds work fine for me (even ones I've built myself). Regards, Sammy Console error: 2008-04-17T00:58:49Z llwindow/llgl.cpp(959) : error 2008-04-17T00:58:49Z ERROR: assert_glerror: GL Error:invalid value System: Model Name: MacBook Pro 15" Model Identifier: MacBookPro2,2 Chipset Model: ATY,RadeonX1600 VRAM (Total): 256 MB Vendor: ATI (0x1002) ROM Revision: 113-xxxxxx-158 EFI Driver Version: 01.00.158 System Version: Mac OS X 10.5.2 (9C7010) Kernel Version: Darwin 9.2.2 Stack trace (from when the dialogue box was displayed): #0 0x903149e6 in mach_msg_trap () #1 0x9031c1dc in mach_msg () #2 0x901500de in CFRunLoopRunSpecific () #3 0x90150d18 in CFRunLoopRunInMode () #4 0x92ef66a0 in RunCurrentEventLoopInMode () #5 0x92faa28f in GetNextEventMatchingMask () #6 0x92fa9f96 in WNEInternal () #7 0x92fa9ef5 in WaitNextEvent () #8 0x92fa8c35 in ModalDialog () #9 0x92fdf1b2 in RunStandardAlert () #10 0x00e160fa in OSMessageBoxMacOSX (text=0x2f340b7c "ERROR: assert_glerror: GL Error:invalid value", caption=0xfb5ac0 "Fatal Error", type=0) at /Users/home/SLOrig/linden/indra/newview/../llwindow/ llwindowmacosx.cpp:3143 #11 0x00daf624 in OSMessageBox (text=0x2f340b7c "ERROR: assert_glerror: GL Error:invalid value", caption=0xfb5ac0 "Fatal Error", type=0) at /Users/home/SLOrig/linden/indra/newview/../llwindow/ llwindow.cpp:225 #12 0x00c0f274 in errorCallback (error_string=@0xbfffcf18) at /Users/ home/SLOrig/linden/indra/newview/llappviewer.cpp:1402 #13 0x00d03601 in LLError::Log::flush (out=0x7236050, site=@0x2891700) at /Users/home/SLOrig/linden/indra/newview/../llcommon/llerror.cpp:1029 #14 0x00e2d272 in assert_glerror () at /Users/home/SLOrig/linden/indra/ newview/../llwindow/llgl.cpp:959 #15 0x006d99ff in display (rebuild=0, zoom_factor=1, subfield=0, for_snapshot=1) at /Users/home/SLOrig/linden/indra/newview/ llviewerdisplay.cpp:495 #16 0x0013d9c7 in LLViewerWindow::rawSnapshot (this=0x17e7e530, raw=0x34a7be10, image_width=2770, image_height=1570, keep_window_aspect=1, is_texture=0, show_ui=0, do_rebuild=0, type=LLViewerWindow::SNAPSHOT_TYPE_COLOR, max_size=6144) at /Users/ home/SLOrig/linden/indra/newview/llviewerwindow.cpp:4518 #17 0x00bc995e in LLFileTakeSnapshotToDisk::handleEvent (this=0x2be5ed90, event=@0xbfffd4c8, userdata=@0x739a748) at /Users/ home/SLOrig/linden/indra/newview/llviewermenufile.cpp:397 #18 0x00a6968b in LLSimpleDispatcher::fireEvent (this=0x2c2118e0, event=@0xbfffd50c, filter=@0xbfffd508) at /Users/home/SLOrig/linden/ indra/newview/../llcommon/llevent.cpp:228 #19 0x00a69403 in LLEventDispatcher::fireEvent (this=0x739e170, event=@0xbfffd54c, filter=@0xbfffd548) at /Users/home/SLOrig/linden/ indra/newview/../llcommon/llevent.cpp:153 #20 0x00a694c7 in LLObservable::fireEvent (this=0x2c211d68, event=@0xbfffd59c, filter=@0xbfffd598) at /Users/home/SLOrig/linden/ indra/newview/../llcommon/llevent.cpp:104 #21 0x0083169c in LLMenuItemCallGL::doIt (this=0x2c211bb0) at /Users/ home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:853 #22 0x00829bb5 in LLMenuItemGL::handleAcceleratorKey (this=0x2c211bb0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/indra/newview/../llui/ llmenugl.cpp:195 #23 0x0082d61c in LLMenuItemCallGL::handleAcceleratorKey (this=0x2c211bb0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/ indra/newview/../llui/llmenugl.cpp:892 #24 0x0082e557 in LLMenuGL::handleAcceleratorKey (this=0x2c20ebc0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/indra/newview/../llui/ llmenugl.cpp:2743 #25 0x0083176d in LLMenuItemBranchDownGL::handleAcceleratorKey (this=0x2c213fc0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/ indra/newview/../llui/llmenugl.cpp:1483 #26 0x0082e557 in LLMenuGL::handleAcceleratorKey (this=0x2bea9de0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/indra/newview/../llui/ llmenugl.cpp:2743 #27 0x0082fbcb in LLMenuBarGL::handleAcceleratorKey (this=0x2bea9de0, key=96 '`', mask=1) at /Users/home/SLOrig/linden/indra/newview/../llui/ llmenugl.cpp:3867 #28 0x0013fc3a in LLViewerWindow::handleKey (this=0x17e7e530, key=96 '`', mask=1) at /Users/home/SLOrig/linden/indra/newview/ llviewerwindow.cpp:2603 #29 0x0080c26f in LLViewerKeyboard::handleKey (this=0x254d0a0, translated_key=96 '`', translated_mask=1, repeated=0) at /Users/home/ SLOrig/linden/indra/newview/llviewerkeyboard.cpp:654 #30 0x0013752e in LLViewerWindow::handleTranslatedKeyDown (this=0x17e7e530, key=96 '`', mask=1, repeated=0) at /Users/home/ SLOrig/linden/indra/newview/llviewerwindow.cpp:1300 #31 0x00e1e042 in LLKeyboard::handleTranslatedKeyDown (this=0x6e8e400, translated_key=96 '`', translated_mask=1) at /Users/home/SLOrig/linden/ indra/newview/../llwindow/llkeyboard.cpp:243 #32 0x00e23620 in LLKeyboardMacOSX::handleKeyDown (this=0x6e8e400, key=50, mask=4096) at /Users/home/SLOrig/linden/indra/newview/../ llwindow/llkeyboardmacosx.cpp:237 #33 0x00e1ba17 in LLWindowMacOSX::eventHandler (this=0x6e45e00, myHandler=0xbfffe2e0, event=0x2f3e8ee0) at /Users/home/SLOrig/linden/ indra/newview/../llwindow/llwindowmacosx.cpp:2300 #34 0x00e1af3f in LLWindowMacOSX::eventHandler (this=0x6e45e00, myHandler=0xbfffe2e0, event=0x2be41f60) at /Users/home/SLOrig/linden/ indra/newview/../llwindow/llwindowmacosx.cpp:2159 #35 0x00e1d56b in LLWindowMacOSX::staticEventHandler (myHandler=0xbfffe2e0, event=0x2be41f60, userData=0x6e45e00) at /Users/ home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:1963 #36 0x92ecdfc3 in DispatchEventToHandlers () #37 0x92ecd3fd in SendEventToEventTargetInternal () #38 0x92ee9e0e in SendEventToEventTarget () #39 0x92efcbc6 in ToolboxEventDispatcherHandler () #40 0x92ece37c in DispatchEventToHandlers () #41 0x92ecd3fd in SendEventToEventTargetInternal () #42 0x92ee9e0e in SendEventToEventTarget () #43 0x92fcbab5 in SendTSMEvent () #44 0x93009314 in SendUnicodeTextAEToUnicodeDoc () #45 0x92fca03b in TSMKeyEvent () #46 0x92f1db13 in TSMProcessRawKeyEvent () #47 0x930761a5 in HandleCompatibilityKeyEvent () #48 0x92ec9c07 in HIApplication::EventHandler () #49 0x92ecdfc3 in DispatchEventToHandlers () #50 0x92ecd3fd in SendEventToEventTargetInternal () #51 0x92ecd262 in SendEventToEventTargetWithOptions () #52 0x92efcafa in ToolboxEventDispatcherHandler () #53 0x92ece37c in DispatchEventToHandlers () #54 0x92ecd3fd in SendEventToEventTargetInternal () #55 0x92ee9e0e in SendEventToEventTarget () #56 0x92f57110 in ToolboxEventDispatcher () #57 0x92faa4b0 in GetOrPeekEvent () #58 0x92faa17a in GetNextEventMatchingMask () #59 0x92fa9f96 in WNEInternal () #60 0x92fa9ef5 in WaitNextEvent () #61 0x00e16b1a in LLWindowMacOSX::gatherInput (this=0x6e45e00) at / Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp: 1159 #62 0x00c1d222 in LLAppViewer::mainLoop (this=0x7235f10) at /Users/ home/SLOrig/linden/indra/newview/llappviewer.cpp:921 #63 0x00c29358 in main (argc=1, argv=0xbffff6d0) at /Users/home/SLOrig/ linden/indra/newview/llappviewermacosx.cpp:88 From q at lindenlab.com Wed Apr 16 20:48:42 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Apr 16 20:48:45 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806A5CA.6000700@gmail.com> References: <48064D58.5050003@gmail.com><48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com><4806975A.1010805@lindenlab.com> <4806A5CA.6000700@gmail.com> Message-ID: <4CB3C6E4-EF1A-4015-B417-C590C97098B5@lindenlab.com> OLPC: 4470 bugs closed, 2368 non-closed (assigned, new, and reopened). That's 6838 total, or 35% open bugs. That's not to say that I think 35% is a good number or anything, just that there are other examples. If you're going to invalidate examples, I think we also have to consider the rate of change of the underlying systems. Ghostscript is basically an implementation of Postscript. According to Wikipedia, the last change to the Postscript spec was in 1997. I *hope* by now it has very few bugs! I think we all recognize that we'd like to get better at accepting patches, developing in the open, providing more modular code so that others can more readily contribute, and so that we can accept those contributions. We're doing a lot in all of those areas, but it takes time. I'm not going to sit here and promise the moon, or even list all of our initiatives. I recognize that the proof is in our actions, so I'll shut up and ask you to just watch us...and please try also to notice the good stuff when it happens. Q On Apr 16, 2008, at 9:20 PM, Jason Giglio wrote: > Rob Lanphier wrote: >> Because anyone can file issues, and you can't get the people who >> disagree about whether an issue is really an issue into the same room >> and lock them there until they agree on a resolution. With >> proprietary >> software you can. >> >> It's also about what I've observed: >> >> Linux kernel. 1298 open issues out of 10460 since the tracker was >> set >> up in late 2002: >> http://bugzilla.kernel.org/ > > This sounds like a decent ratio, about 12%. > > Keep in mind my 8+ bugs growth per day number is *only bugs*. I do > not > count feature requests in that number. > >> Firefox: Query timed out before I could get a result: >> https://bugzilla.mozilla.org/ > > I'm not sure Firefox is a good example. They aren't exactly model > citizens in the open source world. > >> MediaWiki: 2869 open issues out of 13768 created since the tracker >> was >> created in mid 2004. Issues I've personally been watching have sat >> open >> for years: >> https://bugzilla.wikimedia.org/ > > This is about 20%, > > And I hate to keep bringing them up as my "good example", but > Ghostscript is about 500,000 lines of code, which puts them in the > same > ballpark as say, just the SL client. > > They have 369 open bugs out of 4015 total filed, slightly under 10%, > rillian reports they do have a very slightly positive open bug > growth rate. > > Along with your data, it looks like this 10% open ratio for good > projects keeps coming up. > > Linden lab is running 2717 out of 7706 across all projects, or 35% > open. > Even your examples were better than this. > From lenglish5 at cox.net Wed Apr 16 21:43:56 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Apr 16 21:43:59 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48066426.9020807@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> Message-ID: <4806D58C.7050103@cox.net> Rob Lanphier wrote: > Hi Gigs, > > This is great information. Thanks for compiling it. > > A couple of questions/comments below: > > On 4/16/08 12:02 PM, Jason Giglio wrote: >> "Open" bugs have been on a steady climb. It started at 1547 when >> sljirastats.com began collecting data, and is now at 2717. This means >> we are averaging 8.6 additional unresolved bugs per day. This is after >> subtracting fixed and resolved issues. This number is a critical >> metric; Linden Lab is falling more and more behind every day. >> > > How does this compare to other open source and public projects? My > suspicion is that almost every active open source project experiences > net positive growth in number of open bugs. I'd like to make sure > we're not being measured against an unreasonably high standard. > > We have a resolution internally called "someday maybe", which is one > I'm personally not a fan of (since the issue isn't "resolved", just > acknowledged as a wart we're going to have to live with for a while). > We've recently discussed making a matching PJIRA resolution, and > concluded that a) we can't, because we still want to allow votes and > b) we'd get a public flogging over it. The conclusion of that > discussion is to represent that as "small" priority, possibly renaming > "small" to "someday maybe", or adding a new "someday maybe" priority, > and I'm hoping we can actually change our internal usage to match. > >> SVC-472 and SVC-85 remain the most hated bugs, for most of the time that >> sljirastats has existed. >> > > Hmmm....these are also somewhat subjective without clear victory > conditions. While I'm guessing the team will acknowledge that these > aren't yet running at an acceptable baseline, it also strikes me that > these both describe symptoms with multiple and ever-changing causes of > failure that will probably always be with us in some form from time to > time. For both of these, I think we need to establish a victory > condition that causes these issues to be closed and stay closed, to > the point where a new issue gets opened if a problem with the same > symptom occurs. Otherwise, these will automatically be at the top of > the list every time they get reopened, despite the fact that other > issues may actually be more pressing. > > What are good victory conditions for these? > > Rob > I've said it before (and I'm saying it again): the single most important thing that can be done to reduce client-bugs in the long-run is to refactor the GUI away from the rest of the client code-base. The GUI kinda seeps into everything and it's virtually impossible to change the GUI in substantial ways without impacting the rest of the code, and whenever you touch most of the non-GUI code, you must take into account the interactions of the GUI with that section of code during your analysis--even at the highest and lowest levels of the analysis. It's a mess. And a not-very tasty mess, too. In other words, if the refactoring of the GUI is done properly, it will allow us to establish good victory conditions for almost every other issue in the client because many issues will sort themselves out during the refactoring or such is my intuition, and even if not, they will become more manageable issues automatically. Lawson From robin.cornelius at gmail.com Thu Apr 17 01:36:43 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Apr 17 01:36:49 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds In-Reply-To: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> References: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> Message-ID: <48070C1B.7030606@gmail.com> Sammy Frederix wrote: > Has anyone else been seeing "ERROR: assert_glerror: GL Error:invalid > value" when running debug builds of the > Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to take > one with Control-` ? > There have been a few issues on this branch. r481 is old news though ;-) Soft dropped an update r487 on that branch last night, i would give your code an update and try again, i think it fixes this. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080417/1e41299c/signature.pgp From lcc1967 at gmail.com Thu Apr 17 02:16:21 2008 From: lcc1967 at gmail.com (laurent cezanne) Date: Thu Apr 17 02:16:23 2008 Subject: [sldev] [linux ubuntu 8.04] [1.19.1.4] *** glibc detected *** slviewer: corrupted double-linked list: 0x0000000005cdf6d0 *** Message-ID: Hello, Since few days I got thoses silly errors and crash : *** glibc detected *** slviewer: corrupted double-linked list: 0x0000000005cdf6d0 *** with any 1.19.1.4 viewer (official, coolviewer, home_made, Nicholaz) 1) Any clue about the root causes of that ? 2) How could I try to debug that ? any flag to activate during compilation ? Oddly, it seems to be more frequent since the last ubuntu 8.04 upgrade :/ Thanks ===== Ubuntu 8.04 (64 bits) AMD64,4GO -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/95f91fd1/attachment.htm From warkirby3333 at hotmail.co.uk Thu Apr 17 03:31:37 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Thu Apr 17 03:31:41 2008 Subject: [sldev] Victory Conditions In-Reply-To: <20080417034541.E1F1341B36A@stupor.lindenlab.com> References: <20080417034541.E1F1341B36A@stupor.lindenlab.com> Message-ID: My own thoughts as to "Victory Conditions" on the two most hated bugs SVC-85: The friends list bug Due to the nature of being able to hide online status, part of this will never be resolved, I think.. But there are definitive problems with the friends list as is. 1. The list simply fails to load, showing waiting/loading/hippos permanantly. It is acceptable, and even expected, that this would appear on there temporarily, The problem occurs when one has been online for several minutes, and still nothing shows. I think the best solution to this, if it is not already implemnented, is to add a timeout. If the friends list hasn't loaded x seconds after logging in, try again. Keep trying until it works, or there's a fairly certain conclusion that it won't work. Now, as o that latter part, there are occasionally service problems that make things not work properly. Problems with the friends list often leave it in limbo permanantly. Instead, I think the friends list should be replaced with an error message in such times. Something to let the user know that there is a current service problem, and apologise for the inconvenience. Now farther to that, there is another problem. Oftentimes, the friends list will permanantly stick at loading, but if the user logs out and back in again, it works as expected. This would generally indicate that it could work if the viewer just retried, perhaps ? So, Victory conditions for this part 1. Make the friends list never fail to display, as long as there it not a widespread service problem. 2. If there is a problem, replace it with an error message informing the user of such Now, the second part of this, presence. In my experience, this most notably manifests itself as the system being confused as to the online status of an agent. This seems to occur in a few ways. 1. An agent shows as offline. Sending them an IM will force an update, though, and suddenly, the friends list says they've just come online. 2. An agent shows as online, according to the friends list, but it actually not. Sending an Im updates it, and makes it appear that the agent has logged out at the exact time they recieved the message. 3. And this one is most important, IMO. An agent shows as online, and IS in fact online, but upon IMing, the friends list suddenly decides they're offline. Giving the (x is offline, message will be stored and delivered later) and showing them offline in the friends list. The agent will often respond, unaware of this. I've observed, in this case, the friends list actually flipping back and forward with each IM, showing a user as online, then offline, then online, etc. When they have in fact been online the whole time. Given the above, I suppose the third victory condition, is simply 3. Make presence work properly. That's all for that issue, I think. Now,... SVC-472 - Region Crossings This is a much more vague and unspecific issue. I break it down into these problems. 1. Attachments messing up on region crossing.. This frequently and annoyiingly happens. The avatar's attachments often simply vanish, or move to odd locations like the waist. Hud devices especially, simply vvanish. 2. Unseating A problem which most often affects cases where multiple avatars are sitting on the same object. They seem to randomly get unseated.. This makes passenger vehicles a nightmare to use. In my experience, additional avatars beyond the first are sometimes getting unseated. 3. Sinking into surfaces This is most often seen when crossing regions on foot, less so when flying. The avatar seems to move without colliding with things on the other side of the crossing for a few seconds. In addition, the avatar's trajectory seems to get altered. Theoretically, walking across a straight bridge between sims should be alright, but in actuality, the avatar starts moving diagonally downwards, instead of contonueing straight forwards as they were when the crossing started. I think this part could be solved by simply keeping the avatar/object's trajectory intact, so that if they cross a sim walking in a straight line, they'll be at the same altitude on the other side. Another problem with this area, is the lack of collision with stuff. When falling through things at sim borders, this is often not just a clientside effect, but the avatar will actually end up under or inside objects when the crossing completes. 4. Constant motion Also a notable problem, quite related to the previous, the avatar keeps moving when crossing a sim, while the next siim loads them. When things are going good, this helps t prevent breaking the flow of motion, and is nice. But when sim crossings are going slowly, he user often ends up walking or flying in a straight line for several seconds, or even minutes. No new data seems to be downloaded during this time, and so it's quite possible, and likely, that the useer will walk outside of theiir own draw distance, and just be moving around in endless sea and sky until the crossing finishes. To remedy that, I'm thinking some sort of timeout for that continued motion. After which, the avatar should just stop, and stay still until the crossing finishes. 5. slowness. Ultimately, the worst problem. Simply the time it takes for a region crossing to complete. This is affected by attachments and scripts in the user, as we know. But it does also seem to depend a lot on the performance of the sim. Aside from upgrading the hardware of every sim, the only solution I can think of for this, is preemptively loading the avatar for neighboring sims, before a crossing begins. To minimise the excess load this would cause, there should be some intelligence in doing so. Like preloading based on the avatar's proximity, and direction of motion. If an av is 30m away from a sim border, and moving towards it steadily, it's not unreasonable to expect them to attempt a crossing, and would be a good situation for preloading. Where multiple avatars are sitting on one object, they should be treated as a single entity for deciding preloading, and all preloaded at the same time when necessary. Hopefully, doing that will greatly speed up sim crossings. So, Victory conditions 1. Prevent attachments messing up at all costs. 2. Prevent unseating, and load multiple avatars on the same object together. 3. Implement preloading of avatar data to hopefully speed up crossing time overall. WarKirby Magojiro _________________________________________________________________ Win 100?s of Virgin Experience days with BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/48054307/attachment-0001.htm From tom at streamsense.net Thu Apr 17 04:00:00 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 17 04:00:10 2008 Subject: [sldev] Victory Conditions In-Reply-To: References: <20080417034541.E1F1341B36A@stupor.lindenlab.com> Message-ID: <48072DB0.5050702@streamsense.net> Paul Cook wrote: > 1. The list simply fails to load, showing waiting/loading/hippos > permanantly. It is acceptable, and even expected, that this would > appear on there temporarily, The problem occurs when one has been > online for several minutes, and still nothing shows. I have not seen this problem for a good time now, I would guess it only occurs when either the user or the server is having bandwidth or packet loss issues. > 3. Sinking into surfaces > > This is most often seen when crossing regions on foot, less so when > flying. The avatar seems to move without colliding with things on the > other side of the crossing for a few seconds. In addition, the > avatar's trajectory seems to get altered. Theoretically, walking > across a straight bridge between sims should be alright, but in > actuality, the avatar starts moving diagonally downwards, instead of > contonueing straight forwards as they were when the crossing started. This is due to the fact that (for some reason) the sim does all the collision detection, and since you're switching between sims, there is none. I have little or no idea why the sim does all the collision detection in second life, it would be far more efficient to move it client side. > Ultimately, the worst problem. Simply the time it takes for a region > crossing to complete. This is affected by attachments and scripts in > the user, as we know. But it does also seem to depend a lot on the > performance of the sim. Aside from upgrading the hardware of every > sim, the only solution I can think of for this, is preemptively > loading the avatar for neighboring sims, before a crossing begins. The client already automatically connects to neighbouring sims, so I can't imagine this being tremendously challenging to implement... > So, Victory conditions Let's go get drunk. ~Tom From tateru.nino at gmail.com Thu Apr 17 04:06:48 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Apr 17 04:11:49 2008 Subject: [sldev] Victory Conditions In-Reply-To: References: <20080417034541.E1F1341B36A@stupor.lindenlab.com> Message-ID: <48072F48.9020901@weblogsinc.com> Paul Cook wrote: > My own thoughts as to "Victory Conditions" on the two most hated bugs > > SVC-85: The friends list bug > [etc] > That's all for that issue, I think. Now,... > > SVC-472 - Region Crossings > > This is a much more vague and unspecific issue. I break it down into > these problems. > > 1. Attachments messing up on region crossing.. > > This frequently and annoyiingly happens. The avatar's attachments > often simply vanish, or move to odd locations like the waist. Hud > devices especially, simply vvanish. > Nicholaz Beresford found the causes of this and fixed them. > 2. Unseating > A problem which most often affects cases where multiple avatars are > sitting on the same object. They seem to randomly get unseated.. This > makes passenger vehicles a nightmare to use. In my experience, > additional avatars beyond the first are sometimes getting unseated. > > > 3. Sinking into surfaces > > This is most often seen when crossing regions on foot, less so when > flying. The avatar seems to move without colliding with things on the > other side of the crossing for a few seconds. In addition, the > avatar's trajectory seems to get altered. Theoretically, walking > across a straight bridge between sims should be alright, but in > actuality, the avatar starts moving diagonally downwards, instead of > contonueing straight forwards as they were when the crossing started. > I think this part could be solved by simply keeping the > avatar/object's trajectory intact, so that if they cross a sim walking > in a straight line, they'll be at the same altitude on the other side. > > Another problem with this area, is the lack of collision with stuff. > When falling through things at sim borders, this is often not just a > clientside effect, but the avatar will actually end up under or inside > objects when the crossing completes. Actually, I think both of these are motion prediction issues. When crossing a sim border, the agent is assumed to continue at last course and speed until the simulator handover is complete, at which point the viewer is sent updated position information. The avatar can appear to be moving through the terrain and objects if their movement vector outweighs the simulator handoff time (there's quite a bit of stuffing around to hand the agent from one sim to another along with attachments and script states intact. This also includes the network latency between the departure sim and the viewer and between the arrival sim and the viewer). I am guessing that item 2 (unseating) is actually triggered by the viewer under circumstances where position updates are sent to the viewer in an order that makes it seem as if the seat and the agent are too far away from each-other. That's more of a deduction than anything I've had the opportunity to confirm. > 4. Constant motion > > Also a notable problem, quite related to the previous, the avatar > keeps moving when crossing a sim, while the next siim loads them. When > things are going good, this helps t prevent breaking the flow of > motion, and is nice. But when sim crossings are going slowly, he user > often ends up walking or flying in a straight line for several > seconds, or even minutes. No new data seems to be downloaded during > this time, and so it's quite possible, and likely, that the useer will > walk outside of theiir own draw distance, and just be moving around in > endless sea and sky until the crossing finishes. > > To remedy that, I'm thinking some sort of timeout for that continued > motion. After which, the avatar should just stop, and stay still > until the crossing finishes. I think perhaps yes. If you're doing more than a few seconds of motion prediction without updates it is probably time to halt and await further updates. > 5. slowness. > > Ultimately, the worst problem. Simply the time it takes for a region > crossing to complete. This is affected by attachments and scripts in > the user, as we know. But it does also seem to depend a lot on the > performance of the sim. Aside from upgrading the hardware of every > sim, the only solution I can think of for this, is preemptively > loading the avatar for neighboring sims, before a crossing begins. To > minimise the excess load this would cause, there should be some > intelligence in doing so. Like preloading based on the avatar's > proximity, and direction of motion. If an av is 30m away from a sim > border, and moving towards it steadily, it's not unreasonable to > expect them to attempt a crossing, and would be a good situation for > preloading. > > Where multiple avatars are sitting on one object, they should be > treated as a single entity for deciding preloading, and all preloaded > at the same time when necessary. > > Hopefully, doing that will greatly speed up sim crossings. [see above] I think there are probably more delays in ... well 'baggage handling' than in the raw avatars and agents themselves. Attachments and script states come to mind immediately. -- Tateru Nino http://www.massively.com/ From secret.argent at gmail.com Thu Apr 17 04:26:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Apr 17 04:26:19 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806D58C.7050103@cox.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> Message-ID: <427D7A8B-1633-40F8-89FA-4F4154DDD842@gmail.com> On the subject of refactoring the GUI, the last time this came up there was a suggestion that teh LL GIO be made a portable toolkit rather than using a portable OpenGL toolkit for the GUI. After looking at the LL GUI code, I believe that it would probably be better to throw Linden Labs support behind one of the existing OpenGL GUI toolkits. It's pretty specialized and missing a lot of basic functionality like automatically cropping or wrapping text in widgets... From Dana.Fagerstrom at Sun.COM Thu Apr 17 05:03:39 2008 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Thu Apr 17 05:03:43 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds In-Reply-To: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> References: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> Message-ID: <48073C9B.90802@sun.com> Sammy, This is likely https://jira.secondlife.com/browse/VWR-6343 The workaround reported by Fooke, disabling Avatar Imposters and Atmospheric Shaders, works great on all platforms I've tested. D/Whoops Sammy Frederix wrote: > Has anyone else been seeing "ERROR: assert_glerror: GL Error:invalid > value" when running debug builds of the > Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to take > one with Control-` ? > > It's been happening to me on the Mac, but only with Development (Debug) > builds. It crashes before the Save as dialogue box is displayed. > Deployment builds get to the save as dialogue and I can save perfectly. > > I'm not sure if it's related to > https://jira.secondlife.com/browse/VWR-3529 or not, because Deployment > builds work fine for me (even ones I've built myself). > > Regards, > Sammy > > Console error: > > 2008-04-17T00:58:49Z llwindow/llgl.cpp(959) : error > 2008-04-17T00:58:49Z ERROR: assert_glerror: GL Error:invalid value > > System: > Model Name: MacBook Pro 15" > Model Identifier: MacBookPro2,2 > Chipset Model: ATY,RadeonX1600 > VRAM (Total): 256 MB > Vendor: ATI (0x1002) > ROM Revision: 113-xxxxxx-158 > EFI Driver Version: 01.00.158 > System Version: Mac OS X 10.5.2 (9C7010) > Kernel Version: Darwin 9.2.2 > > Stack trace (from when the dialogue box was displayed): > > #0 0x903149e6 in mach_msg_trap () > #1 0x9031c1dc in mach_msg () > #2 0x901500de in CFRunLoopRunSpecific () > #3 0x90150d18 in CFRunLoopRunInMode () > #4 0x92ef66a0 in RunCurrentEventLoopInMode () > #5 0x92faa28f in GetNextEventMatchingMask () > #6 0x92fa9f96 in WNEInternal () > #7 0x92fa9ef5 in WaitNextEvent () > #8 0x92fa8c35 in ModalDialog () > #9 0x92fdf1b2 in RunStandardAlert () > #10 0x00e160fa in OSMessageBoxMacOSX (text=0x2f340b7c "ERROR: > assert_glerror: GL Error:invalid value", caption=0xfb5ac0 "Fatal Error", > type=0) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:3143 > #11 0x00daf624 in OSMessageBox (text=0x2f340b7c "ERROR: assert_glerror: > GL Error:invalid value", caption=0xfb5ac0 "Fatal Error", type=0) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindow.cpp:225 > #12 0x00c0f274 in errorCallback (error_string=@0xbfffcf18) at > /Users/home/SLOrig/linden/indra/newview/llappviewer.cpp:1402 > #13 0x00d03601 in LLError::Log::flush (out=0x7236050, site=@0x2891700) > at /Users/home/SLOrig/linden/indra/newview/../llcommon/llerror.cpp:1029 > #14 0x00e2d272 in assert_glerror () at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llgl.cpp:959 > #15 0x006d99ff in display (rebuild=0, zoom_factor=1, subfield=0, > for_snapshot=1) at > /Users/home/SLOrig/linden/indra/newview/llviewerdisplay.cpp:495 > #16 0x0013d9c7 in LLViewerWindow::rawSnapshot (this=0x17e7e530, > raw=0x34a7be10, image_width=2770, image_height=1570, > keep_window_aspect=1, is_texture=0, show_ui=0, do_rebuild=0, > type=LLViewerWindow::SNAPSHOT_TYPE_COLOR, max_size=6144) at > /Users/home/SLOrig/linden/indra/newview/llviewerwindow.cpp:4518 > #17 0x00bc995e in LLFileTakeSnapshotToDisk::handleEvent > (this=0x2be5ed90, event=@0xbfffd4c8, userdata=@0x739a748) at > /Users/home/SLOrig/linden/indra/newview/llviewermenufile.cpp:397 > #18 0x00a6968b in LLSimpleDispatcher::fireEvent (this=0x2c2118e0, > event=@0xbfffd50c, filter=@0xbfffd508) at > /Users/home/SLOrig/linden/indra/newview/../llcommon/llevent.cpp:228 > #19 0x00a69403 in LLEventDispatcher::fireEvent (this=0x739e170, > event=@0xbfffd54c, filter=@0xbfffd548) at > /Users/home/SLOrig/linden/indra/newview/../llcommon/llevent.cpp:153 > #20 0x00a694c7 in LLObservable::fireEvent (this=0x2c211d68, > event=@0xbfffd59c, filter=@0xbfffd598) at > /Users/home/SLOrig/linden/indra/newview/../llcommon/llevent.cpp:104 > #21 0x0083169c in LLMenuItemCallGL::doIt (this=0x2c211bb0) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:853 > #22 0x00829bb5 in LLMenuItemGL::handleAcceleratorKey (this=0x2c211bb0, > key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:195 > #23 0x0082d61c in LLMenuItemCallGL::handleAcceleratorKey > (this=0x2c211bb0, key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:892 > #24 0x0082e557 in LLMenuGL::handleAcceleratorKey (this=0x2c20ebc0, > key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:2743 > #25 0x0083176d in LLMenuItemBranchDownGL::handleAcceleratorKey > (this=0x2c213fc0, key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:1483 > #26 0x0082e557 in LLMenuGL::handleAcceleratorKey (this=0x2bea9de0, > key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:2743 > #27 0x0082fbcb in LLMenuBarGL::handleAcceleratorKey (this=0x2bea9de0, > key=96 '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llui/llmenugl.cpp:3867 > #28 0x0013fc3a in LLViewerWindow::handleKey (this=0x17e7e530, key=96 > '`', mask=1) at > /Users/home/SLOrig/linden/indra/newview/llviewerwindow.cpp:2603 > #29 0x0080c26f in LLViewerKeyboard::handleKey (this=0x254d0a0, > translated_key=96 '`', translated_mask=1, repeated=0) at > /Users/home/SLOrig/linden/indra/newview/llviewerkeyboard.cpp:654 > #30 0x0013752e in LLViewerWindow::handleTranslatedKeyDown > (this=0x17e7e530, key=96 '`', mask=1, repeated=0) at > /Users/home/SLOrig/linden/indra/newview/llviewerwindow.cpp:1300 > #31 0x00e1e042 in LLKeyboard::handleTranslatedKeyDown (this=0x6e8e400, > translated_key=96 '`', translated_mask=1) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llkeyboard.cpp:243 > #32 0x00e23620 in LLKeyboardMacOSX::handleKeyDown (this=0x6e8e400, > key=50, mask=4096) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llkeyboardmacosx.cpp:237 > > #33 0x00e1ba17 in LLWindowMacOSX::eventHandler (this=0x6e45e00, > myHandler=0xbfffe2e0, event=0x2f3e8ee0) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:2300 > #34 0x00e1af3f in LLWindowMacOSX::eventHandler (this=0x6e45e00, > myHandler=0xbfffe2e0, event=0x2be41f60) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:2159 > #35 0x00e1d56b in LLWindowMacOSX::staticEventHandler > (myHandler=0xbfffe2e0, event=0x2be41f60, userData=0x6e45e00) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:1963 > #36 0x92ecdfc3 in DispatchEventToHandlers () > #37 0x92ecd3fd in SendEventToEventTargetInternal () > #38 0x92ee9e0e in SendEventToEventTarget () > #39 0x92efcbc6 in ToolboxEventDispatcherHandler () > #40 0x92ece37c in DispatchEventToHandlers () > #41 0x92ecd3fd in SendEventToEventTargetInternal () > #42 0x92ee9e0e in SendEventToEventTarget () > #43 0x92fcbab5 in SendTSMEvent () > #44 0x93009314 in SendUnicodeTextAEToUnicodeDoc () > #45 0x92fca03b in TSMKeyEvent () > #46 0x92f1db13 in TSMProcessRawKeyEvent () > #47 0x930761a5 in HandleCompatibilityKeyEvent () > #48 0x92ec9c07 in HIApplication::EventHandler () > #49 0x92ecdfc3 in DispatchEventToHandlers () > #50 0x92ecd3fd in SendEventToEventTargetInternal () > #51 0x92ecd262 in SendEventToEventTargetWithOptions () > #52 0x92efcafa in ToolboxEventDispatcherHandler () > #53 0x92ece37c in DispatchEventToHandlers () > #54 0x92ecd3fd in SendEventToEventTargetInternal () > #55 0x92ee9e0e in SendEventToEventTarget () > #56 0x92f57110 in ToolboxEventDispatcher () > #57 0x92faa4b0 in GetOrPeekEvent () > #58 0x92faa17a in GetNextEventMatchingMask () > #59 0x92fa9f96 in WNEInternal () > #60 0x92fa9ef5 in WaitNextEvent () > #61 0x00e16b1a in LLWindowMacOSX::gatherInput (this=0x6e45e00) at > /Users/home/SLOrig/linden/indra/newview/../llwindow/llwindowmacosx.cpp:1159 > #62 0x00c1d222 in LLAppViewer::mainLoop (this=0x7235f10) at > /Users/home/SLOrig/linden/indra/newview/llappviewer.cpp:921 > #63 0x00c29358 in main (argc=1, argv=0xbffff6d0) at > /Users/home/SLOrig/linden/indra/newview/llappviewermacosx.cpp:88 > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- ===================================================================== Dana Fagerstrom Phone: 877.851.6343 Sun Services Fax: 877.851.6343 400 Atrium Dr. Email: dana.fagerstrom@Sun.COM Somerset, NJ 08873 SneakerNet: USMT01 ===================================================================== Pressure - It can turn a lump of coal into a flawless diamond, and an average person into a perfect basketcase. -- www.despair.com ===================================================================== From tofu.linden at lindenlab.com Thu Apr 17 05:11:42 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Apr 17 05:11:39 2008 Subject: [sldev] Victory Conditions In-Reply-To: References: <20080417034541.E1F1341B36A@stupor.lindenlab.com> Message-ID: <48073E7E.7010702@lindenlab.com> Some FYIs: Paul Cook wrote: > 1. The list simply fails to load, showing waiting/loading/hippos > permanantly. It is acceptable, and even expected, that this would appear > on there temporarily, The problem occurs when one has been online for > several minutes, and still nothing shows. This is believed fixed, since around 1.19.1. > 1. Attachments messing up on region crossing.. > > This frequently and annoyiingly happens. The avatar's attachments often > simply vanish, or move to odd locations like the waist. Hud devices > especially, simply vvanish. The attachments-in-butt part of this is believed fixed since 1.19.1, though there may be other issues. -Tofu From jpirkola at gmail.com Thu Apr 17 05:17:03 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Thu Apr 17 05:17:07 2008 Subject: [sldev] realXtend viewer builds for Mac and Linux - help needed Message-ID: <6c9557390804170517w3f8947cemcc21be6c152a5fdc@mail.gmail.com> Dear all, We have received a lot of questions whether we are going to offer Mac and/or linux version of the realXtend viewer. Currently we have no such developers in the project that could do those builds. If you feel that you can help us, please contact me! Best regards, Jani Pirkola realXtend program manager -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/04d12484/attachment-0001.htm From tom at streamsense.net Thu Apr 17 09:06:26 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu Apr 17 09:06:39 2008 Subject: [sldev] realXtend viewer builds for Mac and Linux - help needed In-Reply-To: <6c9557390804170517w3f8947cemcc21be6c152a5fdc@mail.gmail.com> References: <6c9557390804170517w3f8947cemcc21be6c152a5fdc@mail.gmail.com> Message-ID: <48077582.2090208@streamsense.net> Jani Pirkola wrote: > Dear all, > > We have received a lot of questions whether we are going to offer Mac > and/or linux version of the realXtend viewer. Are you at least going to fix the 64 bit incompatibilities with the server? :) Tom From aimee at ama-zing.co.uk Thu Apr 17 09:56:34 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Apr 17 09:56:40 2008 Subject: [sldev] Patch for joystick control of vehicles Message-ID: <673477CD-C09B-4D89-9382-31018685ABF2@ama-zing.co.uk> I just posted a patch to allow the Space Navigator (or whatever) to work with vehicles if anyone wants to do some fun testing :) http://jira.secondlife.com/browse/VWR-6432 Aimee T. From lenglish5 at cox.net Thu Apr 17 09:57:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Apr 17 09:57:44 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <427D7A8B-1633-40F8-89FA-4F4154DDD842@gmail.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <427D7A8B-1633-40F8-89FA-4F4154DDD842@gmail.com> Message-ID: <48078186.1010806@cox.net> Argent Stonecutter wrote: > On the subject of refactoring the GUI, the last time this came up > there was a suggestion that teh LL GIO be made a portable toolkit > rather than using a portable OpenGL toolkit for the GUI. After looking > at the LL GUI code, I believe that it would probably be better to > throw Linden Labs support behind one of the existing OpenGL GUI > toolkits. It's pretty specialized and missing a lot of basic > functionality like automatically cropping or wrapping text in widgets... How extensible are such toolkits? Can they have simple skins? What about animated skins? A game-oriented GUI has needs that business-oriented ones do not and while SL isn't JUST a game, there are game-like features, and many games can-be/have-been created using SL as a games platform. Any GUI toolkit used for the main SL viewer should be extensible on those areas. It's not enough that it is simply better/cleaner than the current GUI. That's a given, IMHO. Lawson From stephany at lindenlab.com Thu Apr 17 10:33:16 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Thu Apr 17 10:33:19 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project Message-ID: <480789DC.4050306@lindenlab.com> Hi, SLDEV - Linden Lab is kicking off a new project, focused on navigation within the viewer, that is different from others we've done. How is it different? First, Vectorform, a third-party software development company, will complete the design and implementation work for this project, rather than Linden Lab. Vectorform will work closely with Linden Lab, and their team is very familiar with Second Life as residents, Help Island mentors, and developers. This project will be public. This means that: * Many tasks will be visible in PJIRA. We aren't yet in a position to publish all planned tasks, but you will see many more than we've traditionally published with new projects. * Vectorform will check their code into a public branch (that you can check it out of). * Weekly project updates will be sent to public email lists like SLDEV, just as they are to internal lists at Linden Lab. * Resident participation is not only welcome but strongly encouraged. * PJIRA tasks and wiki pages will be available in the near future. We will kick this project off publicly, today, at Benjamin Linden 's office hour, 2pm (Pacific) in Beaumont . The next two office hours will be dedicated to soliciting your feedback and input on this project as it gets started. You can meet the Vectorform team at Benjamin Linden's office hour today, and read more about them at: http://www.vectorform.com/secondlife/ If you have any questions about this project, please email the sldev list or Benjamin Linden (benglenn@lindenlab.com) or Stephany Linden (stephany@lindenlab.com) directly. Thanks, Stephany -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/89b501e3/attachment.htm From email at consultantpm.com Thu Apr 17 10:59:17 2008 From: email at consultantpm.com (email@consultantPM.com) Date: Thu Apr 17 10:59:44 2008 Subject: [sldev] PJIRA separation Message-ID: PJIRA separation Rob Said: "We've recently discussed making a matching PJIRA resolution, and concluded that a) we can't, because we still want to allow votes and b) we'd get a public flogging over it." PM comment: Perhaps later such differentiation can work to better address the concerns of the two disparate JIRA participant sectors. Two distinct concern user sets worthy of separating are inworld-resident-end-users and open-source-programmers at work within JIRA. I recognize that somehow separating these user sets, can in general better address the customer friendly message concerns of each set. So, with the right PR, instead of public backlash, that notion could be presented as win-win. Rather the task is distinguishing resolution titles, or even much greater overall separation to different PJIRA and JIRA interface portal view experiences. With the right nomenclature, for instance name SL-User-JIRA for what is referred to as PJIRA, in addition to the existing name JIRA, perhaps. I can see that if a separate PJIRA (resolution status, et cetera ) is helpful to not interfere with, and to allow daily tech work to be more clearly organized and completed, then that makes sense to me. It is a daunting task for JIRA to both support open-source-programmers for all various 3D metaverse platforms; while dealing with the existing inworld SL user base concerns. Note: I make no claim to assured PR success of this statement "So, with the right PR, instead of public backlash, that notion could be presented as win-win". If I were tasked as responsible for PR success, I would lower expectations to just "LESS public backlash". ========== Public Audit Trail Rob said: "It's also more a question of observability. I'm not interested in abstract discussions about issue trackers we don't have access to. I'm interested in having a discussion about something with a public audit trail that we're all on a level playing field when we discuss pros/cons." PM comment: So, I think I am reading the problem here is many duplicate issues make it difficult to get a read on actual public votes on a specific issue. Here is a quick sketch process: Say the formal voting on issues only occurs at a separate PJIRA interface. Issues appear for voting only after being moved from the JIRA to the PJIRA. Movers of issues to PJIRA for voting are Lindens or their properly deputized volunteers. That might lead to a cleaner exact number of voter tally for auditing distinct issues. This is only a process change using the existing JIRA features. ========== Victory Conditions Obviously, just a tolerable standard condition I look forward to appreciating will be to have my JIRA comment privilege restored. Besides allocating Linden staff to the oversight of volunteer JIRA stewards, a standardized disciplinary process should be duplicated (or administered by the same team that heads up) the Second Life Community Incident Report. This inworld Community Incident Report (police blotter) seems to issue a more severe account suspension for 1 week. In contrast, my JIRA comment abilities have been suspended for an ongoing month now. https://lists.secondlife.com/pipermail/sldev/2008-March/008796.html https://lists.secondlife.com/pipermail/sldev/2008-March/008790.html I hear Q's comment about noticing the good stuff when it happens. I lift my rock concert lighter to the dedicated work of all Lindens. Have a good weekend ========================= Paul Meriwether consultantPM.com ========================= -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080417/e1cba801/attachment.htm From robla at lindenlab.com Thu Apr 17 17:29:23 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Apr 17 17:29:27 2008 Subject: [sldev] wiki.secondlife.com/jira.secondlife.com intermittent downtime tonight (8pm-2am PDT) Message-ID: <4807EB63.9080604@lindenlab.com> Hi folks, We expect some brief, intermittent disruptions of jira.secondlife.com and wiki.secondlife.com this evening for a six hour window starting at 8pm PDT tonight. Among the stuff being worked on: - Core network infrastructure upgrades and re-configuration (routing, switching, firewalling, power, etc.) - Core server platform upgrades and configuration (routine OS maintenance, upgrades, etc.) - High-availability failover/failback testing of various devices and systems - Other minor disruptive and non-disruptive maintenance work as needed Sorry for the late notice. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080417/84a21d07/signature.pgp From gigstaggart at gmail.com Thu Apr 17 18:27:46 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Apr 17 18:27:51 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4CB3C6E4-EF1A-4015-B417-C590C97098B5@lindenlab.com> References: <48064D58.5050003@gmail.com><48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com><4806975A.1010805@lindenlab.com> <4806A5CA.6000700@gmail.com> <4CB3C6E4-EF1A-4015-B417-C590C97098B5@lindenlab.com> Message-ID: <4807F912.8000005@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kent Quirk (Q Linden) wrote: > If you're going to invalidate examples, I think we also have to > consider the rate of change of the underlying systems. Ghostscript is > basically an implementation of Postscript. According to Wikipedia, the > last change to the Postscript spec was in 1997. I *hope* by now it has > very few bugs! Well, I see your point, but keep in mind GS also implements the PDF spec, which is an 1100 page document. New versions of it come out every couple years too. - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIB/kSvPhJdUgWbXsRAgTpAKC/iEz8q8ADrjgtRIklZ/6dbFDbjgCguA1K ETBU32U0yem48VINHZe2CNI= =Oxjo -----END PGP SIGNATURE----- From lenglish5 at cox.net Thu Apr 17 19:44:32 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Apr 17 19:44:33 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4807F912.8000005@gmail.com> References: <48064D58.5050003@gmail.com><48066426.9020807@lindenlab.com> <4806737B.3070105@watson.ibm.com><4806975A.1010805@lindenlab.com> <4806A5CA.6000700@gmail.com> <4CB3C6E4-EF1A-4015-B417-C590C97098B5@lindenlab.com> <4807F912.8000005@gmail.com> Message-ID: <48080B10.1020207@cox.net> Jason Giglio wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kent Quirk (Q Linden) wrote: > >> If you're going to invalidate examples, I think we also have to >> consider the rate of change of the underlying systems. Ghostscript is >> basically an implementation of Postscript. According to Wikipedia, the >> last change to the Postscript spec was in 1997. I *hope* by now it has >> very few bugs! >> > > Well, I see your point, but keep in mind GS also implements the PDF > spec, which is an 1100 page document. New versions of it come out every > couple years too. > > > /me hates both. QuickDraw GX forever!. Seriously, it would have been nice for someone in the OS community to notice that there was something better than PostSCript and pdf out there, but I guess it makes sense to assume that Apple doesn't support their own products they can't be any good (leaving aside internal and external politics issues that trump technical superiority, of course). Ironically, the patents on both TrueType AND GX fonts are expired, so an OpenSource implementation of them would certainly be possible, but again, no-one pays attention to Apple. (you should hear my rant about how QUickDraw regions have been left behind even though they are perfect for 3D ROI volume descriptions in medical imaging). Lawson From sammy.frederix at gmail.com Thu Apr 17 17:06:17 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Thu Apr 17 21:11:24 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds In-Reply-To: <48070C1B.7030606@gmail.com> References: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> <48070C1B.7030606@gmail.com> Message-ID: On 17/04/2008, at 6:36 PM, Robin Cornelius wrote: > Sammy Frederix wrote: >> Has anyone else been seeing "ERROR: assert_glerror: GL Error:invalid >> value" when running debug builds of the >> Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to >> take >> one with Control-` ? >> There have been a few issues on this branch. r481 is old news >> though ;-) > Soft dropped an update r487 on that branch last night, i would give > your > code an update and try again, i think it fixes this. Bah. I misread svn's status, and I am on 486 (svn isn't offering me r487 on that branch), sorry about that. From sammy.frederix at gmail.com Thu Apr 17 17:23:19 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Thu Apr 17 21:11:37 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds In-Reply-To: <48073C9B.90802@sun.com> References: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> <48073C9B.90802@sun.com> Message-ID: On 17/04/2008, at 10:03 PM, Dana Fagerstrom wrote: > Sammy, > This is likely https://jira.secondlife.com/browse/VWR-6343 > The workaround reported by Fooke, disabling Avatar Imposters and > Atmospheric Shaders, works great on all platforms I've tested. Sadly it's a different bug - I've been running around without Avatar Imposters and any shaders (and have re-tested it with all shaders except Atmospheric), and it still crashes. I'll play with it more later on (to try to find out what options cause it, specifically) and file a Jira. > Sammy Frederix wrote: >> Has anyone else been seeing "ERROR: assert_glerror: GL >> Error:invalid value" when running debug builds of the >> Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to >> take one with Control-` ? >> It's been happening to me on the Mac, but only with Development >> (Debug) builds. It crashes before the Save as dialogue box is >> displayed. Deployment builds get to the save as dialogue and I can >> save perfectly. >> I'm not sure if it's related to https://jira.secondlife.com/browse/VWR-3529 >> or not, because Deployment builds work fine for me (even ones I've >> built myself). >> Regards, >> Sammy >> Console error: >> 2008-04-17T00:58:49Z llwindow/llgl.cpp(959) : error >> 2008-04-17T00:58:49Z ERROR: assert_glerror: GL Error:invalid value >> System: >> Model Name: MacBook Pro 15" >> Model Identifier: MacBookPro2,2 >> Chipset Model: ATY,RadeonX1600 >> VRAM (Total): 256 MB >> Vendor: ATI (0x1002) >> ROM Revision: 113-xxxxxx-158 >> EFI Driver Version: 01.00.158 >> System Version: Mac OS X 10.5.2 (9C7010) >> Kernel Version: Darwin 9.2.2 From matthew.dowd at hotmail.co.uk Fri Apr 18 00:53:40 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Apr 18 00:53:42 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480789DC.4050306@lindenlab.com> References: <480789DC.4050306@lindenlab.com> Message-ID: Sorry to be picky but for those of us who can't attend the office hours, is there a description of what the project will do (as opposed to how the project will be managed)? thanks Matthew Date: Thu, 17 Apr 2008 10:33:16 -0700From: stephany@lindenlab.comTo: sldev@lists.secondlife.comSubject: [sldev] Linden Lab Navigations and Landmark Project Hi, SLDEV - Linden Lab is kicking off a new project, focused on navigation within the viewer, that is different from others we've done. How is it different? First, Vectorform, a third-party software development company, will complete the design and implementation work for this project, rather than Linden Lab. Vectorform will work closely with Linden Lab, and their team is very familiar with Second Life as residents, Help Island mentors, and developers. This project will be public. This means that:* Many tasks will be visible in PJIRA. We aren't yet in a position to publish all planned tasks, but you will see many more than we've traditionally published with new projects. * Vectorform will check their code into a public branch (that you can check it out of).* Weekly project updates will be sent to public email lists like SLDEV, just as they are to internal lists at Linden Lab.* Resident participation is not only welcome but strongly encouraged. * PJIRA tasks and wiki pages will be available in the near future. We will kick this project off publicly, today, at Benjamin Linden?s office hour, 2pm (Pacific) in Beaumont. The next two office hours will be dedicated to soliciting your feedback and input on this project as it gets started. You can meet the Vectorform team at Benjamin Linden's office hour today, and read more about them at:http://www.vectorform.com/secondlife/ If you have any questions about this project, please email the sldev list or Benjamin Linden (benglenn@lindenlab.com) or Stephany Linden (stephany@lindenlab.com) directly. Thanks,Stephany _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080418/0c2dcc4f/attachment.htm From matthew.dowd at hotmail.co.uk Fri Apr 18 00:54:34 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Apr 18 00:54:37 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480789DC.4050306@lindenlab.com> References: <480789DC.4050306@lindenlab.com> Message-ID: Sorry to be picky but for those of us who can't attend the office hours, is there a description of what the project will do (as opposed to how the project will be managed)? thanks Matthew Date: Thu, 17 Apr 2008 10:33:16 -0700From: stephany@lindenlab.comTo: sldev@lists.secondlife.comSubject: [sldev] Linden Lab Navigations and Landmark Project Hi, SLDEV - Linden Lab is kicking off a new project, focused on navigation within the viewer, that is different from others we've done. How is it different? First, Vectorform, a third-party software development company, will complete the design and implementation work for this project, rather than Linden Lab. Vectorform will work closely with Linden Lab, and their team is very familiar with Second Life as residents, Help Island mentors, and developers. This project will be public. This means that:* Many tasks will be visible in PJIRA. We aren't yet in a position to publish all planned tasks, but you will see many more than we've traditionally published with new projects. * Vectorform will check their code into a public branch (that you can check it out of).* Weekly project updates will be sent to public email lists like SLDEV, just as they are to internal lists at Linden Lab.* Resident participation is not only welcome but strongly encouraged. * PJIRA tasks and wiki pages will be available in the near future. We will kick this project off publicly, today, at Benjamin Linden?s office hour, 2pm (Pacific) in Beaumont. The next two office hours will be dedicated to soliciting your feedback and input on this project as it gets started. You can meet the Vectorform team at Benjamin Linden's office hour today, and read more about them at:http://www.vectorform.com/secondlife/ If you have any questions about this project, please email the sldev list or Benjamin Linden (benglenn@lindenlab.com) or Stephany Linden (stephany@lindenlab.com) directly. Thanks,Stephany _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080418/a82d70ad/attachment-0001.htm From tateru.nino at gmail.com Fri Apr 18 03:58:12 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Apr 18 04:03:18 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> Message-ID: <48087EC4.505@weblogsinc.com> I gather from a rough summary that it's a more flock-like sort of behavior. Taggable, arrangeable bookmarks (shareable), history, that sort of thing. Lord knows, it's already impossible for me to find anything in my landmarks 2 times out of 3. Matthew Dowd wrote: > Sorry to be picky but for those of us who can't attend the office > hours, is there a description of what the project will do (as opposed > to how the project will be managed)? > > thanks > > Matthew > > > > > ------------------------------------------------------------------------ > Date: Thu, 17 Apr 2008 10:33:16 -0700 > From: stephany@lindenlab.com > To: sldev@lists.secondlife.com > Subject: [sldev] Linden Lab Navigations and Landmark Project > > Hi, SLDEV - > > Linden Lab is kicking off a new project, focused on navigation > within the viewer, that is different from others we've done. How > is it different? > > First, Vectorform, a third-party software development company, > will complete the design and implementation work for this project, > rather than Linden Lab. Vectorform will work closely with Linden > Lab, and their team is very familiar with Second Life as > residents, Help Island mentors, and developers. > > This project will be public. This means that: > * Many tasks will be visible in PJIRA. We aren't yet in a > position to publish all planned tasks, but you will see many more > than we've traditionally published with new projects. > * Vectorform will check their code into a public branch (that you > can check it out of). > * Weekly project updates will be sent to public email lists like > SLDEV, just as they are to internal lists at Linden Lab. > * Resident participation is not only welcome but strongly encouraged. > * PJIRA tasks and wiki pages will be available in the near future. > > We will kick this project off publicly, today, at Benjamin Linden > ?s office > hour, 2pm (Pacific) in Beaumont > . > The next two office hours will be dedicated to soliciting your > feedback and input on this project as it gets started. > > You can meet the Vectorform team at Benjamin Linden's office hour > today, and read more about them at: > http://www.vectorform.com/secondlife/ > > If you have any questions about this project, please email the > sldev list or Benjamin Linden (benglenn@lindenlab.com > ) or Stephany Linden > (stephany@lindenlab.com ) directly. > > Thanks, > > Stephany > > > ------------------------------------------------------------------------ > Get fish-slapping on Messenger Play now! > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From kfa at gmx.net Fri Apr 18 04:07:21 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 04:07:30 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4806D58C.7050103@cox.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> Message-ID: <480880E9.2060305@gmx.net> Lawson English wrote: > I've said it before (and I'm saying it again): the single most > important thing that can be done to reduce client-bugs in the long-run > is to refactor the GUI away from the rest of the client code-base. > The GUI kinda seeps into everything and it's virtually impossible to > change the GUI in substantial ways without impacting the rest of the > code, and whenever you touch most of the non-GUI code, you must take > into account the interactions of the GUI with that section of code > during your analysis--even at the highest and lowest levels of the > analysis. Not sure how closely this is related, maybe this needs a different subject line. But here is what I keep thinking when pouring over the source: There is quite a heavy dependency of the viewer application on the correctness of added resources. In other words, hard coded parts of the program need outside resources to be correctly structured or they would fail. I really mean structure, not just language dependent snipplets of text, or colors or the like. Examples of that are keywords.ini and the entire GUI skin files collection, and certainly some more parts of the viewer which I'm not yet too familiar with. I always thought this is awkward. Shouldn't we do it e.g. in the fashion the Qt toolkit works: with a preprocessor that turns the xml gui definitions into code at compile time, with the language being a configurable parameter. These things are not dynamic anyway, so why aren't they part of the main app? This would save us having to distribute all those files with the release viewer, and make the GUI elements display faster. Language overlays or custom skins could still be made dynamic by placing such things in user's overlay directory, in case it's not feasible to provide a compiled viewer for a specific configuration. If no overlay file for a floater or panel exists, nothing needs to be parsed. I may be totally off with this, missing out a mention of the reasons for why the current structure is the way it is. Can someone help with a pointer if that is the case? Felix From kfa at gmx.net Fri Apr 18 04:21:45 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 04:21:51 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <480880E9.2060305@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> Message-ID: <48088449.3030305@gmx.net> sorry, slight correction of my previous post: Felix Duesenburg wrote: > - Language overlays or custom skins could still be made dynamic by placing > + Language overlays or custom skins could still be made tweakable by > placing From secret.argent at gmail.com Fri Apr 18 04:35:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 18 04:35:50 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <48087EC4.505@weblogsinc.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> Message-ID: On 2008-04-18, at 05:58, Tateru Nino wrote: > Lord knows, it's already impossible for me to find anything in my > landmarks 2 times out of 3. I think just limiting the landmarks shown in the map to the landmarks in your "Landmarks" folder would make landmark management SO much easier... plus let the map come up more quickly since it wouldn't have to grovel through your whole inventory... I have to periodically go through my inventory with the filter set to landmarks and delete landmarks or put them in boxes to keep them from cluttering up the map. From secret.argent at gmail.com Fri Apr 18 04:37:49 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 18 04:37:37 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <480880E9.2060305@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> Message-ID: <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> On 2008-04-18, at 06:07, Felix Duesenburg wrote: > I always thought this is awkward. Shouldn't we do it e.g. in the > fashion the Qt toolkit works: with a preprocessor that turns the > xml gui definitions into code at compile time, with the language > being a configurable parameter. These things are not dynamic > anyway, so why aren't they part of the main app? Because then they wouldn't be skinnable or editable and you wouldn't be able to go in and say "if you remove this section from your overlay panel xml file you can get rid of the damned release keys button". From kfa at gmx.net Fri Apr 18 04:48:38 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 04:48:46 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> Message-ID: <48088A96.3080007@gmx.net> Argent Stonecutter wrote: > On 2008-04-18, at 06:07, Felix Duesenburg wrote: >> I always thought this is awkward. Shouldn't we do it e.g. in the >> fashion the Qt toolkit works: with a preprocessor that turns the xml >> gui definitions into code at compile time, with the language being a >> configurable parameter. These things are not dynamic anyway, so why >> aren't they part of the main app? > > Because then they wouldn't be skinnable or editable and you wouldn't > be able to go in and say "if you remove this section from your overlay > panel xml file you can get rid of the damned release keys button". It doesn't occur to me that this is a feature people really want. Is it? If those who like to edit their gui files happen to be mostly developers (which I cannot verify), wouldn't it suffice that they can compile their own? The whole thing would run faster and more reliable. I've made this point a little earlier in another thread about user contributions of language translations, but I guess it went under because it was beyond the scope of that thread. From aimee at ama-zing.co.uk Fri Apr 18 04:55:58 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Apr 18 04:56:06 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> Message-ID: <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> On Apr 18, 2008, at 12:35, Argent Stonecutter wrote: > I have to periodically go through my inventory with the filter set > to landmarks and delete landmarks or put them in boxes to keep them > from cluttering up the map. Duplicate detection based on UUID would help too, but that's something not limited to landmarks. Aimee. From secret.argent at gmail.com Fri Apr 18 05:14:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 18 05:14:02 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48088A96.3080007@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> Message-ID: <63078284-F15C-4029-99ED-6FFD90020F54@gmail.com> On 2008-04-18, at 06:48, Felix Duesenburg wrote: > Argent Stonecutter wrote: >> On 2008-04-18, at 06:07, Felix Duesenburg wrote: >>> I always thought this is awkward. Shouldn't we do it e.g. in the >>> fashion the Qt toolkit works: with a preprocessor that turns the >>> xml gui definitions into code at compile time, with the language >>> being a configurable parameter. These things are not dynamic >>> anyway, so why aren't they part of the main app? >> >> Because then they wouldn't be skinnable or editable and you >> wouldn't be able to go in and say "if you remove this section from >> your overlay panel xml file you can get rid of the damned release >> keys button". > > It doesn't occur to me that this is a feature people really want. > Is it? It's a feature that most people don't care about most of the time, but when they do need it they REALLY need it. I have provided patches for these files on Jira and on the blog and in-world and people have been VERY grateful for them. > If those who like to edit their gui files happen to be mostly > developers (which I cannot verify), wouldn't it suffice that they > can compile their own? I'm a developer, but I don't want to have to maintain a development environment on Windows as well as OS X to tweak the viewer. And every time I read this list and see more questions about compatibility problems with this or that version of visual studio that gets reinforced. > The whole thing would run faster and more reliable. It wouldn't be significantly faster... these files are only read at startup and they're not a significant part of the startup process. It wouldn't be significantly more reliable. I don't think I have have EVER had a problem caused by these files, except where I caused it by editing them... and whether I was rebuilding the client after editing them or not wouldn't make much difference there. As for language translations... you want to require translators to be translators as well? From kfa at gmx.net Fri Apr 18 05:24:32 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 05:24:39 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <63078284-F15C-4029-99ED-6FFD90020F54@gmail.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <63078284-F15C-4029-99ED-6FFD90020F54@gmail.com> Message-ID: <48089300.9090302@gmx.net> Argent Stonecutter wrote: > On 2008-04-18, at 06:48, Felix Duesenburg wrote: >> Argent Stonecutter wrote: >>> On 2008-04-18, at 06:07, Felix Duesenburg wrote: >>>> I always thought this is awkward. Shouldn't we do it e.g. in the >>>> fashion the Qt toolkit works: with a preprocessor that turns the >>>> xml gui definitions into code at compile time, with the language >>>> being a configurable parameter. These things are not dynamic >>>> anyway, so why aren't they part of the main app? >>> > >>> Because then they wouldn't be skinnable or editable and you wouldn't >>> be able to go in and say "if you remove this section from your >>> overlay panel xml file you can get rid of the damned release keys >>> button". >> > >> It doesn't occur to me that this is a feature people really want. Is it? > > It's a feature that most people don't care about most of the time, but > when they do need it they REALLY need it. I have provided patches for > these files on Jira and on the blog and in-world and people have been > VERY grateful for them. > >> If those who like to edit their gui files happen to be mostly >> developers (which I cannot verify), wouldn't it suffice that they can >> compile their own? > > I'm a developer, but I don't want to have to maintain a development > environment on Windows as well as OS X to tweak the viewer. And every > time I read this list and see more questions about compatibility > problems with this or that version of visual studio that gets reinforced. > >> The whole thing would run faster and more reliable. > > It wouldn't be significantly faster... these files are only read at > startup and they're not a significant part of the startup process. > > It wouldn't be significantly more reliable. I don't think I have have > EVER had a problem caused by these files, except where I caused it by > editing them... and whether I was rebuilding the client after editing > them or not wouldn't make much difference there. > > As for language translations... you want to require translators to be > translators as well? > Thank you for the clarification, I see the point. I remember now one more aspect that led me to raising this, which is a security concern. Something could overwrite these files and do things like swapping the 'yes' and 'no' labels on the payment permission dialog. See the recent thread titled "Handling open source translations". From aimee at ama-zing.co.uk Fri Apr 18 05:58:30 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Apr 18 05:58:36 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48088A96.3080007@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> Message-ID: <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> On Apr 18, 2008, at 12:48, Felix Duesenburg wrote: > It doesn't occur to me that this is a feature people really want. > Is it? If those who like to edit their gui files happen to be > mostly developers (which I cannot verify), wouldn't it suffice that > they can compile their own? The whole thing would run faster and > more reliable. I guess you haven't been following the Dazzle debate then; people are desperate for proper user skinning to happen before the new colour scheme goes live. It causes eyestrain and migraines for a significant number of people, and breaks some fundamental principles of good GUI design. Packaged skins would at least allow those people that aren't happy messing around with the files directly some choice, with a little security that the changes aren't going to get broken with each update. https://wiki.secondlife.com/wiki/Skinning - note Dazzle and the new skin in Phase 0, skinning not till Phase 1. A completely avoidable PR issue, why upset people introducing Phase 0 when it's all going to be moot anyway once Phase 1 is ready? It makes no sense; it's like standing by and watching a friend walk off a cliff. http://jira.secondlife.com/browse/VWR-5059 and http:// jira.secondlife.com/browse/VWR-5080 Aimee T. From jessesa at gmail.com Fri Apr 18 06:01:00 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Fri Apr 18 06:01:04 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception Message-ID: I've been mulling over chiming in on this topic for a couple of days now. Just my personal POV, but I don't really care about the ratios of other companies bugs, SL is the only one that matters. I can also understand and sympathize with the problems of solving poorly documented intermittent bugs with no clear replication. It might not be a bad idea to go with some kind of flag system to differintiate between Bob/Susie Homemaker's bugs stating "It doesn't work when I push the button" from vetted contributors who give clear repro and or patches. But this does beg the million dollar question; Why exactly is it that some bugs/patches from people like Strife have been ignored when not only the problem is pointed out but the solution is handed over on a silver platter? (I am aware that many of Strife's have been accepted) Why is it that LL is now faced with the PR nightmare of Nicholas's Blog? His fixes/viewers were used by a multitude of people because THEY WERE MORE STABLE and fixed some really annoying problems. His fixes were clearly popular but more importantly all of the work was already done. Fixes that had already been alpha and beta checked and went into production with no problems. It all just adds to the other old PR problems: "LL only works on what they want" and the one I hate the worst: "Stop new features and fix bugs". (Clarification: I personally do not support this view and know we need to move forward). But please always keep in mind and understand that there is some justification behind those two rants. We have problems like the forums still not fixed after all of this time and now with no moderation even thou a list from Strife was submitted of names of qualified volunteers. Come on guys/gals. Realistically, what are we looking at? 20 man hours to fix that one? Seems ludicrous that none at LL understands that this is and will always be the best and irreplaceable definitive source for content creation information. And as pointed out in another thread, valid and important points were completely ignored from the community concerning dazzle. The sky isn't falling and anyone that says SL will loose people is delusional, clearly, many more come in then are lost. Also I acknowledge that before JIRA, everyone of my bugs that I had clear repro on in Siva/Aditi were fixed. Have said it before and will say it again that the QA team rocks!!! Post JIRA, my measely 2 JIRA entries with clear repro were both fixed. But can we at least get past the hurt feelings and acknowledge that maybe rethinking does need to be done in how some problems are handled? Just my early morning/overly caffienated POV, Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080418/298a78fd/attachment.htm From kfa at gmx.net Fri Apr 18 06:49:01 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 06:49:08 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: References: Message-ID: <4808A6CD.2020309@gmx.net> Just having this idea and shooting it off before clear vision kicks in... How about creating a regular incentive called "Patch of the month", awarded monthly (of course) to the best contributed patch that gets taken into the release viewer, coupled with the promise that at least one /does/ get accepted. Throw in a little prize, like L$10,000 or so. Before dismissing it, please let me explain that I'm thinking with a little twist here: This is not meant as an incentive for OS developers to contribute code more than they already do. That's clearly not needed, the motivation is there. It's also not meant to compensate OS contributors, because that would likely violate a number of regulations and good customs. Not to mention that the sum would be too meager to make up for the actual value. Instead, it is intended to implement a regular procedure inside of LL with which they oblige themselves to care for these contributions and make a deliberate effort to include them. At least once per month. This could only be torpedoed by a lack of quality input, but I don't think this would be happening too soon. Opinions? Felix, unfolding his umbrella From lenglish5 at cox.net Fri Apr 18 12:24:44 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 18 12:24:49 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> Message-ID: <4808F57C.3070305@cox.net> Aimee Walton wrote: > > I guess you haven't been following the Dazzle debate then; people are > desperate for proper user skinning to happen before the new colour > scheme goes live. It causes eyestrain and migraines for a significant > number of people, and breaks some fundamental principles of good GUI > design. Packaged skins would at least allow those people that aren't > happy messing around with the files directly some choice, with a > little security that the changes aren't going to get broken with each > update. > > https://wiki.secondlife.com/wiki/Skinning - note Dazzle and the new > skin in Phase 0, skinning not till Phase 1. A completely avoidable PR > issue, why upset people introducing Phase 0 when it's all going to be > moot anyway once Phase 1 is ready? It makes no sense; it's like > standing by and watching a friend walk off a cliff. It's an issue with the number of beta testers. More people are willing to try a first look client than a beta test. More people are willing to try an RC than a first look. And for something like this they need huge numbers of beta testers and they just don't get them. Maybe it would be possible to roll Dazzle back to "first look" or even "second look" and explain this is a test of features, tell us what you like and don't like.... But it still needs to be on the main grid or they don't' get enough feedback. Personally, (horns blaring) I think the GUI needs to be refactored from the ground up, as I have said. The crazy patchwork of classes that is the viewer GUI is virtually unmanageable, so all these changes are overly risky as far as introducing side-effect bugs. The hierarchy of the classes--even how they are grouped in files--makes it extremely difficult to modify, letalone rationally "extend" behavior. The GUI itself is dependent on global variables that are poorly documented, and often have nothing to do with a normal GUI at all. Folders and their helper classes are intertwined quite tightly with server interactions. Inventory folders are the only type of folder available. There's no possibility of creating a window with a simple hierarchical view of non-inventory data stored on the client's hard drive without having an extensive understanding of how the folder classes interrelate so you can grab that one relevant class and rewrite it for your own use. Skins, we know about. User-extensible GUI elements are impossible, at least at the level a game-like client should allow for. Programmer-extensibility is slightly less impossible, but still not-doable unless you spend a ludicrous amount of time analyzing the code. Rearranging existing elements is doable, but only in a very contrived fashion.... If anyone looks at the roadmap for GUI revision http://wiki.secondlife.com/wiki/User_Interface_Roadmap They will notice that the very bottom of the page of "future projects," what used to be called "step four," is: Create a sample UI only client In a normal system, that would be the first thing you would expect to see, but in fact, the GUI, as it stands now, needs so much reworking that a standalone GUI window ("a sample UI-only client") can only be done after the entire mess has been cleaned up. THAT is how messy and intertwined the GUI is. Why anyone seriously thinks that de-bugging the client at some higher level, while leaving the foundational mess of the GUI untouched (and the GUI IS the foundation here--there's no clear MVC divisions that make the GUI-bugs relatively separate from the rest of the system, interaction-wise), will yield a truly stable, extensible system, is beyond me. I can understand LL's reluctance to tackle the job. I can understand any individual developer's reluctance to try to do it (HELL, I have no idea where to begin), but that the development community remains almost mute on this topic while squabbling over the superficial stuff, just reveals that the SL developers community really is clueless about the fundamental issue here--or is being hypocritical in their condemnation of LL. Why are only a handful of us screaming about this issue? Why isn't it the number one priority raised over and over again in Open Source meetings, SLDEV messages, etc? It impacts everything from frame rate, to memory leaks, to GUI extensibility, to who-knows-what. I mean really, guys. Refactoring the GUI is Job Number 1. The Lindens are afraid to tackle it. You guys bury your heads in the sand. If nothing is done, the situation will only get worse and the list of bug-fixes awaiting integration will grow ever longer because dependencies on the GUI and other subsystems will continue to bite every bug-fix attempt. Lawson From gigstaggart at gmail.com Fri Apr 18 12:50:40 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Apr 18 12:50:51 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: <4808A6CD.2020309@gmx.net> References: <4808A6CD.2020309@gmx.net> Message-ID: <4808FB90.50407@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Felix Duesenburg wrote: > This is not meant as an incentive for OS developers to contribute code > more than they already do. That's clearly not needed, I disagree. The number of patches coming in is pretty low, and a lot of them are 1-liners. > the motivation is > there. It's also not meant to compensate OS contributors, because that > would likely violate a number of regulations and good customs. Not to What? Open source contributors work for money too. Bug bounties and other payment/prizes for open source code *is* the custom, I'd say. I'd say it would be exceptional for a company to not offer such things. > mention that the sum would be too meager to make up for the actual value. > Well, that's true. A more typical bounty is $500 US, which still doesn't really pay for the development, it's just an incentive. > Instead, it is intended to implement a regular procedure inside of LL > with which they oblige themselves to care for these contributions and > make a deliberate effort to include them. At least once per month. This > could only be torpedoed by a lack of quality input, but I don't think > this would be happening too soon. I don't know. It may help, but it doesn't address the root cause of the problem: That Linden Lab views themselves as a separate entity from the community; that the community development process is completely outside the actual development of the client. If anything, this might reinforce that idea. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFICPuQvPhJdUgWbXsRApLOAJ9gJJK+qoiYepYnLygzsuHpbO0eNQCfX2b2 r4FeJHiQ2EXVETkWTPK2mZs= =QRuU -----END PGP SIGNATURE----- From seg at haxxed.com Fri Apr 18 13:28:48 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 18 13:29:00 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48066426.9020807@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> Message-ID: <1208550528.22067.22.camel@localhost> On Wed, 2008-04-16 at 13:40 -0700, Rob Lanphier wrote: > How does this compare to other open source and public projects? My > suspicion is that almost every active open source project experiences > net positive growth in number of open bugs. I'd like to make sure > we're > not being measured against an unreasonably high standard. Second Life isn't just an open source project, it is a commercial open source project with *paying* customers, wherein the vast majority of development is still done by paid employees. The "open source" part is incidental, really. I don't think it's fair to measure LL against an unreasonably low standard like volunteer open source projects... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/e6f6b056/attachment.pgp From jessesa at gmail.com Fri Apr 18 13:30:58 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Fri Apr 18 13:31:03 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4808F57C.3070305@cox.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> <4808F57C.3070305@cox.net> Message-ID: On 4/18/08, Lawson English wrote: > > > I can understand LL's reluctance to tackle the job. I can understand any > individual developer's reluctance to try to do it (HELL, I have no idea > where to begin), but that the development community remains almost mute on > this topic while squabbling over the superficial stuff, just reveals that > the SL developers community really is clueless about the fundamental issue > here--or is being hypocritical in their condemnation of LL. > > Why are only a handful of us screaming about this issue? Why isn't it the > number one priority raised over and over again in Open Source meetings, > SLDEV messages, etc? It impacts everything from frame rate, to memory leaks, > to GUI extensibility, to who-knows-what. > > I mean really, guys. Refactoring the GUI is Job Number 1. The Lindens are > afraid to tackle it. You guys bury your heads in the sand. If nothing is > done, the situation will only get worse and the list of bug-fixes awaiting > integration will grow ever longer because dependencies on the GUI and other > subsystems will continue to bite every bug-fix attempt. > > > > > Lawson Actually it was discussed extensively the first few weeks of SLDev & Rob coming on board in iirc and meetings under the umbrella of plugin architecture. I would imagine that the concensus has'nt changed from that time. Yes, it is a serious problem and yes, it should be done, but no, no one wants to tackle that beast and it is more expidient to just create sockets that interface the jumbled mess in the backend for the plugins to go. You hit the nail on the head with this : "I can understand any individual developer's reluctance to try to do it (HELL, I have no idea where to begin)," It isn't just a matter of refactoring the GUI, the GUI is everywhere and would involve a major rewrite of ALL the code. The code sucks and everyone in the community and the Lindens know it sucks but continually hammering to get someone, anyone to rewrite it isn't going to be very productive. Jesse -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080418/9bc9a98b/attachment.htm From robla at lindenlab.com Fri Apr 18 13:37:26 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Apr 18 13:37:29 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <1208550528.22067.22.camel@localhost> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <1208550528.22067.22.camel@localhost> Message-ID: <48090686.9030706@lindenlab.com> On 4/18/08 1:28 PM, Callum Lerwick wrote: > On Wed, 2008-04-16 at 13:40 -0700, Rob Lanphier wrote: > >> How does this compare to other open source and public projects? My >> suspicion is that almost every active open source project experiences >> net positive growth in number of open bugs. I'd like to make sure >> we're >> not being measured against an unreasonably high standard. >> > > Second Life isn't just an open source project, it is a commercial open > source project with *paying* customers, wherein the vast majority of > development is still done by paid employees. The "open source" part is > incidental, really. > > I don't think it's fair to measure LL against an unreasonably low > standard like volunteer open source projects... > What, exactly, do you want to compare us to? Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/f3d9b8c6/signature.pgp From robla at lindenlab.com Fri Apr 18 13:47:02 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Apr 18 13:47:20 2008 Subject: [sldev] Rewriting the viewer (Re: sljirastats.com Linden Metrics Report) In-Reply-To: References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> <4808F57C.3070305@cox.net> Message-ID: <480908C6.9010909@lindenlab.com> On 4/18/08 1:30 PM, Jesse Barnett wrote: > Actually it was discussed extensively the first few weeks of SLDev & Rob coming on board in iirc > and meetings under the umbrella of plugin architecture. I would > imagine that the concensus has'nt changed from that time. Yes, it is a > serious problem and yes, it should be done, but no, no one wants to > tackle that beast and it is more expidient to just create sockets that > interface the jumbled mess in the backend for the plugins to go. You > hit the nail on the head with this : "I can understand any individual > developer's reluctance to try to do it (HELL, I have no idea where to > begin)," It isn't just a matter of refactoring the GUI, the GUI is > everywhere and would involve a major rewrite of ALL the code. The code > sucks and everyone in the community and the Lindens know it sucks but > continually hammering to get someone, anyone to rewrite it isn't going > to be very productive. I'll restate what I stated last year on this topic, pointing to this article from Joel Spolsky about Netscape: http://www.joelonsoftware.com/articles/fog0000000069.html I'm glad Firefox and Thunderbird are around, and I use both of them as my primary apps for their respective functions. However, while the approach was eventually successful in producing some really important software, it completely failed to achieve the desired result for Netscape Corporation (and for that matter, AOL after that). We intend to survive the release of our source code ;-) The viewer architecture is in much better shape than it was this time last year, and I think we have every reason to believe it will be much better next year. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/6dd4a903/signature.pgp From seg at haxxed.com Fri Apr 18 14:11:02 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 18 14:11:09 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48090686.9030706@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <1208550528.22067.22.camel@localhost> <48090686.9030706@lindenlab.com> Message-ID: <1208553062.22067.37.camel@localhost> On Fri, 2008-04-18 at 13:37 -0700, Rob Lanphier wrote: > On 4/18/08 1:28 PM, Callum Lerwick wrote: > > Second Life isn't just an open source project, it is a commercial open > > source project with *paying* customers, wherein the vast majority of > > development is still done by paid employees. The "open source" part is > > incidental, really. > > > > I don't think it's fair to measure LL against an unreasonably low > > standard like volunteer open source projects... > > > > What, exactly, do you want to compare us to? Other commercial projects with paying customers and a full time staff of in-house developers? Not really my "scene", so I can't really name any. Of course a lot of commercial projects may very well be worse than OS projects at bug closing. But then, as mentioned elsewhere, some see keeping the open bug count as near zero as possible a matter of pride and their #1 priority. Though I've also heard this attitude in some open source projects too... (Some Fedora maintainers are like this, but not all. Of course some critical components, like the kernel and xorg get such a disproportionate number of bugs it is simply not humanly possible for a small team to keep up with them, and ruthless triageing is done, but still the most serious issues are dealt with promptly...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/1c08fee0/attachment-0001.pgp From qarl at lindenlab.com Fri Apr 18 14:18:59 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Fri Apr 18 14:19:39 2008 Subject: [sldev] libre graphics open source conference Message-ID: <80AA9B2E-EE17-4E0A-A7E3-770752E22EEE@lindenlab.com> hey all - sorry for the late announcement - i'm speaking about second life and open source at the libre graphics conference, in the beginning of may in poland. libre graphics is where the blender/gimp/etc devs meet and speak. if any of you will be attending - i'd love to meet-up. http://www.libregraphicsmeeting.org/2008/index.php best, K. From seg at haxxed.com Fri Apr 18 14:28:31 2008 From: seg at haxxed.com (Callum Lerwick) Date: Fri Apr 18 14:28:39 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <480880E9.2060305@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> Message-ID: <1208554111.22067.47.camel@localhost> On Fri, 2008-04-18 at 07:07 -0400, Felix Duesenburg wrote: > There is quite a heavy dependency of the viewer application on the > correctness of added resources. In other words, hard coded parts of the > program need outside resources to be correctly structured or they would > fail. I really mean structure, not just language dependent snipplets of > text, or colors or the like. Examples of that are keywords.ini and the > entire GUI skin files collection, and certainly some more parts of the > viewer which I'm not yet too familiar with. > I may be totally off with this, missing out a mention of the reasons for > why the current structure is the way it is. Can someone help with a > pointer if that is the case? How about: Rule of Representation: Fold knowledge into data, so program logic can be stupid and robust. http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263 At the same time: Rule of Generation: Avoid hand-hacking; write programs to write programs when you can. http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878742 So arguably *automatically generated* code is acceptable. But you need to strictly disallow hand-hacking of generated code. Don't even put it in the SCM, make the build system generate it for you. But I think the real issue here is: Rule of Repair: Repair what you can ? but when you must fail, fail noisily and as soon as possible. http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538 The viewer has the "failing" part down, but fails at the graceful and noisy part. It crashes and gives you no useful diagnostic output as to what the problem is. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080418/11fc0a47/attachment.pgp From carjay at gmx.net Fri Apr 18 15:11:49 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri Apr 18 15:11:56 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: <4808FB90.50407@gmail.com> References: <4808A6CD.2020309@gmx.net> <4808FB90.50407@gmail.com> Message-ID: <48091CA5.6030400@gmx.net> Jason Giglio wrote: > I don't know. It may help, but it doesn't address the root cause of the > problem: That Linden Lab views themselves as a separate entity from the > community; that the community development process is completely outside > the actual development of the client. > True and that's actually my problem currently, too. I don't care that much about my patches not getting in the viewer but more about the lack of communication between Linden developers and OS developers. I see sldev and JIRA as a communication platform. But if you e.g. submit a source code bug on JIRA it can happen that the comment is read by a non-developer Linden first who simply marks the bug as "needs more info - resolved" instead of assigning it to the appropriate developer(s). I can understand that developers are unwillling to take a look at all the user provided JIRA entries but at least "source code" entries should be treated differently. Sometimes, there's not a reply at all. All of this is very frustrating. The lack or fear of communication due to what seems to be some kind of "culture clash" problem (open source vs. commercial development) is one of the things that need to be tackled or a lot of good developers will simply turn away because they feel their efforts going nowhere. That is not to say that there this is valid for all Lindens, quite contrary, some go out of their way to help the OS community, but they currently seem to be a noble exception. Regards, Carsten From lenglish5 at cox.net Fri Apr 18 15:17:24 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 18 15:17:33 2008 Subject: [sldev] Rewriting the viewer (Re: sljirastats.com Linden Metrics Report) In-Reply-To: <480908C6.9010909@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> <4808F57C.3070305@cox.net> <480908C6.9010909@lindenlab.com> Message-ID: <48091DF4.8010102@cox.net> Rob Lanphier wrote: > On 4/18/08 1:30 PM, Jesse Barnett wrote: >> Actually it was discussed extensively the first few weeks of SLDev & >> Rob coming on board in iirc and meetings under the umbrella of plugin >> architecture. I would imagine that the concensus has'nt changed from >> that time. Yes, it is a serious problem and yes, it should be done, >> but no, no one wants to tackle that beast and it is more expidient to >> just create sockets that interface the jumbled mess in the backend >> for the plugins to go. You hit the nail on the head with this : "I >> can understand any individual developer's reluctance to try to do it >> (HELL, I have no idea where to begin)," It isn't just a matter of >> refactoring the GUI, the GUI is everywhere and would involve a major >> rewrite of ALL the code. The code sucks and everyone in the community >> and the Lindens know it sucks but continually hammering to get >> someone, anyone to rewrite it isn't going to be very productive. > > I'll restate what I stated last year on this topic, pointing to this > article from Joel Spolsky about Netscape: > http://www.joelonsoftware.com/articles/fog0000000069.html > > I'm glad Firefox and Thunderbird are around, and I use both of them as > my primary apps for their respective functions. However, while the > approach was eventually successful in producing some really important > software, it completely failed to achieve the desired result for > Netscape Corporation (and for that matter, AOL after that). We intend > to survive the release of our source code ;-) > > The viewer architecture is in much better shape than it was this time > last year, and I think we have every reason to believe it will be much > better next year. I meant to say refactoring. If I said throw everything out and start from scratch, well, I said it wrong. Here are the problems I am aware of with the GUI: *It uses global variables that aren't documented, and apparently are tied to other subsystems in complicated, undocumented ways, which make creating standalone test-viewers impossible unless they drag substantial portions of other subsystems with them. Not only can't you test GUI's separately, you can't test the other subsystems separately either. *Certain important functionality, e.g., hierarchical folders, are tied to server communications in ways that make it very difficult, or at least, unintuitive, to create new hierarchical lists in the GUI that don't use inventory items. I threw up my hands and bypassed the whole thing: http://www.youtube.com/watch?v=kvEKiGSYm0k Dale Glass told me he figured out how to do it using the existing folder classes, but it wasn't obvious to me how he did it. GUIs are supposed to make life easier for developers, not harder, so my point stands. *Text-handling is extremely... odd. True-type fonts are used to simulate bitmapped fonts and different truetype fonts are required to simulate different text-sizes. Changing fontsizes in existing classes is a chore. For example, I wrote a simple patch to link font-sizes specified in preferences to the font size of all multi-line text except the LSL editor. It wasn't that hard to do, but required a bit of analysis of the internals of the various text-handling classes because there was no easy way to do it from outside the existing classes. I would have to rename classes and write simple interface classes to intercept the calls from other parts of the viewer, such as the XML handlers, or add a tiny snippet of code to test the status of the font-size flag set in the preferences inside the existing multi-line text editor. I chose the latter as the most easy to maintain. Just delete/comment out my 10 lines of code if a better solution is devised. *event handling is (or was, haven't looked lately) a bit odd as well. *skinning is possible only at the most superficial level. More complex customization is difficult or impossible. Customizing the behavior of the GUI elements, such as adding different kinds of sliders, wasn't even a design consideration originally (nuf said). * and likely other issues I can't recall off the top of my head. * and certainly other issues I never encountered when working on my two minor patches. Lawson From carjay at gmx.net Fri Apr 18 15:34:55 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri Apr 18 15:34:58 2008 Subject: [sldev] "ERROR: assert_glerror: GL Error:invalid value" when taking high-res snapshot in Deployment builds In-Reply-To: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> References: <8038B30D-D594-448F-8DCF-7C0A725D8857@gmail.com> Message-ID: <4809220F.3080301@gmx.net> Sammy Frederix wrote: > Has anyone else been seeing "ERROR: assert_glerror: GL Error:invalid > value" when running debug builds of the > Branch_1-20-Viewer (rev:481) when high-res snapshots and trying to > take one with Control-` ? Hm, strangely enough, this error assert is commented out for Linux even though there is a comment saying that it should be enabled for that platform, too. :) I'm tempted to turn it on and see what happens. GL's error reporting mechanism is a bit unusual in that function never directly return error codes but instead you have to check a (context-)global variable every now and then. So to pinpoint the exact call which is responsible for the "invalid" you need put a lot of glError()-calls into the code and find the spot where it changes. Regards, Carsten From stephany at lindenlab.com Fri Apr 18 16:32:42 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Fri Apr 18 16:32:44 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> Message-ID: <48092F9A.7070702@lindenlab.com> Hi everyone, Here's the pwiki page on the Landmarks and Navigation project: https://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project Also, a correction: Benjamin Linden's weekly office hour is on Thursdays at 3 PM Pacific, not at 2 PM, as my email yesterday stated. Amusingly, Ben and I both made the mistake and didn't realize it until 2 PM. Our apologies for our seemingly singed neurons and the confusion we caused. Stephany Aimee Walton wrote: > On Apr 18, 2008, at 12:35, Argent Stonecutter wrote: >> I have to periodically go through my inventory with the filter set to >> landmarks and delete landmarks or put them in boxes to keep them from >> cluttering up the map. > > Duplicate detection based on UUID would help too, but that's something > not limited to landmarks. > > Aimee. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Fri Apr 18 16:39:59 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 18 16:40:01 2008 Subject: [sldev] Rewriting the viewer (Re: sljirastats.com Linden Metrics Report) In-Reply-To: <480908C6.9010909@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <27E54679-27D7-4833-BC86-BAD37C685CA8@ama-zing.co.uk> <4808F57C.3070305@cox.net> <480908C6.9010909@lindenlab.com> Message-ID: <4809314F.9080800@cox.net> Rob Lanphier wrote: > On 4/18/08 1:30 PM, Jesse Barnett wrote: >> Actually it was discussed extensively the first few weeks of SLDev & >> Rob coming on board in iirc and meetings under the umbrella of plugin >> architecture. I would imagine that the concensus has'nt changed from >> that time. Yes, it is a serious problem and yes, it should be done, >> but no, no one wants to tackle that beast and it is more expidient to >> just create sockets that interface the jumbled mess in the backend >> for the plugins to go. You hit the nail on the head with this : "I >> can understand any individual developer's reluctance to try to do it >> (HELL, I have no idea where to begin)," It isn't just a matter of >> refactoring the GUI, the GUI is everywhere and would involve a major >> rewrite of ALL the code. The code sucks and everyone in the community >> and the Lindens know it sucks but continually hammering to get >> someone, anyone to rewrite it isn't going to be very productive. > > I'll restate what I stated last year on this topic, pointing to this > article from Joel Spolsky about Netscape: > http://www.joelonsoftware.com/articles/fog0000000069.html > > I'm glad Firefox and Thunderbird are around, and I use both of them as > my primary apps for their respective functions. However, while the > approach was eventually successful in producing some really important > software, it completely failed to achieve the desired result for > Netscape Corporation (and for that matter, AOL after that). We intend > to survive the release of our source code ;-) > > The viewer architecture is in much better shape than it was this time > last year, and I think we have every reason to believe it will be much > better next year. > > Rob > > I agree. Things have changed in drastic ways for the better since I started in SL in May of last year. And I said things badly. I didn't mean everything *needs* to be refactored, but that one has to examine what needs to be refactored from the ground up (base classes), since so many basic things are interacting in such odd ways at so many levels. Much/most of the code hopefully wouldn't need rewriting at all, or only piecemeal. And even the refactoring itself could be done piecemeal. But an understanding of where things are really pathological in their behavior is needed and all parts should be looked at as possible candidates of refactoring, no exceptions. That way, we catch all the potential gotchas (in theory at least). Lawson From kfa at gmx.net Fri Apr 18 17:01:29 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 18 17:01:35 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <1208554111.22067.47.camel@localhost> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> Message-ID: <48093659.8010907@gmx.net> Callum Lerwick wrote: > On Fri, 2008-04-18 at 07:07 -0400, Felix Duesenburg wrote: > >> There is quite a heavy dependency of the viewer application on the >> correctness of added resources. In other words, hard coded parts of the >> program need outside resources to be correctly structured or they would >> fail. I really mean structure, not just language dependent snipplets of >> text, or colors or the like. Examples of that are keywords.ini and the >> entire GUI skin files collection, and certainly some more parts of the >> viewer which I'm not yet too familiar with. >> > > >> I may be totally off with this, missing out a mention of the reasons for >> why the current structure is the way it is. Can someone help with a >> pointer if that is the case? >> > > How about: > > Rule of Representation: Fold knowledge into data, so program logic can > be stupid and robust. > http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263 > > At the same time: > > Rule of Generation: Avoid hand-hacking; write programs to write programs > when you can. > http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878742 > > So arguably *automatically generated* code is acceptable. But you need > to strictly disallow hand-hacking of generated code. Don't even put it > in the SCM, make the build system generate it for you. > > I'm afraid I didn't present it too well, maybe lacking some background to cite excellent sources such as this. But we're not at all on different sides here. That's why I was drawing the comparison with the Qt toolkit, which has these rules implemented well. (Only been given to understand that compiling all of it into a monolithic executable is not wanted for the SL viewer.) Ok, being told that the goal is to have loadable skin packs, I want to ask back: What's in a skin? To me that is colors, text and labels that are language dependent, style descriptions of widget decorations, and icons or other graphical elements. But not the entire structure with functional elements on whose presence hard coded parts of the program are relying. IMHO this is a starting point where refactoring would make sense and be fairly easy to do as well: Have the functionality part taken into the source on compile time by a preprocessor, and reduce the 'loadFromXML' function to add the parts that are really just style elements. The much desired function to enable/disable certain elements without having to recompile the viewer (s. Argent's earlier post in this thread) is provided by show/hide flags in the GUI XML. If 'preprocessor' sounds high-flying or complicated, it's really just a rewrite of the current load function in Python that hooks up in the custom build steps. We may even keep the XML files as they are and leave it to the preprocessor to sort out which is which. This would avoid creating a gigantic patch, and avoid undoing any work that has already been put into creating tools for editing the GUI. Hope I'm making sense, trying to think practical. > But I think the real issue here is: > > Rule of Repair: Repair what you can ? but when you must fail, fail > noisily and as soon as possible. > http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878538 > > The viewer has the "failing" part down, but fails at the graceful and > noisy part. It crashes and gives you no useful diagnostic output as to > what the problem is. > > YES. From q at lindenlab.com Fri Apr 18 20:40:43 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Fri Apr 18 20:40:48 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48093659.8010907@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> Message-ID: <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> On Apr 18, 2008, at 8:01 PM, Felix Duesenburg wrote: > Callum Lerwick wrote: >> On Fri, 2008-04-18 at 07:07 -0400, Felix Duesenburg wrote: >> >>> There is quite a heavy dependency of the viewer application on the >>> correctness of added resources. In other words, hard coded parts >>> of the program need outside resources to be correctly structured >>> or they would fail. I really mean structure, not just language >>> dependent snipplets of text, or colors or the like. Examples of >>> that are keywords.ini and the entire GUI skin files collection, >>> and certainly some more parts of the viewer which I'm not yet too >>> familiar with. >>> >> >> >>> I may be totally off with this, missing out a mention of the >>> reasons for why the current structure is the way it is. Can >>> someone help with a pointer if that is the case? >>> >> >> How about: >> >> Rule of Representation: Fold knowledge into data, so program logic >> can >> be stupid and robust. >> http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878263 >> >> At the same time: >> >> Rule of Generation: Avoid hand-hacking; write programs to write >> programs >> when you can. >> http://catb.org/~esr/writings/taoup/html/ch01s06.html#id2878742 >> >> So arguably *automatically generated* code is acceptable. But you >> need >> to strictly disallow hand-hacking of generated code. Don't even put >> it >> in the SCM, make the build system generate it for you. >> >> > > I'm afraid I didn't present it too well, maybe lacking some > background to cite excellent sources such as this. But we're not at > all on different sides here. That's why I was drawing the comparison > with the Qt toolkit, which has these rules implemented well. (Only > been given to understand that compiling all of it into a monolithic > executable is not wanted for the SL viewer.) > > Ok, being told that the goal is to have loadable skin packs, I want > to ask back: What's in a skin? To me that is colors, text and labels > that are language dependent, style descriptions of widget > decorations, and icons or other graphical elements. But not the > entire structure with functional elements on whose presence hard > coded parts of the program are relying. > > IMHO this is a starting point where refactoring would make sense and > be fairly easy to do as well: Have the functionality part taken into > the source on compile time by a preprocessor, and reduce the > 'loadFromXML' function to add the parts that are really just style > elements. The much desired function to enable/disable certain > elements without having to recompile the viewer (s. Argent's earlier > post in this thread) is provided by show/hide flags in the GUI XML. > > If 'preprocessor' sounds high-flying or complicated, it's really > just a rewrite of the current load function in Python that hooks up > in the custom build steps. We may even keep the XML files as they > are and leave it to the preprocessor to sort out which is which. > This would avoid creating a gigantic patch, and avoid undoing any > work that has already been put into creating tools for editing the > GUI. Hope I'm making sense, trying to think practical. I'm sorry, but I really think this is highly unlikely to ever happen. You're proposing the creation of an additional step to the build process, to take something out of data and put it into code. We're moving much more in the direction of moving things out of code and into data. I see that you're trying to draw a bright line between the model and view parts of the UI, and there's a certain argument for your position -- in stable code. But high quality UI development requires lots of iterations. The cycle time for edit/build/test is critical to controlling how many shots you get at making it good. In that scenario, the more you can do in data without a rebuild, the better off you are. To tie in the other discussion going on right now, we're fully aware that the viewer isn't as modular as anyone would like, and that there's too much coupling between the various pieces. Some of us are working very hard on taking some of that apart right now. I, for example, am one of three developers who have been working on refactoring the notifications and alerts systems, with the help of our UI team and some excellent feedback I got earlier from this list. We're also doing a lot of work toward making the viewer more and more data-driven. For example, the Notifications system is quite a bit more flexible now, because we're adding capabilities to the XML file we use for localization. I'm not being authoritarian about this, just trying to express the reality of our goals and that I think they're incompatible with what you're proposing. As far as I can tell, there's little chance that we'll move in favor of moving things into compiled code, especially if doing so also requires adding to build time and complexity. Q From darien_caldwell at comcast.net Fri Apr 18 20:58:54 2008 From: darien_caldwell at comcast.net (Darien Caldwell) Date: Fri Apr 18 20:58:58 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> Message-ID: <003f01c8a1d1$b0385de0$647ba8c0@a644000> Reading the Wiki entry, it sounds like a lot of good ideas. However, the talk of doing away with User Picks is worrisome. LL may not be aware, but many people use Picks like an extended area of their personal profile. The locations in the picks often are meaningless, it's the words and pictures which are of importance. I think this points to the fact that the amount of space people have to talk about themselves and what's important to them is very small in the profile. Certainly you could remove Picks, but offering more space for personal expression in return would be a good idea. I know some will say you can simply start a blog or some other web based personal page, and that's true, but not everyone is so inclined to do so. Just some thoughts. :) ----- Original Message ----- Subject: Re: [sldev] Linden Lab Navigations and Landmark Project > Hi everyone, > > Here's the pwiki page on the Landmarks and Navigation project: > https://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project > > Also, a correction: Benjamin Linden's weekly office hour is on Thursdays > at 3 PM Pacific, not at 2 PM, as my email yesterday stated. Amusingly, > Ben and I both made the mistake and didn't realize it until 2 PM. Our > apologies for our seemingly singed neurons and the confusion we caused. > > Stephany > > Aimee Walton wrote: >> On Apr 18, 2008, at 12:35, Argent Stonecutter wrote: >>> I have to periodically go through my inventory with the filter set to >>> landmarks and delete landmarks or put them in boxes to keep them from >>> cluttering up the map. >> >> Duplicate detection based on UUID would help too, but that's something >> not limited to landmarks. >> >> Aimee. From secret.argent at gmail.com Fri Apr 18 21:07:54 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 18 21:07:49 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48089300.9090302@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <84570B39-E9C2-4B2B-A05E-06AC8B77E84E@gmail.com> <48088A96.3080007@gmx.net> <63078284-F15C-4029-99ED-6FFD90020F54@gmail.com> <48089300.9090302@gmx.net> Message-ID: <620F84A8-A79C-4ACC-A3EF-7B4FA72D2893@gmail.com> On 2008-04-18, at 07:24, Felix Duesenburg wrote: > I remember now one more aspect that led me to raising this, which > is a security concern. Something could overwrite these files and do > things like swapping the 'yes' and 'no' labels on the payment > permission dialog. See the recent thread titled "Handling open > source translations". Pretty much anyone in a position to do do that *and* take advantage of it already has control of your computer. Security is like sex, once you're penetrated... From aimee at ama-zing.co.uk Fri Apr 18 23:00:41 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Apr 18 23:00:45 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <003f01c8a1d1$b0385de0$647ba8c0@a644000> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> Message-ID: <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> On Apr 19, 2008, at 04:58, Darien Caldwell wrote: > Reading the Wiki entry, it sounds like a lot of good ideas. > However, the talk of doing away with User Picks is worrisome. LL > may not be aware, but many people use Picks like an extended area > of their personal profile. The locations in the picks often are > meaningless, it's the words and pictures which are of importance. The suggestion of deprecating user picks on the wiki page is actually at odds with most of what was expressed at the meeting. General consensus seemed to be that they should become more flexible in recognition of the fact they are being widely used for non- geographical purposes. I would suggest that rather than just allowing a landmark on them they should be able to take a generalised attachment, be that a landmark, link to a friend, URL, notecard, or an object. That would allow store owners to distribute incentive freebies through the profile pick for their store for example, or give non-landowners a way to distribute freebies, Aimee. From lenglish5 at cox.net Fri Apr 18 23:36:22 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 18 23:36:25 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> Message-ID: <480992E6.2000403@cox.net> Kent Quirk (Q Linden) wrote: > > To tie in the other discussion going on right now, we're fully aware > that the viewer isn't as modular as anyone would like, and that > there's too much coupling between the various pieces. Some of us are > working very hard on taking some of that apart right now. I, for > example, am one of three developers who have been working on > refactoring the notifications and alerts systems, with the help of our > UI team and some excellent feedback I got earlier from this list. > This is encouraging and I apologize if I came off sounding, well, offensive. Lawson From seg at haxxed.com Sat Apr 19 02:05:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat Apr 19 02:05:53 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> Message-ID: <1208595944.22067.64.camel@localhost> On Sat, 2008-04-19 at 07:00 +0100, Aimee Walton wrote: > On Apr 19, 2008, at 04:58, Darien Caldwell wrote: > > > Reading the Wiki entry, it sounds like a lot of good ideas. > > However, the talk of doing away with User Picks is worrisome. LL > > may not be aware, but many people use Picks like an extended area > > of their personal profile. The locations in the picks often are > > meaningless, it's the words and pictures which are of importance. > > The suggestion of deprecating user picks on the wiki page is actually > at odds with most of what was expressed at the meeting. General > consensus seemed to be that they should become more flexible in > recognition of the fact they are being widely used for non- > geographical purposes. > > I would suggest that rather than just allowing a landmark on them > they should be able to take a generalised attachment, be that a > landmark, link to a friend, URL, notecard, or an object. That would > allow store owners to distribute incentive freebies through the > profile pick for their store for example, or give non-landowners a > way to distribute freebies, How about we just nuke profiles out of the client and SL protocol entirely and push them out onto the web? We seem to have an in-game browser these days... Then integrate it with Facebook and Google Apps and Mugshot and so on. Apparently the kids these days call this a "mashup"... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080419/efd5ee4e/attachment.pgp From kfa at gmx.net Sat Apr 19 03:05:50 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 19 03:05:58 2008 Subject: Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> Message-ID: <4809C3FE.6030700@gmx.net> Kent Quirk (Q Linden) wrote: > > You're proposing the creation of an additional step to the build > process, to take something out of data and put it into code. We're > moving much more in the direction of moving things out of code and > into data. I see that you're trying to draw a bright line between the > model and view parts of the UI, and there's a certain argument for > your position -- in stable code. But high quality UI development > requires lots of iterations. The cycle time for edit/build/test is > critical to controlling how many shots you get at making it good. In > that scenario, the more you can do in data without a rebuild, the > better off you are. > > To tie in the other discussion going on right now, we're fully aware > that the viewer isn't as modular as anyone would like, and that > there's too much coupling between the various pieces. Some of us are > working very hard on taking some of that apart right now. I, for > example, am one of three developers who have been working on > refactoring the notifications and alerts systems, with the help of our > UI team and some excellent feedback I got earlier from this list. > > We're also doing a lot of work toward making the viewer more and more > data-driven. For example, the Notifications system is quite a bit more > flexible now, because we're adding capabilities to the XML file we use > for localization. > > I'm not being authoritarian about this, just trying to express the > reality of our goals and that I think they're incompatible with what > you're proposing. As far as I can tell, there's little chance that > we'll move in favor of moving things into compiled code, especially if > doing so also requires adding to build time and complexity. > > Q > And these goals are a crucial thing to learn i.o. to reach any degree of coherence, thanks for taking the time to clarify. Looking at a mountain (workload) and trying to figure out where it makes sense to start digging and where there's bedrock under the surface. No point in being religious about anything. Still, maybe one more shot at this concrete step to "make it compatible", and at the broader strategy: The cycle time is really a strong argument. What I'm trying to find out is, are we compromising in favour of a more economic development process, or is a strict separation as taught in the MVC philosophy not seen as that important when talking about refactoring? If the former is the case, there is certainly headroom for improving on what was previously said. A compromise could be to switch on the custom build step only for shelling out a new release viewer, and to leave it out while GUI elements are being developed. I don't foresee a lot of problems/bugs that could occur only because of that step, because once established it runs automatic, same as with Bison for the script compiler. I find it hard to imagine that anyone would prefer to have that ditched as well for a data driven approach? Although this would enable the possibility to hook up any programming language with the script engine by finding a way to describe how it is to be translated into bytecode (current or mono). No need to recompile... hmmm, /scratching my head if someone would like to have this, or rather drill a hole into their kneecap than adding such complexity... The main point of this now is to shed light on the distinction between what is/should be flexible for the developer for reaching a better work economy, and what is/should be mutable/immutable to the end user or "light developer" (i.e. skinning, customizing the surface only). I don't think there's an argument that there has to be a certain core which the user is not to touch, and that strictly ought to be developed with the goal of stability. What exactly that core comprises is a subject of discussion and needs to be clearly defined. So I'm wondering if maybe a design paper already exists that is a bit more concrete than just saying "we're moving towards a more data-driven approach"? Call me donkey if I missed a wiki on that. Is anyone possibly thinking of a client/server architecture in the fashion of the X window system under Linux? By the way, when starting this I didn't really think of the GUI initially, and didn't mean to focus on it either. I took my first stab at the LSL parser and was dealing with keywords.ini there. If I had my way I'd shoot it and write the definitions into a header, because the actual collection of keywords and their function in LSL is immutable outside of development. (I'm contradicting myself with the loadable bytecode compiler mention above, but that would be a thing of the future if at all.) Customizable are the colours for the categories in syntax highlighting, and of course the tooltips that could be translated into other languages, so those should be going into XML somewhere. As it is, this flexibility does not exist anyway, and maybe there are similar situations in other parts of the application. Would that be seen as a small but worthwhile task in the bigger picture? Forgive me if I perceive the criticism of "adding complexity" as a little political in this context... every time a new big feature is introduced, it adds a lot more complexity than what we're talking about here :) Felix From dmahalko at gmail.com Sat Apr 19 03:53:49 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Apr 19 03:53:59 2008 Subject: [sldev] Physics precision, and negative values? Translation of center of precision? Message-ID: This is probably a really obscure question, so it's not something I'm going to ask Andrew during office hours.. :-) We have long been told that the physics calculations become more and more inaccurate as height increases. It would be nice to have a more in-depth discussion of why this is the case, for the SL Wiki. How exactly is physics positional data stored, server side, and how can it become more inaccurate in relation to height? I assume this has something to do with floating point values. But if 768.00 meters is where the problems begin then it sounds like the floating point values are accurate for only 5 decimal places, which seems unusually and almost ridiculously small. Even the lowly Apple II floating point BASIC was accurate to 9 places. What exactly is going on with this precision limit? Also, I note that negative positional values are not actually out of the question, since I have in the past been able to move objects to negative Z axis positions without crashing the simulator.. At what point on the negative-Z axis does the coordinate system start to get imprecise again? Does an object have to get below -768 for positional errors to appear, or does the imprecision begin immediately below 0 meters Z? What I'm trying to determine here is if the physics engine absolute center of precision is also aligned at 0,0,0 with the sim, or if the location is translated to up in the sky somewhere, to improve world physics calculation. If for example the center of accurate positioning is from +384.00 m Z to -384.00m Z to the physics engine, then by translating the sim to have the actual world center at +384.0 Z relative to the simulator, then the entire range of precision of +/- 384m becomes available as 0 to +768m for users of the sim. But if the high-precision range is from -768m to +768m Z and the physics engine origin is the same as the simulator origin, that would mean the precision below 0m Z is unusuable and wasted. >From the client side, there's no way to know if prim positions aligned to the sim-origin are being translated by the simulator to conform to some other world-origin being used by the physics engine. I suppose if the simulator ever does go open-source, such details will become known as a matter of course, but for now this is hidden away and there's no way to know how the coordinate system is directly calculated and used by the physics engine. - Scalar Tardis / Dale Mahalko From aimee at ama-zing.co.uk Sat Apr 19 04:18:05 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Apr 19 04:18:11 2008 Subject: [sldev] Physics precision, and negative values? Translation of center of precision? In-Reply-To: References: Message-ID: On Apr 19, 2008, at 11:53, Dale Mahalko wrote: > But if 768.00 meters is where the problems begin then it sounds like > the floating point values are accurate for only 5 decimal places, > which seems unusually and almost ridiculously small. Even the lowly > Apple II floating point BASIC was accurate to 9 places. What exactly > is going on with this precision limit? You may find this patch, http://aimee.adsl24.co.uk/sl/slviewer-v11901- Precision.patch useful. I use it routinely to expose the rounding errors so I know exactly where what I build is being put, rather than just where it says it is :) and adjust things more finely without resorting to nudge scripts. Aimee. From blindwanderer at gmail.com Sat Apr 19 04:58:09 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sat Apr 19 04:58:13 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: <48091CA5.6030400@gmx.net> References: <4808A6CD.2020309@gmx.net> <4808FB90.50407@gmail.com> <48091CA5.6030400@gmx.net> Message-ID: <89ca6da00804190458n787fd20eme72a60f8a941cd4a@mail.gmail.com> They gets grumpy when you assign patches to people. I've only ever assigned one patch to a linden and that was SVC-1241. Don Linden is a scripting guru so when I came across some badly written, buggy dead code in LSL VM, I thought he would be the guy to assign it to. I was then told that doing so delayed it getting imported ~_~ . SVC-1241 hasn't been fixed and the offending code has not been fixed or removed (I submitted two patches, one to remove it the other to fix it). I don't know if all my patches actually work, some of the more involved VM patches are hard to test without getting really involved and mostly I only go after low hanging fruit (like VWR-4111 ). Mostly I stare at the code until something jumps out at me as wrong. I don't submit a large number of patches and I don't think they are all of the greatest of quality; I'm sure there is someone whose patches are better then mine and more prolific that you can use as an example. I've just read the Nic's before mentioned blog post and I too have been feeling uneasy, though not to that extent. With Philip stepping down and Cory having left it worries me greatly (there was a program on PBS about 10 years ago "Triumph of the Nerds" about Silicon Valley and some venture capitalists were saying that once the business grows you sack the founders, i think there were talking about HP). It suggests to me that while the monkeys are at their typewriters the investors are quietly running the show from the back room; but I'm not cynical enough to believe that. What ever is going on the name of the game is changing or we are just beginning to see what the game really is. Frankly I don't like whats going on but there aren't enough facts for me to draw a definitive conclusion. There is a slippery slope to madness and paranoia here, the easiest thing you can do, which is what Nic did, was to quit while your ahead. But still it makes me uneasy. There is much I'm thinking but not saying. PR wise, LL is in a bad spot, mostly of their own design. People are claiming LL is being negligent in it's community minded programs and suggesting they were a bluff to pacify the masses. No matter how you look at those words are intended to hurt; they are hard to refute. But I don't care for the politics so much anymore, I've paid my dues, I've got the t-shirt, I've been in the trenches and until my prize expires, I have retired to my beach hut. The things I still do are me just going through the motions and keeping my hand in the game. On Fri, Apr 18, 2008 at 6:11 PM, Carsten Juttner wrote: > Jason Giglio wrote: > > > I don't know. It may help, but it doesn't address the root cause of the > > problem: That Linden Lab views themselves as a separate entity from the > > community; that the community development process is completely outside > > the actual development of the client. > > > > True and that's actually my problem currently, too. I don't care that much > about my patches not getting in the viewer but more about the lack of > communication between Linden developers and OS developers. I see sldev and > JIRA as a communication platform. > > But if you e.g. submit a source code bug on JIRA it can happen that the > comment is read by a non-developer Linden first who simply marks the bug as > "needs more info - resolved" instead of assigning it to the appropriate > developer(s). I can understand that developers are unwillling to take a look > at all the user provided JIRA entries but at least "source code" entries > should be treated differently. > > Sometimes, there's not a reply at all. All of this is very frustrating. > > The lack or fear of communication due to what seems to be some kind of > "culture clash" problem (open source vs. commercial development) is one of > the things that need to be tackled or a lot of good developers will simply > turn away because they feel their efforts going nowhere. > > That is not to say that there this is valid for all Lindens, quite > contrary, some go out of their way to help the OS community, but they > currently seem to be a noble exception. > > Regards, > Carsten > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From aimee at ama-zing.co.uk Sat Apr 19 05:08:27 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Apr 19 05:08:32 2008 Subject: [sldev] Physics precision, and negative values? Translation of center of precision? In-Reply-To: References: Message-ID: On Apr 19, 2008, at 12:18, Aimee Walton wrote: > You may find this patch, http://aimee.adsl24.co.uk/sl/slviewer- > v11901-Precision.patch useful. > > I use it routinely to expose the rounding errors so I know exactly > where what I build is being put, rather than just where it says it > is :) and adjust things more finely without resorting to nudge > scripts. Actually you'll probably want to increase it to more DP to investigate, I forgot I limited it to 5DP in the end to squeeze it in the UI. From matthew.dowd at hotmail.co.uk Sat Apr 19 05:37:15 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Apr 19 05:37:16 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: <48091CA5.6030400@gmx.net> References: <4808A6CD.2020309@gmx.net> <4808FB90.50407@gmail.com> <48091CA5.6030400@gmx.net> Message-ID: > The lack or fear of communication due to what seems to be some kind of > "culture clash" problem (open source vs. commercial development) is one > of the things that need to be tackled or a lot of good developers will > simply turn away because they feel their efforts going nowhere. At the beginning, I think the OS-ers expected this (moving from a closed source shop to an open source shop is a difficult cultural change), and LL, I suspect, underestimated the work needed to properly OS the source code, and build an OS community (on the basis that thinking you just tidy and publish the code under an OS license is a common mistake), and so people were patient and sympathetic to LL. However, that patience and sympathy is now beginning to wear thin - with some high profile OS committers moving on (some I suspect to work on OpenSim or LibSL projects or even non-SL based open source projects such as croquet and wonderland). There also seems to be a disconnect between what the SL customers are asking for in terms of problems and features and what LL implement - whilst there are things in jira with 100s of votes ignored. 1.20, for example, introduces a number of changes which don't seem to be in any of the public forums for feature discussions (e.g. jira, blog, LL forums) such as double click run, removing friends from the map, etc. (which have either been rolled back due to user demand, or have large number of votes in jira to roll back), but these are not isolated examples. The result of the latter is that customers are being pushed to third party viewers which seem better connected to user demand that LL, and the former is pushing those developers away from committing back to LL's source base. Rob's e-mail says that LL does not want to go the same way as Netscape - but I predict that if LL does not change direction soon, it will do precisely that. On its current course, I predict that within 5 years, if SL still exists in some form, it will be OpenSim grids and LibSL based viewers that will have the lead in both popularity and (community driven) innovation, and LL will be fondly remembered as an early pioneer only... Matthew (hoping that 1.20 RC2 might provide a source code drop which actually compiles *AND* runs under Windows....) _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080419/85425c74/attachment.htm From matthew.dowd at hotmail.co.uk Sat Apr 19 05:49:54 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Apr 19 05:49:54 2008 Subject: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48090686.9030706@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <1208550528.22067.22.camel@localhost> <48090686.9030706@lindenlab.com> Message-ID: > >> How does this compare to other open source and public projects? My > >> suspicion is that almost every active open source project experiences > >> net positive growth in number of open bugs. I'd like to make sure> >> we're > >> not being measured against an unreasonably high standard.> >> > >> > Second Life isn't just an open source project, it is a commercial open> > source project with *paying* customers, wherein the vast majority of> > development is still done by paid employees. The "open source" part is> > incidental, really.> >> > I don't think it's fair to measure LL against an unreasonably low> > standard like volunteer open source projects...> > > > What, exactly, do you want to compare us to? What we are discussing here are not open source projects per se, but projects which use a public bug/feature trackiing system. Open source projects do not have an exclusive right to use public bug/issue trackers, and it might make more sense to compare SL to closed/commercial source projects using public trackers given that the development effort on SL is still primarily driven by paid employees. As for an example, well jira itself (as well as the other atlassian tools) is a very good example of a closed/commercial source project using a public bug/issue tracker: http://jira.atlassian.com/browse/JRA?report=com.atlassian.jira.plugin.system.project:popularissues-panel Matthew _________________________________________________________________ Amazing prizes every hour with Live Search Big Snap http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080419/19ab82c5/attachment.htm From annagulaev at gmail.com Sat Apr 19 06:02:53 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Sat Apr 19 06:02:55 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <1208595944.22067.64.camel@localhost> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> Message-ID: Callum Lerwick wrote: > > How about we just nuke profiles out of the client and SL protocol > entirely and push them out onto the web? > > Then integrate it with Facebook and Google Apps and Mugshot and so on. > Apparently the kids these days call this a "mashup"... I call it a tacky mess of ugly crap. Think about what a profile is. When I get a profile I know what I'll find there. One brief statement about the person's SL life, with a picture. One brief statement about the person's FL, with a picture, if he's so inclined to share. One page of favorite items that tells me about the person's tastes and potentially offers links to interesting things. Restricted? Yes. But it's also concise and there's a limit to how tacky it can be made. There's also a web tab, so the person can set up a facebook page and from there they can link all the other tacky crap they want. Wisely (for security and privacy) the viewer asks my permission to view this external content. If profiles go the way of other things and become web-based, at least keep them under viewer-generated control so they remain consistent and concise, and keep them on LL-owned property. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080419/17292f22/attachment-0001.htm From secret.argent at gmail.com Sat Apr 19 06:18:54 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 19 06:18:49 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <1208595944.22067.64.camel@localhost> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> Message-ID: <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> On 2008-04-19, at 04:05, Callum Lerwick wrote: > How about we just nuke profiles out of the client and SL protocol > entirely and push them out onto the web? Because then nobody can view profiles without potentially revealing to the person they're viewing that they have viewed the profile and where on the net they were viewing from. People are already having problems when they set the "web" tab of a profile to load by default, The best thing to come out of the recent changes in streaming media is that you can have streaming media enabled in the client without automatically connecting to the media source. That eliminates the streaming media "web bugs" that people were using to automatically track visitors by IP address. None of these schemes should even be considered until LL is prepared to host the kind of proxy infrastructure that makes stalking people by IP address impossible. From kfa at gmx.net Sat Apr 19 06:23:03 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 19 06:23:10 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> Message-ID: <4809F237.4090702@gmx.net> Anna Gulaev wrote: > *Callum Lerwick* wrote: > > How about we just nuke profiles out of the client and SL protocol > entirely and push them out onto the web? > > > > Then integrate it with Facebook and Google Apps and Mugshot and so on. > Apparently the kids these days call this a "mashup"... > > > I call it a tacky mess of ugly crap. > > Think about what a profile is. When I get a profile I know what I'll > find there. One brief statement about the person's SL life, with a > picture. One brief statement about the person's FL, with a picture, if > he's so inclined to share. One page of favorite items that tells me > about the person's tastes and potentially offers links to interesting > things. > > Restricted? Yes. But it's also concise and there's a limit to how > tacky it can be made. > > There's also a web tab, so the person can set up a facebook page and > from there they can link all the other tacky crap they want. Wisely > (for security and privacy) the viewer asks my permission to view this > external content. > > If profiles go the way of other things and become web-based, at least > keep them under viewer-generated control so they remain consistent and > concise, and keep them on LL-owned property. > The idea has some appeal initially, but I admit that lasted only as long as looking only at the technical side. Personally, I don't like "mashup" and I'm definitely out of that generation. Adding to that, I'd like to get a choice about where my profile appears and where not. Publishing something on one platform (SL) does not automatically include my consent to have it republished on another platform (www). I'm already not too happy with SL search results being available on the web, although I probably nodded it through with the TOS just to stay in the game. From secret.argent at gmail.com Sat Apr 19 06:30:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 19 06:30:54 2008 Subject: Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <4809C3FE.6030700@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> Message-ID: <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> On 2008-04-19, at 05:05, Felix Duesenburg wrote: > A compromise could be to switch on the custom build step only for > shelling out a new release viewer, and to leave it out while GUI > elements are being developed. I don't foresee a lot of problems/ > bugs that could occur only because of that step, because once > established it runs automatic, same as with Bison for the script > compiler. I find it hard to imagine that anyone would prefer to > have that ditched as well for a data driven approach? I would. I guess you didn't catch that when I say I routinely provide changes to the XML files for people to use, that's not limited to "first look" or "production", these are needed in all viewer. These have nothing to do with whether the viewer is in production or not, or whether one is a developer or not, they have to do with the fact that people have different preferences as to how they want the user interface of the browser to operate, and these files give them the ability to satisfy many of them without being a developer. > Although this would enable the possibility to hook up any > programming language with the script engine by finding a way to > describe how it is to be translated into bytecode (current or mono). This part of your comment I don't understand. What does the scripting language in-world have to do with the viewer user interface? > The main point of this now is to shed light on the distinction > between what is/should be flexible for the developer for reaching a > better work economy, and what is/should be mutable/immutable to the > end user or "light developer" (i.e. skinning, customizing the > surface only). Ideally the entire user interface should be implemented completely in a scripting language (Javascript, Lua, Tcl, Python, etc) with only the actual "in-world" part implemented in a compiled language at all. This should improve the reliability of the viewer, because it would reduce the amount of code that is subject to buffer overflows, null pointers, wild pointers, memory management problems, and so on, because there are many many more eyes looking for these problems in the scripting language runtime. > I don't think there's an argument that there has to be a certain > core which the user is not to touch, and that strictly ought to be > developed with the goal of stability. Yes, there is an argument there. The user should have access to everything in the viewer user interface where it does not impact performance. From carjay at gmx.net Sat Apr 19 07:14:40 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Apr 19 07:14:39 2008 Subject: [sldev] sljirastats.com Linden Metrics Report & Public Perception In-Reply-To: <89ca6da00804190458n787fd20eme72a60f8a941cd4a@mail.gmail.com> References: <4808A6CD.2020309@gmx.net> <4808FB90.50407@gmail.com> <48091CA5.6030400@gmx.net> <89ca6da00804190458n787fd20eme72a60f8a941cd4a@mail.gmail.com> Message-ID: <4809FE50.7010203@gmx.net> Strife Onizuka wrote: > They gets grumpy when you assign patches to people. I've only ever > assigned one patch to a linden and that was SVC-1241. Don Linden is a > scripting guru so when I came across some badly written, buggy dead > code in LSL VM, I thought he would be the guy to assign it to. I was > then told that doing so delayed it getting imported ~_~ . SVC-1241 > hasn't been fixed and the offending code has not been fixed or removed > (I submitted two patches, one to remove it the other to fix it). > Looking at the bug entry this is exactly what I am referring to. A clear description of a specific problem with the source code which is left unanswered by the developers. Worse, from the comment that the person at Linden left it appears that you broke some rule and are now punished for it. Well, in my opinion it makes no sense to be able to assign bugs to developers at Linden if that is not wanted. Personally, I am usually very hesitant trying to write a public patch for a subsystem which I do not fully understand since it invites bugs so I usually write a small bandaid fix for my own purposes to verify the issue then try to discuss the problem. Unfortunately that approach seems not to work so I guess in a few months my quilt folder will be full of small patches which make the viewer more stable on my system but never make it into the official viewer since the developers may not even have heard about it. Thinking about your worries I guess they are founded but I also doubt it makes sense to discuss wild guesses and speculations about internal LL politics. I simply enjoy looking at all the screws in the viewer and playing with them to learn more about the way a virtual environment works. So reporting and discussing problems that I find along the way seems only fair. Regards, Carsten From kfa at gmx.net Sat Apr 19 09:14:29 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 19 09:14:36 2008 Subject: Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> Message-ID: <480A1A65.4010509@gmx.net> Argent Stonecutter wrote: > On 2008-04-19, at 05:05, Felix Duesenburg wrote: >> A compromise could be to switch on the custom build step only for >> shelling out a new release viewer, and to leave it out while GUI >> elements are being developed. I don't foresee a lot of problems/bugs >> that could occur only because of that step, because once established >> it runs automatic, same as with Bison for the script compiler. I find >> it hard to imagine that anyone would prefer to have that ditched as >> well for a data driven approach? > > I would. below * > > I guess you didn't catch that when I say I routinely provide changes > to the XML files for people to use, that's not limited to "first look" > or "production", these are needed in all viewer. These have nothing to > do with whether the viewer is in production or not, or whether one is > a developer or not, they have to do with the fact that people have > different preferences as to how they want the user interface of the > browser to operate, and these files give them the ability to satisfy > many of them without being a developer. Think I did, and replied that it would still be possible with an overlay. Only that you could as well live without if you had a monolithic viewer with built-in defaults. Anyway, I can see why there is a lot of opposition to what I thought, and won't trample on everybody's nerves by keeping to ride on it. Throwing my 2 cents and learning where the flow goes was the purpose. > >> Although this would enable the possibility to hook up any programming >> language with the script engine by finding a way to describe how it >> is to be translated into bytecode (current or mono). > > This part of your comment I don't understand. What does the scripting > language in-world have to do with the viewer user interface? * - Because the script compiler is part of the viewer. This was my "I would", or rather "would I?". Sounded like a nutty idea or science fiction at first, but it would consequently follow the path of moving intelligence out of code and into data. If you had something that takes a description of the scripting language of your choice and translates it into bytecode, like a bison input file or a more modern XML version of that, then this would be a loadable component as well. The complexity of such a thing may be toenail-curling though. > >> The main point of this now is to shed light on the distinction >> between what is/should be flexible for the developer for reaching a >> better work economy, and what is/should be mutable/immutable to the >> end user or "light developer" (i.e. skinning, customizing the surface >> only). > > Ideally the entire user interface should be implemented completely in > a scripting language (Javascript, Lua, Tcl, Python, etc) with only the > actual "in-world" part implemented in a compiled language at all. This > should improve the reliability of the viewer, because it would reduce > the amount of code that is subject to buffer overflows, null pointers, > wild pointers, memory management problems, and so on, because there > are many many more eyes looking for these problems in the scripting > language runtime. Yes that would be awesome. Actually, if the mention of X finds any friends, then this would mean that anything goes. We wouldn't even have to dictate which language to use for the UI. Apart from the selection you mentioned, XUL or Java anyone? Or a compiled app again based on Qt or wxWidgets or JUCE? Everyone as they like. > > >> I don't think there's an argument that there has to be a certain core >> which the user is not to touch, and that strictly ought to be >> developed with the goal of stability. > > Yes, there is an argument there. > > The user should have access to everything in the viewer user interface > where it does not impact performance. > Well at least between you and me, nope, no argument at all. As you say "where it does not impact performance", that's where to draw the line between the core and the rest. What exactly that comprises though, at least so it seems to me, is not exactly finalized yet. Without such a clear layout it's difficult to know what to do about refactoring. Others have expressed it before that they wouldn't even know where to start. From robla at lindenlab.com Sat Apr 19 09:34:26 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Apr 19 09:34:40 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080410203552.22e899b0.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> Message-ID: <480A1F12.5060004@lindenlab.com> On 4/10/08 11:35 AM, Henri Beauchamp wrote: > On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > >> Henri Beauchamp wrote: >> >>> I already gave up submitting bug reports to the JIRA as this proved >>> to be a total loss of time and energy. >>> >>> >> I vote that some people are not allowed posting there anyway without a >> patch attached. Especially those that claim they're so good that by the >> time they spent ranting they could have squashed a few bugs. How come we >> have any open issues at all then. >> > > Be happy: http://sldev.free.fr/ > > I do not only criticize, I also contribute. All my patches were also > submitted to the JIRA.... with little to no result. > ....but without a contribution agreement, so we can't accept the changes :-( Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080419/6d434daa/signature.pgp From wfz at canopusresearch.com Sat Apr 19 13:08:21 2008 From: wfz at canopusresearch.com (William F. Zachmann) Date: Sat Apr 19 13:08:38 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project Message-ID: <6C0D06E089CDE94CA0AD3C80C2497F0C17794D@EXVBE012-5.exch012.intermedia.net> I'd meant to send my original reply to the list. I am trying to correct this by forwarding my latest reply to Callum to the list. I think this is an important issue not simply in terms of the specific point here, but more broadly in that there does not seem to me to be sufficient awareness and concern among developers working on the software of the perspective of ordinary residents in Second Life (and many more who do not ever become active residents because they find it too difficult to learn their way around). My concern is that technically proficient programmers do not typically find it very easy to put themselves in the shoes of a non-technical user (SL resident) or to appreciate how difficult it is for ordinary people to learn their way around SL. While replacing the current Picks structure with external web site links may seem like a good idea to a programmer, it is an absolutely dreadful idea from the perspective of an ordinary, non-technical, SL resident. All the best, Arifi/Will Arifi Saeed, Research Director, SL Canopus Research Inc. Arifi.saeed@canopusresearch.com http://arifisaeed.wordpress.com William F. Zachmann, President, Canopus Research Inc. Columnist: Redmond Developer News wfz@canopusresearch.com http://www.canopusresearch.com http://reddevnews.com/columns/columnist.aspx?columnistsid=47 -----Original Message----- From: William F. Zachmann Sent: Saturday, April 19, 2008 3:49 PM To: 'Callum Lerwick' Subject: RE: [sldev] Linden Lab Navigations and Landmark Project Callum, I don't agree. Aside from the likely performance hit going out to another web site, the bigger issue I see with this is that it requires a resident to have a web site somewhere, rather than being able to just create a Pick simply in-world as they can now. Again, that's no big deal for technically proficient programmer types. But it is quite daunting for many ordinary residents. SL is already a very difficult environment for normal people. That's why the retention rate is pathetically low (VERY low digits according to Mitch Kapor - only 1-2%). The change you advocate would make it even more difficult for non-technical residents. For Second Life to grow and to achieve its potential it needs to be simpler, not more complex or requiring even more technical skills. All the best, will William F. Zachmann President, Canopus Research Inc. Contributing Editor, Redmond Developer News RRwfz@canopusresearch.com +1-781-934-9800 (office) +1-617-851-0773 (mobile) Skype: william.f.zachmann Also see: Facebook Profile -----Original Message----- From: Callum Lerwick [mailto:seg@haxxed.com] Sent: Saturday, April 19, 2008 2:22 PM To: William F. Zachmann Subject: RE: [sldev] Linden Lab Navigations and Landmark Project On Sat, 2008-04-19 at 04:36 -0700, William F. Zachmann wrote: > One of the best things about the in-world experience for a user is the > ability to find new and interesting people/places/etc. by looking at > the Picks in someone's profile whom one casually encounters (or > perhaps merely sees in a crowd). The ease with which a resident can > do that would be totally lost if it required going out to the web. > Same goes for profiles generally. Nuking profiles might appeal to > programmers, but it is a totally dreadful idea as far as any > reasonably social non-geek-hiding-out-behind-a-computer SL resident > goes! No you're missing the point. No functionality would be lost. You would still click on a person and bring up their profile. It would just happen using the in-game browser or perhaps an external one, whatever the user prefers. User picks would remain, using some protocol such as slurls to link back in to SL and keep everything seamlessly integrated. The idea is to not limit ourselves to a single implementation. Make it a web page, and you can easily change, tweak, add and remove features, with NO viewer changes needed. This is a Good Thing. From gigstaggart at gmail.com Sat Apr 19 13:16:39 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Apr 19 13:16:43 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> Message-ID: <480A5327.6040308@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > None of these schemes should even be considered until LL is prepared > to host the kind of proxy infrastructure that makes stalking people > by IP address impossible. Really getting sick of this bullshit. The world isn't going to stop because you have this false belief that an IP address is private information. - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIClMnvPhJdUgWbXsRAh4qAJ45/Un1A+s2LFhpXNUT5LRhgIRZBwCgnBdQ o2CoIoqZ1P7DmGLNr1EW27o= =DGgy -----END PGP SIGNATURE----- From secret.argent at gmail.com Sat Apr 19 14:45:55 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 19 14:45:52 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480A5327.6040308@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: On 2008-04-19, at 15:16, Jason Giglio wrote: > Really getting sick of this bullshit. The world isn't going to stop > because you have this false belief that an IP address is private > information. I'm getting tired of explaining this, too, but I'll give it another try. Lets' start with the Internet. On the Internet, when you visit a website, that website gets your IP address. You visit another website. That site gets your IP address. So website A knows that "Joe user" is at IP address A, and website B knows that "Fred smith" is at IP address A. But this doesn't tell website B that "Joe user" is "Fred smith", because Website B doesn't see that. At one time it was possible for Website b to use tricks with cookies to get information that Website A had put on the user's computer and figure out that "Joe user" is "Fred smith". This kind of thing is frowned upon, and browsers have over the years been tightened up to try and reduce the opportunities for this kind of information leakage. There are, however, still tricks that website B can use. For example, he could set up Website C and have Website C take out an ad on Website A, and use the referrer for the image to get information about the IP addresses that visit Website A. This practice of using "web bugs" to track people across websites is controversial. Many people don't like it. There are programs you can get to try and block it. When people come up with new kinds of web bugs, they show up on security mailing lists, because being able to track people from website to website is something that is considered a bad thing. Website hosting companies make an effort so that people who visit myfreeserver/cutepuppies don't reveal to the owner of cutepuppies that they also visit mysfreeserver/weirdsexkink. Where they don't, that also shows up in security lists. It's mostly a minor problem on the internet as a whole because there's no common shared "global cookie" that everyone can use to track you. Within Second Life, your account name serves as that kind of global cookie. Making the IP address available as well provides what is basically a "universal web bug" that, if it existed in the 2d Internet, would be big news. If Linden Labs wants to make SL a "3d Internet", they would be poorly advised to make a "universal web bug" a standard part of the system. From tateru.nino at gmail.com Sat Apr 19 14:43:23 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Apr 19 14:48:26 2008 Subject: Refactoring and development economy - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <480A1A65.4010509@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> Message-ID: <480A677B.8080500@weblogsinc.com> Felix Duesenburg wrote: > Argent Stonecutter wrote: >> On 2008-04-19, at 05:05, Felix Duesenburg wrote: >> > >> >>> Although this would enable the possibility to hook up any >>> programming language with the script engine by finding a way to >>> describe how it is to be translated into bytecode (current or mono). >> >> This part of your comment I don't understand. What does the scripting >> language in-world have to do with the viewer user interface? > * - Because the script compiler is part of the viewer. This was my "I > would", or rather "would I?". Sounded like a nutty idea or science > fiction at first, but it would consequently follow the path of moving > intelligence out of code and into data. If you had something that > takes a description of the scripting language of your choice and > translates it into bytecode, like a bison input file or a more modern > XML version of that, then this would be a loadable component as well. > The complexity of such a thing may be toenail-curling though. > The script compiler isn't really staying. There's the old LSL compiler which might stay in the viewer (or move to the sim, not sure about that yet) and the mono compiler which definitely isn't going into the viewer last we heard. -- Tateru Nino http://www.massively.com/ From gigstaggart at gmail.com Sat Apr 19 17:55:30 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Apr 19 17:55:34 2008 Subject: [sldev] IP Address "Privacy". (Was: "Linden Lab Navigations and Landmark Project") In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: <480A9482.9010004@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > I'm getting tired of explaining this, too, but I'll give it another try. You failed. > Within Second Life, your account name serves as that kind of global > cookie. Making the IP address available as well provides what is > basically a "universal web bug" that, if it existed in the 2d > Internet, would be big news. If someone visits my profile, I have no idea what their SL username is, unless I say "Hey, Argent go visit my profile" and then you do. Which is EXACTLY THE SAME as me saying "Hey, Argent go visit my web site". There's absolutely no difference. You make it sound like the SL user name is going to be transmitted with each request or something, which is not what anyone is proposing. - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFICpSCvPhJdUgWbXsRAud6AJ0bP9ERu0dm8NXTM+QK6ocAX1w/hwCgoK7I D9C28gFTxNU0I3YeflPk0As= =SUNw -----END PGP SIGNATURE----- From secret.argent at gmail.com Sat Apr 19 21:42:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Apr 19 21:42:57 2008 Subject: [sldev] IP Address "Privacy". (Was: "Linden Lab Navigations and Landmark Project") In-Reply-To: <480A9482.9010004@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480A9482.9010004@gmail.com> Message-ID: First, Jason, I thought you were talking about the comment that I made about streaming media, that you quoted in your reply. Second... On 2008-04-19, at 19:55, Jason Giglio wrote: > If someone visits my profile, I have no idea what their SL username > is, > unless I say "Hey, Argent go visit my profile" and then you do. Which > is EXACTLY THE SAME as me saying "Hey, Argent go visit my web site". Which I don't normally do, unless I know that person, and which I have on occasion recommended people not do routinely. Viewing a profile doesn't seem like an obvious exposure, and yet there already is one there if you automatically load the web tab... even if you don't visit the web tab. There is a slippery slope here, and we've gone pretty far down the slope already... far enough that people are already getting caught out. But for the moment you CAN still avoid having the SL client visit random websites except by explicit request through an operation that is clearly "visiting a web site". From kfa at gmx.net Sat Apr 19 22:58:49 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 19 22:58:56 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480A677B.8080500@weblogsinc.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> Message-ID: <480ADB99.6010506@gmx.net> Tateru Nino wrote: > > > The script compiler isn't really staying. There's the old LSL compiler > which might stay in the viewer (or move to the sim, not sure about > that yet) and the mono compiler which definitely isn't going into the > viewer last we heard. > I keep hearing that, too, but so far it seems all rumours and nothing conclusive. Can you cite sources? It's a difficult keyword to search for, too many results. (To everybody: With things like that, always, ALWAYS make proper citations with sources, please.) Because if that was so, I'd immediately stop all work with the script compiler that I'm currently doing. But I've been in contact with Lindens about a sandbox where to test my stuff should things go wrong, and noone tried to discourage me. There are various JIRAs with feature requests for LSL, but no Linden is answering there saying that it's all going to be futile. I know that the current script compiler's days are numbered, but features can be ported. If it was to be taken away completely though, that would hurt. It would be good if we could have a statement from the horse's mouth, saying it's either this way or that way to stop these rumours. Or a pointer if we missed it. At the moment it feels rather uneasy indeed. Thanks, Felix From seg at haxxed.com Sun Apr 20 00:19:37 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun Apr 20 00:19:47 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <6C0D06E089CDE94CA0AD3C80C2497F0C17794D@EXVBE012-5.exch012.intermedia.net> References: <6C0D06E089CDE94CA0AD3C80C2497F0C17794D@EXVBE012-5.exch012.intermedia.net> Message-ID: <1208675977.11579.15.camel@localhost> On Sat, 2008-04-19 at 13:08 -0700, William F. Zachmann wrote: > I think this is an important issue not simply in terms of the specific > point here, but more broadly in that there does not seem to me to be > sufficient awareness and concern among developers working on the > software of the perspective of ordinary residents in Second Life (and > many more who do not ever become active residents because they find it > too difficult to learn their way around). My concern is that > technically proficient programmers do not typically find it very easy > to put themselves in the shoes of a non-technical user (SL resident) > or to appreciate how difficult it is for ordinary people to learn > their way around SL. And non-technical users have trouble understanding what engineers are talking about on (what I thought was) a technical list. I really have better things to do than hand-hold everyone through every offhand idea I toss out to the world. No, I'm not proposing users hand-write profile pages in vi on their own server. I'm talking about moving the *backend implementation* to standard, proven, flexible, adaptable and interoperable web technology. This would all still happen within the SL viewer on top of Linden Lab's infrastructure. Assuming LL is at all interested in this idea. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080420/c4f2bf5f/attachment.pgp From lenglish5 at cox.net Sun Apr 20 00:54:58 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Apr 20 00:55:00 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480ADB99.6010506@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> Message-ID: <480AF6D2.9050404@cox.net> Felix Duesenburg wrote: > Tateru Nino wrote: >> >> >> The script compiler isn't really staying. There's the old LSL >> compiler which might stay in the viewer (or move to the sim, not sure >> about that yet) and the mono compiler which definitely isn't going >> into the viewer last we heard. >> > > I keep hearing that, too, but so far it seems all rumours and nothing > conclusive. Can you cite sources? It's a difficult keyword to search > for, too many results. (To everybody: With things like that, always, > ALWAYS make proper citations with sources, please.) > > Because if that was so, I'd immediately stop all work with the script > compiler that I'm currently doing. But I've been in contact with > Lindens about a sandbox where to test my stuff should things go wrong, > and noone tried to discourage me. There are various JIRAs with feature > requests for LSL, but no Linden is answering there saying that it's > all going to be futile. I know that the current script compiler's days > are numbered, but features can be ported. If it was to be taken away > completely though, that would hurt. > > It would be good if we could have a statement from the horse's mouth, > saying it's either this way or that way to stop these rumours. Or a > pointer if we missed it. At the moment it feels rather uneasy indeed. > A better thing to work on then a compiler is a client-side syntax checker that doesnt' require one to go to the server. That exists for teh pre-mono version of LSL but as far as I now, you gotta wait for the server to compile before you know if there are any syntax errors in your mono-compiled script. If mono-based LSL [3] ever comes about this will be a useful feature. Lawson From matthew.dowd at hotmail.co.uk Sun Apr 20 03:59:10 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Apr 20 03:59:24 2008 Subject: [sldev] Skin changing patch In-Reply-To: <480AF6D2.9050404@cox.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480AF6D2.9050404@cox.net> Message-ID: Well, on finally getting a version of 1.20 to compile (under Windows), my skin changing patch seems to work! I've posted the files on the jira issue at http://jira.secondlife.com/browse/VWR-5059 Matthew _________________________________________________________________ The next generation of Windows Live is here http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080420/7e8b9b70/attachment.htm From wfz at canopusresearch.com Sun Apr 20 05:02:13 2008 From: wfz at canopusresearch.com (William F. Zachmann) Date: Sun Apr 20 05:02:20 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <1208675977.11579.15.camel@localhost> References: <6C0D06E089CDE94CA0AD3C80C2497F0C17794D@EXVBE012-5.exch012.intermedia.net> <1208675977.11579.15.camel@localhost> Message-ID: <6C0D06E089CDE94CA0AD3C80C2497F0C17794E@EXVBE012-5.exch012.intermedia.net> No need to be insulting, Callum. Nor is there reason to assume that because I advocate the case for technically challenged SL residents that I am one. I have been programming for a very long time -- likely since well before you were born -- in a wide variety of programming and scripting languages and on an equally wide variety of software platforms. As to the point at hand, I do understand what you are proposing, at least to the degree of specificity you have offered so far. My concern is that it is far from obvious how to implement it without making it MORE rather than LESS complex for non-technical residents to do what at least quite a few of them have so far managed to learn to do reasonably well: to easily and conveniently put locations and/or pictures of their friends in the Picks page/tab of their SL profiles. If you want usefully to discuss the matter a good next step might be to spell out just how one could implement your suggestion while creating a user (resident) experience that makes it at least as easy/convenient for folks to do what they already do -- preferably even easier and more convenient. As to your "technical list" comment and its implication that it is somehow irrelevant in the context of Second Life software development to discuss the impact on a non-technical user's (in this case an SL resident's) experience of the software being developed, well, I'd say that is fair evidence that my concern about technically-oriented developers sometimes paying insufficient attention to the purpose, function, and impact on users (SL residents in this case) of the software they develop is reasonably well founded. All the best, Arifi/Will Arifi Saeed Research Director,SL Canopus Research Inc. William F. Zachmann President, Canopus Research Inc. Contributing Editor, Redmond Developer News wfz@canopusresearch.com +1-781-934-9800 (office) +1-617-851-0773 (mobile) Skype: william.f.zachmann -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Callum Lerwick Sent: Sunday, April 20, 2008 3:20 AM To: sldev@lists.secondlife.com Subject: RE: [sldev] Linden Lab Navigations and Landmark Project On Sat, 2008-04-19 at 13:08 -0700, William F. Zachmann wrote: > I think this is an important issue not simply in terms of the specific > point here, but more broadly in that there does not seem to me to be > sufficient awareness and concern among developers working on the > software of the perspective of ordinary residents in Second Life (and > many more who do not ever become active residents because they find it > too difficult to learn their way around). My concern is that > technically proficient programmers do not typically find it very easy > to put themselves in the shoes of a non-technical user (SL resident) > or to appreciate how difficult it is for ordinary people to learn > their way around SL. And non-technical users have trouble understanding what engineers are talking about on (what I thought was) a technical list. I really have better things to do than hand-hold everyone through every offhand idea I toss out to the world. No, I'm not proposing users hand-write profile pages in vi on their own server. I'm talking about moving the *backend implementation* to standard, proven, flexible, adaptable and interoperable web technology. This would all still happen within the SL viewer on top of Linden Lab's infrastructure. Assuming LL is at all interested in this idea. From me at signpostmarv.name Sun Apr 20 06:19:15 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Apr 20 06:19:18 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> Message-ID: <480B42D3.9030700@signpostmarv.name> Anna Gulaev wrote: > *Callum Lerwick* wrote: > > How about we just nuke profiles out of the client and SL protocol > entirely and push them out onto the web? > They're on the web already- http://world.secondlife.com/resident/83b3987f-9520-4275-8efe-3ac13dd3f635 > If profiles go the way of other things and become web-based, at least > keep them under viewer-generated control so they remain consistent and > concise, and keep them on LL-owned property. Too late for that- http://svc.sl.net.marvulous.co.uk/resident/SignpostMarv+Martin Darien Caldwell wrote: > Reading the Wiki entry, it sounds like a lot of good ideas. However, > the talk of doing away with User Picks is worrisome. LL may not be > aware, but many people use Picks like an extended area of their > personal profile. The locations in the picks often are meaningless, > it's the words and pictures which are of importance. Personally, I would like to see the picks *improved*. In addition to listing picks under sw.slr using the hReview microformat, it'd be nice to know when a pick was filed, so the picks could be marked up with hAtom. Through my work with sw.slr, I've found that Residents tend to use Picks as mini-blog posts (hence the desire to mark them up as hAtom), so it would be interesting to see the picks have an option to export to the Resident's blog (though I'm not sure about directly from the viewer vs sending into LL and having it posted from their end) One of the things I'm doing with picks that Linden Lab isn't is cross-referencing picks to see what Residents are saying about each other: http://svc.sl.net.marvulous.co.uk/resident/Blue+Linden/mentioned/ Also oddly enough, picks on parcels aren't displayed on world.secondlife.com or in the viewer- http://world.secondlife.com/place/b383dd14-c80e-c0fe-bd55-f5113abe4054 vs http://svc.sl.net.marvulous.co.uk/place/Content+to+Hover/New+Havok4+Meeting+Spot! Argent Stonecutter wrote: > Because then nobody can view profiles without potentially revealing to > the person they're viewing that they have viewed the profile and where > on the net they were viewing from. Since Linden Lab host these on world.secondlife.com already, that wouldn't be an issue, unless you're referring to Residents hosting their profiles themselves. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080420/f537543e/smime.bin From matthew.dowd at hotmail.co.uk Sun Apr 20 06:31:56 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Apr 20 06:32:08 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480B42D3.9030700@signpostmarv.name> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> Message-ID: > > How about we just nuke profiles out of the client and SL protocol> > entirely and push them out onto the web?> >> They're on the web already-> http://world.secondlife.com/resident/83b3987f-9520-4275-8efe-3ac13dd3f635 Yes, and many argued when LL did this due to the new google search appliance, that publicly accessible web versions of profiles should be a) opt in, not opt out b) independent of opting in to search LL's disregard of people's privacy when implementing the new search is not a particularly good precedence to follow for further work on profiles. If anything future work on profiles (and search) should get us back to the original situation (publically accessible web profiles being opt in, and other features not being dependent on opting in). This is of course a different argument to those that internally communications between viewer and sim regarding profiles could use HTTP(S)/HTML based protocols and standards - although the problems and performance of the current embedded HTML browser would make me personally reluctant to use HTML formatting for such things/ Matthew _________________________________________________________________ Win 100?s of Virgin Experience days with BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080420/76623fa6/attachment-0001.htm From secret.argent at gmail.com Sun Apr 20 07:02:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Apr 20 07:02:22 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480B42D3.9030700@signpostmarv.name> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> Message-ID: On 2008-04-20, at 08:19, SignpostMarv Martin wrote: > Argent Stonecutter wrote: >> Because then nobody can view profiles without potentially >> revealing to the person they're viewing that they have viewed the >> profile and where on the net they were viewing from. > Since Linden Lab host these on world.secondlife.com already, that > wouldn't be an issue, unless you're referring to Residents hosting > their > profiles themselves. That was what I was referring to, yes. Good point: that would clearly not be an issue for Linden-hosted profiles. I would hope, though, that LL would not proceed from having the profiles rendered in the web to allowing users to host their own profile pictures or embed HTML in text fields. From me at signpostmarv.name Sun Apr 20 07:14:50 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Apr 20 07:14:53 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> Message-ID: <480B4FDA.6020104@signpostmarv.name> Argent Stonecutter wrote: > That was what I was referring to, yes. Good point: that would clearly > not be an issue for Linden-hosted profiles. I would hope, though, that > LL would not proceed from having the profiles rendered in the web to > allowing users to host their own profile pictures or embed HTML in > text fields. I just hope Linden Lab don't go all MySpace on us and allow Residents to create garish designs for their profiles :-P Just curious what your thoughts are on 3rd parties (such as myself) reusing the world.secondlife.com data on their own sites ? ~ Marv -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080420/7cb3be85/smime.bin From secret.argent at gmail.com Sun Apr 20 08:38:38 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Apr 20 08:38:38 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480B4FDA.6020104@signpostmarv.name> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> <480B4FDA.6020104@signpostmarv.name> Message-ID: <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> On 2008-04-20, at 09:14, SignpostMarv Martin wrote: > Just curious what your thoughts are on 3rd parties (such as myself) > reusing the world.secondlife.com data on their own sites ? I think they should only be available on world.secondlife.com if the user chooses, but given that they are available I don't see any useful purpose in restricting what "good guys" do with them, since bad guys will do unto them regardless. From me at signpostmarv.name Sun Apr 20 09:33:28 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Apr 20 09:33:31 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> <480B4FDA.6020104@signpostmarv.name> <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> Message-ID: <480B7058.40309@signpostmarv.name> BTW, I *only* use data that Linden Lab publishes in the web now- if I used libSecondLife, I'd be able to get profile data for those who hadn't opted to allow Linden Lab to publish their profiles out of world. I have previously used the eventful.com API to get events data, but now I'm using solely first-party sources, albeit 3 *different* first-party sources, due to the inconsistency with which the data is presented. ~ Marv Argent Stonecutter wrote: > On 2008-04-20, at 09:14, SignpostMarv Martin wrote: >> Just curious what your thoughts are on 3rd parties (such as myself) >> reusing the world.secondlife.com data on their own sites ? > > I think they should only be available on world.secondlife.com if the > user chooses, but given that they are available I don't see any useful > purpose in restricting what "good guys" do with them, since bad guys > will do unto them regardless. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080420/1afa7ca9/smime.bin From matthew.dowd at hotmail.co.uk Sun Apr 20 09:33:38 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Apr 20 09:33:39 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> <480B4FDA.6020104@signpostmarv.name> <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> Message-ID: Ironically, someone created a prim which displayed the profile picks of nearby avatars (basically a script doing a sensor to detect nearby avatar keys and then pulling the picture from world.secondlife.com via the parcel media settings). LL removed this prim on the basis it violated the community standards for privacy. Technically, therefore using this information on another website should also be a ToS/CS violation but of course restricting those with SL accounts but still leaving this information usable by anyone else on the web doesn't really make sense. Matthew > From: secret.argent@gmail.com> Subject: Re: [sldev] Linden Lab Navigations and Landmark Project> Date: Sun, 20 Apr 2008 10:38:38 -0500> To: sldev@lists.secondlife.com> > On 2008-04-20, at 09:14, SignpostMarv Martin wrote:> > Just curious what your thoughts are on 3rd parties (such as myself) > > reusing the world.secondlife.com data on their own sites ?> > I think they should only be available on world.secondlife.com if the > user chooses, but given that they are available I don't see any > useful purpose in restricting what "good guys" do with them, since > bad guys will do unto them regardless.> > > _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Amazing prizes every hour with Live Search Big Snap http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080420/7382bc3b/attachment.htm From matthew.dowd at hotmail.co.uk Sun Apr 20 09:59:19 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Apr 20 09:59:23 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480B7058.40309@signpostmarv.name> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> <480B4FDA.6020104@signpostmarv.name> <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> <480B7058.40309@signpostmarv.name> Message-ID: In order to use libSL you need to sign up an account, i.e. sign up to the ToS. LL could outlaw the mass publication/dissemination of profile information obtained via LibSL as a ToS/CS violation in the same way it outlaws the use of LibSL for theft etc. There are no such controls on data published on a publically accessible website. How many of those people for whom LL now publishes their profiles explicitly gave LL permission to do so (beyond any catch-all clauses in the ToS) or even realise that LL does! Before the new search there was a checkbox "Show on web" for explicit permission from the user before the profile was web accessible. That vanished with the new search implementation - being replaces by a "Show in Search" checkbox with no indication that "Show in Search" also makes your profile accessible over the web by people who do not have SL acounts, and who are not bound by the SL ToS and CS. My recollection is that the "Show in Search" checkbox is on by default - even for accounts which had previously had the "Show on Web" box unchecked! The fact that LL took action against someone using the profile information published on the web within SL itself, shows some confusion within LL over their publication of this data! In a nutshell, having profiles (and other in world information) available via world.secondlife.com without explicit opt in permission, and without the ability to opt out without losing in world functionality (in this case appearing in the new search) is a bug (in the sense of an undesired feature) of the new search: a bug best avoided rather than copied by other developments. Matthew > Date: Sun, 20 Apr 2008 17:33:28 +0100> From: me@signpostmarv.name> To: secret.argent@gmail.com> Subject: Re: [sldev] Linden Lab Navigations and Landmark Project> CC: sldev@lists.secondlife.com> > BTW, I *only* use data that Linden Lab publishes in the web now- if I > used libSecondLife, I'd be able to get profile data for those who hadn't > opted to allow Linden Lab to publish their profiles out of world.> > I have previously used the eventful.com API to get events data, but now > I'm using solely first-party sources, albeit 3 *different* first-party > sources, due to the inconsistency with which the data is presented.> > ~ Marv> > Argent Stonecutter wrote:> > On 2008-04-20, at 09:14, SignpostMarv Martin wrote:> >> Just curious what your thoughts are on 3rd parties (such as myself) > >> reusing the world.secondlife.com data on their own sites ?> >> > I think they should only be available on world.secondlife.com if the > > user chooses, but given that they are available I don't see any useful > > purpose in restricting what "good guys" do with them, since bad guys > > will do unto them regardless.> >> >> > _______________________________________________> > Click here to unsubscribe or manage your list subscription:> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev> > _________________________________________________________________ Welcome to the next generation of Windows Live http://www.windowslive.co.uk/get-live -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080420/062ba165/attachment-0001.htm From jacek.antonelli at gmail.com Sun Apr 20 12:37:44 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sun Apr 20 12:37:49 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <480B42D3.9030700@signpostmarv.name> <480B4FDA.6020104@signpostmarv.name> <3E60022D-1465-473E-BB30-E475E365F419@gmail.com> <480B7058.40309@signpostmarv.name> Message-ID: <105c09f0804201237l11486265ga1b0b62cfcbb8d6c@mail.gmail.com> I hate to be a bitch, but none of this has anything to do with the topic of the Navigation and Landmark Project. They're not removing profiles, nor moving them to the web, nor mashing them up with Myspace. They're not even actively planning to remove Picks. They're still in pre-planning stages, gathering Resident feedback. (Yes, imagine that, they're asking Residents what they want, and how they use the tools, before making any changes!) So if you'd like to continue this tangential discussion, could you please use another subject line, so I can more readily ignore this nonsense? I'd suggest as a more apropos subject line, "Bitching, moaning, and flaming about things Linden Lab isn't even doing". Cordially, - Jacek From xotmid at gmail.com Sun Apr 20 15:52:09 2008 From: xotmid at gmail.com (Brandon Husbands) Date: Sun Apr 20 15:52:11 2008 Subject: [sldev] Glow not working? Message-ID: I am in rc2 and it appears glow is no longer working... I am at max settings and its gone. This on the simulator side????? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080420/f4793128/attachment.htm From anthonyrbundy at gmail.com Sun Apr 20 17:22:08 2008 From: anthonyrbundy at gmail.com (Tony) Date: Sun Apr 20 17:22:11 2008 Subject: [sldev] Glow not working? In-Reply-To: References: Message-ID: <480BDE30.6070807@gmail.com> It is working fine for me. You might need to file an issue on JIRA if it is related to your specifica system settings. Brandon Husbands wrote: > I am in rc2 and it appears glow is no longer working... I am at max > settings and its gone. This on the simulator side????? > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kfa at gmx.net Sun Apr 20 22:52:21 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sun Apr 20 22:52:33 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480ADB99.6010506@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> Message-ID: <480C2B95.9070509@gmx.net> Just found this: http://svn.secondlife.com/svn/linden/patches/mono-viewer-r79030.patch If I'm not legally blind (which is quite possible at this morning hour), it doesn't appear as if the script compiler will be taken out of the viewer. Unless this is a temporary fix and future plans are different. I haven't tried applying this patch, not sure if it would work just so. Additions to files.lst indicate a number of files under a new folder lscript_execute_mono, but the patch doesn't contain them. I may have missed some bits and pieces though, was just skimming over it. Felix Duesenburg wrote: > Tateru Nino wrote: >> >> >> The script compiler isn't really staying. There's the old LSL >> compiler which might stay in the viewer (or move to the sim, not sure >> about that yet) and the mono compiler which definitely isn't going >> into the viewer last we heard. >> > > I keep hearing that, too, but so far it seems all rumours and nothing > conclusive. Can you cite sources? It's a difficult keyword to search > for, too many results. (To everybody: With things like that, always, > ALWAYS make proper citations with sources, please.) > > Because if that was so, I'd immediately stop all work with the script > compiler that I'm currently doing. But I've been in contact with > Lindens about a sandbox where to test my stuff should things go wrong, > and noone tried to discourage me. There are various JIRAs with feature > requests for LSL, but no Linden is answering there saying that it's > all going to be futile. I know that the current script compiler's days > are numbered, but features can be ported. If it was to be taken away > completely though, that would hurt. > > It would be good if we could have a statement from the horse's mouth, > saying it's either this way or that way to stop these rumours. Or a > pointer if we missed it. At the moment it feels rather uneasy indeed. > > Thanks, > Felix > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From matthew.dowd at hotmail.co.uk Mon Apr 21 01:22:48 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Apr 21 01:22:49 2008 Subject: [sldev] Jira down again In-Reply-To: <480C2B95.9070509@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480C2B95.9070509@gmx.net> Message-ID: Despite the blog saying resolved, it looks like jira (and the wiki) are down again. Matthew _________________________________________________________________ Get Hotmail on your mobile. Text MSN to 63463 now! http://mobile.uk.msn.com/pc/mail.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/29fd5a20/attachment.htm From carjay at gmx.net Mon Apr 21 12:20:23 2008 From: carjay at gmx.net (Carsten Juttner) Date: Mon Apr 21 12:20:42 2008 Subject: [sldev] Precompiled headers Message-ID: <480CE8F7.4050603@gmx.net> Hi, tried using precompiled headers for a Linux gcc build. I just made a rough comparison with previous compile times but the speedup seems to be around 20-25%. If newview/llviewerprecompiledheaders.h is to be used for all files (and not just the newview directory) then 2 patches are currently necessary. First, llcommon/lltimer.cpp includes timing.h for some reason which defines global time conversion constants differently. But since this file is marked as "deprecated" I think that is just some cleanup work not done yet. The second issue is that the header of libpng does not like a previous inclusion of setjmp.h and it seems to be pulled in by the precompiled header along the way. This can be prevented by simply adding the libpng-header to the precompiled header. Apart from that (and a problem that probably only concerns my build since I converted most of the internal static libs to dynamic libs and the -fPIC-flag is only present for dynamic libs so I'd need to create 2 different precompiled headers for these 2 cases) it builds (and runs) fine. SCons seems not to support precompiled headers (I created them more or less manually) and the last time I needed it, CMake only had a way to set up the headers for Visual Studio but not for gcc. So it's probably not that easy to generally enable without making some additions to the scripts. But maybe something to keep in mind for the cmake branch. Regards, Carsten From sldev at free.fr Mon Apr 21 12:32:35 2008 From: sldev at free.fr (Henri Beauchamp) Date: Mon Apr 21 12:32:39 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <480A1F12.5060004@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> Message-ID: <20080421213235.0bf03195.sldev@free.fr> On Sat, 19 Apr 2008 09:34:26 -0700, Rob Lanphier wrote: > On 4/10/08 11:35 AM, Henri Beauchamp wrote: > > On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > > > >> Henri Beauchamp wrote: > >> > >>> I already gave up submitting bug reports to the JIRA as this proved > >>> to be a total loss of time and energy. > >>> > >>> > >> I vote that some people are not allowed posting there anyway without a > >> patch attached. Especially those that claim they're so good that by the > >> time they spent ranting they could have squashed a few bugs. How come we > >> have any open issues at all then. > >> > > > > Be happy: http://sldev.free.fr/ > > > > I do not only criticize, I also contribute. All my patches were also > > submitted to the JIRA.... with little to no result. > > > ....but without a contribution agreement, so we can't accept the > changes :-( I already replied to you on this point: my patches are released under the GPL. You do not need a contribution agreement to apply GPLed patches to GPL code. Regards, Henri. From teravus at gmail.com Mon Apr 21 12:43:37 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Apr 21 12:43:40 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080421213235.0bf03195.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> Message-ID: <34cc66250804211243h4f5c018bubdf5e22790a2659e@mail.gmail.com> This seems a bit like a flame if you won't sign the contribution agreement. Why complain that they have not applied your patches if you won't follow the project rules? -Teravus On 4/21/08, Henri Beauchamp wrote: > > On Sat, 19 Apr 2008 09:34:26 -0700, Rob Lanphier wrote: > > > On 4/10/08 11:35 AM, Henri Beauchamp wrote: > > > On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > > > > > >> Henri Beauchamp wrote: > > >> > > >>> I already gave up submitting bug reports to the JIRA as this proved > > >>> to be a total loss of time and energy. > > >>> > > >>> > > >> I vote that some people are not allowed posting there anyway without > a > > >> patch attached. Especially those that claim they're so good that by > the > > >> time they spent ranting they could have squashed a few bugs. How come > we > > >> have any open issues at all then. > > >> > > > > > > Be happy: http://sldev.free.fr/ > > > > > > I do not only criticize, I also contribute. All my patches were also > > > submitted to the JIRA.... with little to no result. > > > > > ....but without a contribution agreement, so we can't accept the > > changes :-( > > I already replied to you on this point: my patches are released under > the GPL. You do not need a contribution agreement to apply GPLed patches > to GPL code. > > Regards, > > Henri. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/9fbb1abf/attachment.htm From labrat.hb at gmail.com Mon Apr 21 12:51:10 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Apr 21 12:51:14 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080421213235.0bf03195.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> Message-ID: The release client is not GPL. Without the contribution agreement they can't add that code to the release client. Which means it then can't be added to the GPL code, because that code is derived from the closed license release client. On Mon, Apr 21, 2008 at 12:32 PM, Henri Beauchamp wrote: > > On Sat, 19 Apr 2008 09:34:26 -0700, Rob Lanphier wrote: > > > On 4/10/08 11:35 AM, Henri Beauchamp wrote: > > > On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > > > > > >> Henri Beauchamp wrote: > > >> > > >>> I already gave up submitting bug reports to the JIRA as this proved > > >>> to be a total loss of time and energy. > > >>> > > >>> > > >> I vote that some people are not allowed posting there anyway without a > > >> patch attached. Especially those that claim they're so good that by the > > >> time they spent ranting they could have squashed a few bugs. How come we > > >> have any open issues at all then. > > >> > > > > > > Be happy: http://sldev.free.fr/ > > > > > > I do not only criticize, I also contribute. All my patches were also > > > submitted to the JIRA.... with little to no result. > > > > > ....but without a contribution agreement, so we can't accept the > > changes :-( > > I already replied to you on this point: my patches are released under > the GPL. You do not need a contribution agreement to apply GPLed patches > to GPL code. > > Regards, > > Henri. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From annagulaev at gmail.com Mon Apr 21 14:26:51 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Apr 21 14:26:55 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480A5327.6040308@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: Jason Giglio wrote: > Really getting sick of this bullshit. The world isn't going to stop > because you have this false belief that an IP address is private > information. At the moment, in SL, it *is* private information. That it isn't private elsewhere (WWW) is not a reasonable argument for making it not so in SL. I'd also argue that even on the web, my IP address is as private as I choose to make it. As a technically capable person who is aware of the issue I can decide how much I wish to expose it. For any activity I wish to engage in I must decide if the activity is worth the risk, and the risk I judge by the trustworthiness of the offering party. If you propose increasing the risk of an activity I'm already engaged in (SL) then I must make that decision for something I'm already invested in. This is why you'll get complaints, where you'd expect lesser concern over creating *new* offerings. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/477ff500/attachment.htm From lists at hippygeek.co.uk Mon Apr 21 15:45:08 2008 From: lists at hippygeek.co.uk (Ben Francis) Date: Mon Apr 21 15:46:25 2008 Subject: [sldev] [AWG] Comments on SLGOGP Draft 1 In-Reply-To: <480324E8.9060305@gmail.com> References: <480289C2.5010703@hippygeek.co.uk> <480324E8.9060305@gmail.com> Message-ID: <480D18F4.1040403@hippygeek.co.uk> Hi, Thanks for all the comments and welcoming messages and apologies for my belated reply. Some comments raised an interesting issue which is the distinction between "3D Internet" and "3D Web". This is something I won't go into here because it may be off topic, but I have written about it in my blog (http://www.tola.me.uk/blog/2008/04/21/3d_internet_vs_3d_web). Vivaty (previously MediaMachines) seem to think that X3D is up to the job of virtual worlds, but when their new service enters public beta, we will begin to see how the technology scales. Croquet is extremely interesting academically, but I've tried to get into it before and been put off by the squeaking sound. Perhaps I'm just narrow minded trying to stick with the familiar feel of HTTP and XML over at the Web3D consortium, but it worked for the web we have today and I see a lot of evidence that it could work for the 3D web of the future. I try to remain open minded. Keep up the good work Ben -- Ben Francis http://krellian.org From soft at lindenlab.com Mon Apr 21 17:17:12 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 21 17:17:17 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> Message-ID: More to it, the contributor agreement is an attempt at getting a single statement blessed by our legal department that the patches really are offered under specific terms of use. A mixture of differently worded offers to random Lindens through random channels would paralyze us. We'd constantly be stuck, trying to figure out what we can and can't do with code incorporating code under all those different offers. Even if we were a pure GPL project of this scale, as a commercial project we'd be mad to work without a contributor agreement. Take a look at the SCO debacle to see what ad hoc licensing work can lead to. An event like that would be trouble not just for LL, but for anyone else redistributing the code. On Mon, Apr 21, 2008 at 2:51 PM, Harold Brown wrote: > The release client is not GPL. Without the contribution agreement > they can't add that code to the release client. Which means it then > can't be added to the GPL code, because that code is derived from the > closed license release client. > > > > > On Mon, Apr 21, 2008 at 12:32 PM, Henri Beauchamp wrote: > > > > On Sat, 19 Apr 2008 09:34:26 -0700, Rob Lanphier wrote: > > > > > On 4/10/08 11:35 AM, Henri Beauchamp wrote: > > > > On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: > > > > > > > >> Henri Beauchamp wrote: > > > >> > > > >>> I already gave up submitting bug reports to the JIRA as this proved > > > >>> to be a total loss of time and energy. > > > >>> > > > >>> > > > >> I vote that some people are not allowed posting there anyway without a > > > >> patch attached. Especially those that claim they're so good that by the > > > >> time they spent ranting they could have squashed a few bugs. How come we > > > >> have any open issues at all then. > > > >> > > > > > > > > Be happy: http://sldev.free.fr/ > > > > > > > > I do not only criticize, I also contribute. All my patches were also > > > > submitted to the JIRA.... with little to no result. > > > > > > > ....but without a contribution agreement, so we can't accept the > > > changes :-( > > > > I already replied to you on this point: my patches are released under > > the GPL. You do not need a contribution agreement to apply GPLed patches > > to GPL code. > > > > Regards, > > > > Henri. > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From lenglish5 at cox.net Mon Apr 21 17:26:38 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Apr 21 17:26:41 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080421213235.0bf03195.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC2569.4020005@streamsense.net> <47FC2A69.4070606@gmail.com> <47FC583D.8060204@lindenlab.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> Message-ID: <480D30BE.3000401@cox.net> Henri Beauchamp wrote: > On Sat, 19 Apr 2008 09:34:26 -0700, Rob Lanphier wrote: > > >> On 4/10/08 11:35 AM, Henri Beauchamp wrote: >> >>> On Thu, 10 Apr 2008 14:22:40 -0400, Felix Duesenburg wrote: >>> >>> >>>> Henri Beauchamp wrote: >>>> >>>> >>>>> I already gave up submitting bug reports to the JIRA as this proved >>>>> to be a total loss of time and energy. >>>>> >>>>> >>>>> >>>> I vote that some people are not allowed posting there anyway without a >>>> patch attached. Especially those that claim they're so good that by the >>>> time they spent ranting they could have squashed a few bugs. How come we >>>> have any open issues at all then. >>>> >>>> >>> Be happy: http://sldev.free.fr/ >>> >>> I do not only criticize, I also contribute. All my patches were also >>> submitted to the JIRA.... with little to no result. >>> >>> >> ....but without a contribution agreement, so we can't accept the >> changes :-( >> > > I already replied to you on this point: my patches are released under > the GPL. You do not need a contribution agreement to apply GPLed patches > to GPL code. > > Regards, > > LL has its own agreement because they have been known to license the code to 3rd parties under a commercial license that does not require that party to contribute their private changes via GPL code, or such is my understanding. If you want your patch folded into LL's distro of the GPL code, you have to agree with their right to do the above. They've been pretty upfront about this issue, so... Lawson From gigstaggart at gmail.com Mon Apr 21 17:31:19 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Apr 21 17:31:23 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: <480D31D7.6040202@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anna Gulaev wrote: > If you propose increasing the risk of an activity I'm already engaged in > (SL) then I must make that decision for something I'm already invested in. > This is why you'll get complaints, where you'd expect lesser concern over > creating *new* offerings. Yeah so every competitor can do it, but SL can't, because of a tiny concerned minority? Linden Lab hosting every byte of content is not a viable plan for the future. I think I heard the asset servers are hosting something like 300 TB already. "Uploading the entire web to Linden Lab" is not a viable plan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDTHXvPhJdUgWbXsRAtFaAKC+QHxPMcGbBZ1PkOrWqf/wFrb5NQCg0Hz8 enaSuW99DukkUeXIVNYHE/s= =tVbC -----END PGP SIGNATURE----- From brad at lindenlab.com Mon Apr 21 17:41:16 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Mon Apr 21 17:39:25 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com><47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com><20080410172044.5cb31e9b.sldev@fr ee.fr> <47FE5AF0.6080109@gmx.net><20080410203552.22e899b0.sldev@free.fr><480A1F12.5060004@lindenlab.com><20080421213235.0bf03195.slde v@free.fr> Message-ID: <480D342C.6060203@lindenlab.com> I'd like to chime in and add that this is not specific to commercial projects either. The FSF has a very similar policy for GNU projects: http://www.fsf.org/licensing/licenses/gpl-faq.html#AssignCopyright and that's a big part of the historical reason for the permanence of the fork of xemacs from emacs (http://www.xemacs.org/About/XEmacsVsGNUemacs.html). Many other open source projects operate similarly. Projects like xemacs and the kernel that don't do this legal legwork are unusual I suspect, but I have no numbers to back that up. -Brad Soft wrote: > More to it, the contributor agreement is an attempt at getting a > single statement blessed by our legal department that the patches > really are offered under specific terms of use. A mixture of > differently worded offers to random Lindens through random channels > would paralyze us. We'd constantly be stuck, trying to figure out what > we can and can't do with code incorporating code under all those > different offers. > > Even if we were a pure GPL project of this scale, as a commercial > project we'd be mad to work without a contributor agreement. Take a > look at the SCO debacle to see what ad hoc licensing work can lead to. > An event like that would be trouble not just for LL, but for anyone > else redistributing the code. > > On Mon, Apr 21, 2008 at 2:51 PM, Harold Brown wrote: > >> The release client is not GPL. Without the contribution agreement >> they can't add that code to the release client. Which means it then >> can't be added to the GPL code, because that code is derived from the >> closed license release client. >> From robla at lindenlab.com Mon Apr 21 18:02:33 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Apr 21 18:02:36 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <480D342C.6060203@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com><47FC6B7F.2030803@gmail.com><47FD2C76.2060101@lindenlab. com><20080410172044.5cb31e9b.sldev@free.fr><47FE5AF0.6080109@gmx.n et><20080410203552.22e899b0.sldev@free.fr><480A1F12.5060004@lindenlab.com><20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> Message-ID: <480D3929.3070505@lindenlab.com> Contribution agreements are common but not universal. Sun has a pretty comprehensive FAQ for theirs here: http://www.sun.com/software/opensource/contributor_agreement.jsp A very common objection to contribution agreements generally and specifically with Linden Lab's is that it allows us to relicense the contribution such that it can be incorporated into proprietary products. Our position is that such a clause allows us to build a business model that allows us to pay the paychecks of more developers to write GPL licensed source code. This seems like a net win to me. Rob On 4/21/08 5:41 PM, Brad Kittenbrink (Brad Linden) wrote: > I'd like to chime in and add that this is not specific to commercial > projects either. The FSF has a very similar policy for GNU projects: > http://www.fsf.org/licensing/licenses/gpl-faq.html#AssignCopyright and > that's a big part of the historical reason for the permanence of the > fork of xemacs from emacs > (http://www.xemacs.org/About/XEmacsVsGNUemacs.html). Many other open > source projects operate similarly. Projects like xemacs and the > kernel that don't do this legal legwork are unusual I suspect, but I > have no numbers to back that up. > > -Brad > > Soft wrote: >> More to it, the contributor agreement is an attempt at getting a >> single statement blessed by our legal department that the patches >> really are offered under specific terms of use. A mixture of >> differently worded offers to random Lindens through random channels >> would paralyze us. We'd constantly be stuck, trying to figure out what >> we can and can't do with code incorporating code under all those >> different offers. >> >> Even if we were a pure GPL project of this scale, as a commercial >> project we'd be mad to work without a contributor agreement. Take a >> look at the SCO debacle to see what ad hoc licensing work can lead to. >> An event like that would be trouble not just for LL, but for anyone >> else redistributing the code. >> >> On Mon, Apr 21, 2008 at 2:51 PM, Harold Brown >> wrote: >> >>> The release client is not GPL. Without the contribution agreement >>> they can't add that code to the release client. Which means it then >>> can't be added to the GPL code, because that code is derived from the >>> closed license release client. >>> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080421/db55a9fd/signature.pgp From justizin at gmail.com Mon Apr 21 18:22:51 2008 From: justizin at gmail.com (Justin Ryan) Date: Mon Apr 21 18:22:55 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <480D3929.3070505@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> Message-ID: <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> On Mon, Apr 21, 2008 at 6:02 PM, Rob Lanphier wrote: > Contribution agreements are common but not universal. Sun has a pretty > comprehensive FAQ for theirs here: > http://www.sun.com/software/opensource/contributor_agreement.jsp > > A very common objection to contribution agreements generally and > specifically with Linden Lab's is that it allows us to relicense the > contribution such that it can be incorporated into proprietary products. > Our position is that such a clause allows us to build a business model that > allows us to pay the paychecks of more developers to write GPL licensed > source code. This seems like a net win to me. > There is a problem with this outlook, and it is not unique to companies like LL - in fact the Free Software Foundation's Head Counsel was involved in authoring the Plone Foundation's contributor agreement which allows the same. GPL code is not valuable simply because it exists in GPL, but because it is, or should be, original ideas protected from ever being non-GPL. The alternative is that you propose to sell the authors their code at some point. The problem here is that LL thinks of its' GPL creation(s) as something that it *owns* rather than *has the responsibility to protect*. You won't get any contributions from me directly as a member of the F/OSS community to a project where you can take credit for my code, and decide without my permission to use it as part of your business, without compensation. This is not an equal seat at the table and quite frankly, given that the Computer Graphics industry as a whole takes SL for something of the AOL of Metaverses, I think it is just a question of when, not whether, there will be a horrible decline in interest as other offerings based on truly open technology grow. That is, unless LL has enough foresight to see that, for one, they would be better served by existing as several small companies - an outlook that your average I-care-more-about-being-big-enough-for-an-IPO-that-will-never-happen-than-my-customers-happiness startup could really grow to embrace. The fact is that LL is an overglorified web hosting company with a product that will never be Free or Open-Source enough to allow for competition. Furthermore, existing GPL code may not be an acceptable contribution to a project which has a contributor agreement. My experience is that people pay these things lip service, that noone has any idea the original source of ideas in their dual licensed source code, and that it is very likely someone agreed on behalf of other people. In my opinion, what this makes clear for organizations like Linden Lab and Plone Foundation is that it is a litigation risk to enter into such a model. Also, it's ethically an ethically fragile approach to say the last. RMS promised me that he would write an essay on this some time ago when I raised caine with the Plone Foundation, but I'm sure he's other things to do than criticize his own staff. ;) Cheers! Justin -- Justin Alan Ryan Independent Interaction Architect http://www.bitmonk.net/ * : +1-415-226-1199 "I never meant to hurt anyone, or help anyone.." -Bender From seg at haxxed.com Mon Apr 21 18:58:30 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon Apr 21 18:58:41 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> Message-ID: <1208829510.11579.108.camel@localhost> On Mon, 2008-04-21 at 18:22 -0700, Justin Ryan wrote: > The problem here is that LL thinks of its' GPL creation(s) as > something that it *owns* rather than *has the responsibility to > protect*. You won't get any contributions from me directly as a > member of the F/OSS community to a project where you can take credit > for my code, I believe Linden Lab makes an honest effort to give people credit for their patches. You may very well disagree. > and decide without my permission to use it as part of > your business, without compensation. This is not an equal seat at the > table and quite frankly, given that the Computer Graphics industry as > a whole takes SL for something of the AOL of Metaverses, Without permission? Linden Lab will not take anything until you sign the CLA, and *submit* it yourself on Jira. If that is not "giving permission", then I don't know what is. No one is forcing you to submit your patches to LL. But if you choose to do so, you do it on their terms. That's the deal. Without compensation? Yes, it is an unequal seat at the table. Linden Lab has given you a hell of a lot more source code than you have given them. Have you actually coded *anything* or are you just another one of the loudmouths clogging up the list with un-constructive arguments and flamewars and personal agendas? There's a maddening lack of "Patch or GTFO" lately. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080421/1725b9ae/attachment.pgp From jessesa at gmail.com Mon Apr 21 19:02:40 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Mon Apr 21 19:02:45 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> Message-ID: On 4/21/08, Justin Ryan wrote: > > > There is a problem with this outlook, and it is not unique to > companies like LL - in fact the Free Software Foundation's Head > Counsel was involved in authoring the Plone Foundation's contributor > agreement which allows the same. > > GPL code is not valuable simply because it exists in GPL, but because > it is, or should be, original ideas protected from ever being non-GPL. > The alternative is that you propose to sell the authors their code at > some point. > > The problem here is that LL thinks of its' GPL creation(s) as > something that it *owns* rather than *has the responsibility to > protect*. You won't get any contributions from me directly as a > member of the F/OSS community to a project where you can take credit > for my code, and decide without my permission to use it as part of > your business, without compensation. This is not an equal seat at the > table and quite frankly, given that the Computer Graphics industry as > a whole takes SL for something of the AOL of Metaverses, I think it is > just a question of when, not whether, there will be a horrible decline > in interest as other offerings based on truly open technology grow. > > That is, unless LL has enough foresight to see that, for one, they > would be better served by existing as several small companies - an > outlook that your average > > I-care-more-about-being-big-enough-for-an-IPO-that-will-never-happen-than-my-customers-happiness > startup could really grow to embrace. The fact is that LL is an > overglorified web hosting company with a product that will never be > Free or Open-Source enough to allow for competition. > > Furthermore, existing GPL code may not be an acceptable contribution > to a project which has a contributor agreement. My experience is that > people pay these things lip service, that noone has any idea the > original source of ideas in their dual licensed source code, and that > it is very likely someone agreed on behalf of other people. > > In my opinion, what this makes clear for organizations like Linden Lab > and Plone Foundation is that it is a litigation risk to enter into > such a model. > > Also, it's ethically an ethically fragile approach to say the last. > RMS promised me that he would write an essay on this some time ago > when I raised caine with the Plone Foundation, but I'm sure he's other > things to do than criticize his own staff. ;) > > Cheers! > > Justin > > -- > Justin Alan Ryan > Independent Interaction Architect > http://www.bitmonk.net/ > * : +1-415-226-1199 > > "I never meant to hurt anyone, > or help anyone.." > -Bender > > Some will always disagree with the license, which is fine. Other view points keep everyone constantly thinking about an incredibly important matter. But you can't really lump the other arguments about what others think of the platform into the same response. I have been more then vocal on some subjects in the past and don't agree with everything LL does. But by voicing my concerns I hope to get others to at least consider my position. No matter what our individual pet peeves are, I think the majority here agree that there is a future, hopefully a very bright future for the platform. If I didn't think so, I would have already left. I have been looking and nothing else comes close yet to what LL offers and the ease with which people can create the world around them. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/d4aacfe8/attachment-0001.htm From tateru.nino at gmail.com Mon Apr 21 19:19:31 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Apr 21 19:24:42 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: <480D4B33.2000006@weblogsinc.com> Anna Gulaev wrote: > *Jason Giglio* wrote: > > Really getting sick of this bullshit. The world isn't going to stop > because you have this false belief that an IP address is private > information. > > > At the moment, in SL, it *is* private information. That it isn't > private elsewhere (WWW) is not a reasonable argument for making it not > so in SL. Umm. No it isn't, necessarily. You see, if you or I were using the same Web-based service, there'd probably be no way for me to obtain your IP address... (If I were *running* that service, that'd be different. You'd be all over the logs) In SL though, as long as you've got a webserver handy it is possible to obtain the IP address of anyone who enters your land or who transfers anything to you via your profile - under the right conditions. Privacy's good. There's no way to guarantee, however without eliminating existing functionality. I see LL being willing to do that... Oh.... around-about never. -- Tateru Nino http://www.massively.com/ From seg at haxxed.com Mon Apr 21 19:41:25 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon Apr 21 19:41:31 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <480D342C.6060203@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@fr ee.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr><480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.slde v@free.fr> <480D342C.6060203@lindenlab.com> Message-ID: <1208832085.11579.141.camel@localhost> On Mon, 2008-04-21 at 17:41 -0700, Brad Kittenbrink (Brad Linden) wrote: > I'd like to chime in and add that this is not specific to commercial > projects either. The FSF has a very similar policy for GNU projects: > http://www.fsf.org/licensing/licenses/gpl-faq.html#AssignCopyright and > that's a big part of the historical reason for the permanence of the > fork of xemacs from emacs > (http://www.xemacs.org/About/XEmacsVsGNUemacs.html). As the page says, the main reason the FSF does this is to allow them to actually enforce the GPL in a court of law should the need arise, without having to herd cats first. This is somewhat different than the reason commercial projects usually require CLAs, which is to make their own lawyers happy... > Many other open > source projects operate similarly. Projects like xemacs and the kernel > that don't do this legal legwork are unusual I suspect, but I have no > numbers to back that up. The Fedora Project requires a CLA: http://fedoraproject.org/wiki/Legal/Licenses/CLA Fedora itself is ostensibly a non-commercial project, but Red Hat pays the bills and like it or not it is legally culpable for anything Fedora does. > Projects like xemacs and the kernel > that don't do this legal legwork are unusual I suspect, but I have no > numbers to back that up. I'd say the FSF is unusual among non-commercial OS projects, in actually being prepared to fight a nasty legal battle. :) But of course GNU is a pretty large and critical chunk of most Linux-based open source systems these days. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080421/81df4372/attachment.pgp From seg at haxxed.com Mon Apr 21 19:56:26 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon Apr 21 19:56:33 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> Message-ID: <1208832986.11579.156.camel@localhost> Face it, the dominant culture of the internet is changing, as if it hasn't already. Hell, going by real names has been standard practice in the open source world since the beginning. Anonymity is going out of style. People are no longer separating their online identity from their real life. People are no longer interested in using the internet as an escape from real life, rather it is becoming a ubiquitous and vital piece of their Real Life. Wake up. (Hello culture clash.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080421/4fd36c3b/attachment.pgp From secret.argent at gmail.com Mon Apr 21 20:28:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 21 20:28:58 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D31D7.6040202@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: On 2008-04-21, at 19:31, Jason Giglio wrote: > Yeah so every competitor can do it, but SL can't, because of a tiny > concerned minority? Maybe they can, maybe they can't. There will no doubt be a variety of schemes, from places that are run similar to Wikipedia where everyone's IP is there to dig up, through places where your IP address is logged by only disclosed to the person whose blog you're commenting on, and ones where your IP address is nobody's business but your own. > Linden Lab hosting every byte of content is not a viable plan for > the future. There's really no alternative for the existing Linden grid. The content creators won't stand for anything else. There will be other grids, other subgrids, even other Linden grids. From secret.argent at gmail.com Mon Apr 21 20:31:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 21 20:31:22 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> Message-ID: <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> On 2008-04-21, at 20:22, Justin Ryan wrote: > GPL code is not valuable simply because it exists in GPL, but because > it is, or should be, original ideas protected from ever being non-GPL. That's certainly a point of view. It's not shared by the entire open source community. From secret.argent at gmail.com Mon Apr 21 20:34:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Apr 21 20:34:49 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D4B33.2000006@weblogsinc.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> Message-ID: <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> On 2008-04-21, at 21:19, Tateru Nino wrote: > In SL though, as long as you've got a webserver handy it is > possible to obtain the IP address of anyone who enters your land Only if they turn on streaming audio, or they turn on streaming media AND autorun. > or who transfers anything to you via your profile - under the right > conditions. Only if they turn on autorun. > Privacy's good. There's no way to guarantee, however without > eliminating existing functionality. Sure there is, except in the narrow sense that you can't have privacy in your home unless you eliminate the "leave the doors and windows open" functionality. From tateru.nino at gmail.com Mon Apr 21 20:35:26 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Apr 21 20:40:35 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> References: <480789DC.4050306@lindenlab.com> <48087EC4.505@weblogsinc.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> Message-ID: <480D5CFE.9010309@weblogsinc.com> Argent Stonecutter wrote: > On 2008-04-21, at 21:19, Tateru Nino wrote: >> In SL though, as long as you've got a webserver handy it is possible >> to obtain the IP address of anyone who enters your land > > Only if they turn on streaming audio, or they turn on streaming media > AND autorun. Exactly. > >> or who transfers anything to you via your profile - under the right >> conditions. > > Only if they turn on autorun. Also yes. > >> Privacy's good. There's no way to guarantee, however without >> eliminating existing functionality. > > Sure there is, except in the narrow sense that you can't have privacy > in your home unless you eliminate the "leave the doors and windows > open" functionality. Precisely my point. -- Tateru Nino http://www.massively.com/ From teravus at gmail.com Mon Apr 21 21:03:24 2008 From: teravus at gmail.com (Teravus Ovares) Date: Mon Apr 21 21:03:28 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D5CFE.9010309@weblogsinc.com> References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> Message-ID: <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> I'm sorry, I look at this and laugh. Unfortunately IP addresses are difficult and inconvenient to hide completely. In fact, simply look through the e-mail headers and you'll find the IP addresses of every poster to this list. Simply type that into a Geo-Location web-search and you have the general area where the IP address is registered which is often a good guess at where the person is. Sure, you may argue that you can get around it with a SMTP proxy, however.. in my experience using a SMTP proxy has resulted in my messages ending up in spam folders and outright blocked. HTTP proxies are overloaded and the simplest web-page takes 5 minutes to load. SSL proxies take even longer. I don't think there is really any way around it and I think unless you're doing something illegal or otherwise nasty it's a waste of time and resources to try and hide it. One such GeoLocation search that pins the pushpin on the absolute correct spot for me is: http://www.ipligence.com/geolocation/?lang=en The greifers should worry about it. The general population, however, gives their IP address up all day on the web. "Every 2 nanoseconds 100 unique ip addresses are logged." my 2Cents -Teravus On 4/21/08, Tateru Nino wrote: > > > > Argent Stonecutter wrote: > > > On 2008-04-21, at 21:19, Tateru Nino wrote: > > > > > In SL though, as long as you've got a webserver handy it is possible > > > to obtain the IP address of anyone who enters your land > > > > > > > Only if they turn on streaming audio, or they turn on streaming media > > AND autorun. > > > Exactly. > > > > > or who transfers anything to you via your profile - under the right > > > conditions. > > > > > > > Only if they turn on autorun. > > > Also yes. > > > > > Privacy's good. There's no way to guarantee, however without eliminating > > > existing functionality. > > > > > > > Sure there is, except in the narrow sense that you can't have privacy in > > your home unless you eliminate the "leave the doors and windows open" > > functionality. > > > Precisely my point. > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/e7a5df5a/attachment-0001.htm From ed at anuff.com Mon Apr 21 21:23:31 2008 From: ed at anuff.com (Ed Anuff) Date: Mon Apr 21 21:23:34 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project Message-ID: On Mon, Apr 21, 2008 at 7:02 PM, Jason Giglio wrote: > Linden Lab hosting every byte of content is not a viable plan for the > future. That's actually kind of sad, really, because what you're saying is that LL can't become the cloud computing provider of virtual worlds. Although it's really fashionable to talk about a decentralized grid and people running their own servers, if LL is going to be relevant in the long term, it's going to have to be able to be the Amazon EC2 of virtual worlds, anything else is going to get marginalized and/or commoditized over time. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/09807d3d/attachment.htm From robla at lindenlab.com Mon Apr 21 21:57:51 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Apr 21 21:58:01 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> Message-ID: <480D704F.6040308@lindenlab.com> Richard Stallman's original message probably didn't make it to the sldev list, since we're automatically bouncing non-member mails now (he's whitelisted now). Quoted in entirety below, with my response afterward: On 4/21/08 9:21 PM, Richard Stallman wrote: > [Justin Ryan wrote:] > You won't get any contributions from me directly as a > member of the F/OSS community to a project where you can take credit > for my code, and decide without my permission to use it as part of > your business, without compensation. > > If I were the author of a change, the crucial question for me would be > whether my change might be released in a non-free version of the > program. The worst outcome would be that some of my code might be > available to users _only_ in a non-free version. So I would seek to > put something in the contract to rule that out. > Our contribution agreement is a joint copyright assignment, so the original author retains full rights of authorship, and can ensure that the modifications remain freely available. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080421/49bbbdb5/signature.pgp From me at signpostmarv.name Mon Apr 21 22:41:37 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Apr 21 22:41:39 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: Message-ID: <480D7A91.5020209@signpostmarv.name> Ed Anuff wrote: > > On Mon, Apr 21, 2008 at 7:02 PM, Jason Giglio > wrote: > > Linden Lab hosting every byte of content is not a viable plan for the > future. > > > That's actually kind of sad, really, because what you're saying is > that LL can't become the cloud computing provider of virtual worlds. > Although it's really fashionable to talk about a decentralized grid > and people running their own servers, if LL is going to be relevant in > the long term, it's going to have to be able to be the Amazon EC2 of > virtual worlds, anything else is going to get marginalized and/or > commoditized over time. Storing all your eggs in one basket is a very, very bad idea. Do take into account that a sizeable chunk of Second Life is not too far from a major fault line. Decentralisation FTW! A hypothetical concept of decentralised asset storage is that a content creator could host their textures on an asset server they have complete control over, and could allow/disallow access to the assets on a Geo/IP level, a grid level, and possibly down to individual avatar requests, much in the same way web server/proxy/firewalls can be configured to disallow access from specific countries, IP ranges, networks and MAC addresses. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/947bf572/smime.bin From ed at anuff.com Mon Apr 21 23:32:47 2008 From: ed at anuff.com (Ed Anuff) Date: Mon Apr 21 23:32:50 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D7919.3070905@signpostmarv.name> References: <480D7919.3070905@signpostmarv.name> Message-ID: Far be if from me to challenge conventional wisdom on the subject, but I'll do it anyway. It looks like the new trend in large scale internet services is moving the other direction at the moment, Google, Amazon, etc. are getting people (first their business partners, now end-users and independent developers) to move code and content into their grids and datacenters. As to a content creator hosting their assets on a server they have "complete control" over, most high traffic websites use content networks or specialized hosting to handle their data transfers, no one who's hosting any sizable amount of rich media content is doing it themselves - they might have "complete control" via a management interface to Akamai, but if they're serving images from a machine they bought and own which sits in their server rack, for example, they're doing something wrong or they're very small-time. The LL grid should serve the purpose of being the cloud computing/content network optimized for serving content to virtual worlds. Now, whether it makes sense to have your datacenter on a fault line is a different question entirely. On Mon, Apr 21, 2008 at 10:35 PM, SignpostMarv Martin wrote: > Ed Anuff wrote: > > > > On Mon, Apr 21, 2008 at 7:02 PM, Jason Giglio > gigstaggart@gmail.com>> wrote: > > > > Linden Lab hosting every byte of content is not a viable plan for the > > future. > > > > That's actually kind of sad, really, because what you're saying is that > > LL can't become the cloud computing provider of virtual worlds. Although > > it's really fashionable to talk about a decentralized grid and people > > running their own servers, if LL is going to be relevant in the long term, > > it's going to have to be able to be the Amazon EC2 of virtual worlds, > > anything else is going to get marginalized and/or commoditized over time. > > > Storing all your eggs in one basket is a very, very bad idea. > > Do take into account that a sizeable chunk of Second Life is not too far > from a major fault line. > > Decentralisation FTW! > > A hypothetical concept of decentralised asset storage is that a content > creator could host their textures on an asset server they have complete > control over, and could allow/disallow access to the assets on a Geo/IP > level, a grid level, and possibly down to individual avatar requests, much > in the same way web server/proxy/firewalls can be configured to disallow > access from specific countries, IP ranges, networks and MAC addresses. > > > ~ Marv. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080421/2d9e7037/attachment.htm From me at signpostmarv.name Mon Apr 21 23:47:07 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Apr 21 23:47:11 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480D7919.3070905@signpostmarv.name> Message-ID: <480D89EB.6050809@signpostmarv.name> Swinging this topic back in the direction of the navigation/landmark project; Was the possibility of export/import of del.icio.us and/or other web-based bookmarking services discussed at the meeting last week ? ~ Marv Ed Anuff wrote: > Far be if from me to challenge conventional wisdom on the subject, but > I'll do it anyway. It looks like the new trend in large scale > internet services is moving the other direction at the moment, Google, > Amazon, etc. are getting people (first their business partners, now > end-users and independent developers) to move code and content into > their grids and datacenters. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/45ac96c2/smime-0001.bin From kfa at gmx.net Tue Apr 22 03:06:20 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 22 03:06:23 2008 Subject: [sldev] Refactoring and development economy In-Reply-To: <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> Message-ID: <480DB89C.8070301@gmx.net> Not sure if this has been talked about before, but wouldn't it make sense to implement some more design patterns to reach any degree of order that is better than the current one: - Strictly one file per class, no more and no less. I.e. a header/body pair since we're in C++. The filename is always the class name in lower case. - Headers are for declarations, the body for code. There are too many headers containing all kinds of things. - Avoid global functions and variables like the pest, i.e. anything except 'main'. It's especially bad to sprinkle them in between class methods. Instead, create toolkit classes with static methods and variables, or place them in a base class of the part of the application where it makes sense to find them. Naturally, this is coming from someone who has been doing Java a lot. I know it is so easy in IDE's like VS to just right click and 'find definition' to have a look at that function regardless whether you know where it is. But isn't this rather inviting chaos than helping to tame it. I'm not proposing to change that in one concerted effort, this would severely disrupt development. It should be a gradual process, performed a class at a time whenever a piece of code is touched. This wouldn't help just any OS hacker laying their paws onto the source, but would make real business sense making navigating easier for LL's dev team, also reducing the time they have to pay someone for going through the learning curve in case of staff turnover or enlargement. Discard in case I'm found talking utter rubbish. The thought that sparked this was a set of questions that I guess every OS'er is asking themselves: Do I refrain from fixing anything that isn't directly broken, or do I try to make it better anyway, which may be a subject of personal preference if it hasn't been openly discussed? Do I dare to undo things someone else has done, since I often don't know whether there's a reason for it being that way? Do I try to minimize my patches, even if it means adding to a convoluted mess? More generally than the above, I'm wondering if a series of JIRA's on refactoring certain parts of the viewer would attract enough attention, or even patches. But it would probably be better to discuss this there, since it encourages to keep threads on topic better than this list does. On the other hand, the list triggers replies since the messages get shoved into everyone's face, on JIRA you have to search for it. What to do? It was recently mentioned that some at LL are working hard on this. It would be great to have some more communication on where the effort is directed, which parts are already being tackled and which are in the pipeline, and what it's intended to look like. This would be valuable to know outside, since I foresee that some of my ideas, should I get them done in time, will result in patches clashing with a refactoring effort somewhere, and therefore cause extra workload in adapting and debugging if we ever want to have them implemented. Then maybe I'm the only one thinking that way. Felix From secret.argent at gmail.com Tue Apr 22 03:21:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 03:21:23 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> Message-ID: On 2008-04-21, at 23:03, Teravus Ovares wrote: > I look at this and laugh. Unfortunately IP addresses are > difficult and inconvenient to hide completely. And yet it works. > The greifers should worry about it. The general population, > however, gives their IP address up all day on the web. But not in Second Life. And don't give me any of that "if you have nothing to hide" crap. You're just begging for a dose of Godwin's Law. From babbage at lindenlab.com Tue Apr 22 03:55:03 2008 From: babbage at lindenlab.com (Jim Purbrick (Babbage)) Date: Tue Apr 22 03:55:04 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480ADB99.6010506@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> Message-ID: <480DC407.2010306@lindenlab.com> The plan is to move to server side compilation in the short term so that we can be sure that LSL bytecode we are executing is the output of the LSL compiler and not just arbitrary bytes or carefully crafted LSO files designed to exploit some weakness in the LSL runtime. The LSL compiler used by the asset upload framework is exactly the same code that is used in the current viewer compiler, so we can accept patches, but personally I would far rather see us move to allow other .NET languages than spend time patching and extending LSL. In the long term I'd like to be able to accept arbitrary CLI assemblies that we can verify and trust to run in the server sandbox. This requires significant hardening of the simulator script sandbox and we'd have to put a lot of faith in Mono's nascent verifier, but I think it's a compelling endgame: use any language that targets the CLI to script SL along with the tools and debugging facilities you get with that language. Or invent your own. and call it LSL3 if you must ;-) Cheers, Jim Felix Duesenburg wrote: > Tateru Nino wrote: >> >> >> The script compiler isn't really staying. There's the old LSL >> compiler which might stay in the viewer (or move to the sim, not sure >> about that yet) and the mono compiler which definitely isn't going >> into the viewer last we heard. >> > > I keep hearing that, too, but so far it seems all rumours and nothing > conclusive. Can you cite sources? It's a difficult keyword to search > for, too many results. (To everybody: With things like that, always, > ALWAYS make proper citations with sources, please.) > > Because if that was so, I'd immediately stop all work with the script > compiler that I'm currently doing. But I've been in contact with > Lindens about a sandbox where to test my stuff should things go wrong, > and noone tried to discourage me. There are various JIRAs with feature > requests for LSL, but no Linden is answering there saying that it's > all going to be futile. I know that the current script compiler's days > are numbered, but features can be ported. If it was to be taken away > completely though, that would hurt. > > It would be good if we could have a statement from the horse's mouth, > saying it's either this way or that way to stop these rumours. Or a > pointer if we missed it. At the moment it feels rather uneasy indeed. > > Thanks, > Felix > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kfa at gmx.net Tue Apr 22 04:54:07 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 22 04:54:14 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480DC407.2010306@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> Message-ID: <480DD1DF.1050907@gmx.net> That is great to know! Thank you for the reassurance. So, for the time being you won't get switch/case for LSL then. Or regular expressions. Or arrays. Or condensed storage for keys. Doesn't matter, there is enough other exciting stuff to work on, should be glad to strike off a few items from my list :) Anyway, I hope LL will stick with another statement made earlier, that LSL is not going to die. I think a lot of people have grown to like it, even if one may think that there are enough different programming languages in the world. Content creators in SL who never programmed before found it easy to learn. And those who know other languages found the state based approach quite unusual and highly suitable for the purpose. Someone has done a great job inventing this. So we'll see what the future brings, and indeed, 'LSL3' is just the term I had in mind. :) Cheers, Felix Jim Purbrick (Babbage) wrote: > The plan is to move to server side compilation in the short term so > that we can be sure that LSL bytecode we are executing is the output > of the LSL compiler and not just arbitrary bytes or carefully crafted > LSO files designed to exploit some weakness in the LSL runtime. > > The LSL compiler used by the asset upload framework is exactly the > same code that is used in the current viewer compiler, so we can > accept patches, but personally I would far rather see us move to allow > other .NET languages than spend time patching and extending LSL. > > In the long term I'd like to be able to accept arbitrary CLI > assemblies that we can verify and trust to run in the server sandbox. > This requires significant hardening of the simulator script sandbox > and we'd have to put a lot of faith in Mono's nascent verifier, but I > think it's a compelling endgame: use any language that targets the CLI > to script SL along with the tools and debugging facilities you get > with that language. Or invent your own. and call it LSL3 if you must ;-) > > Cheers, > > Jim > > Felix Duesenburg wrote: >> Tateru Nino wrote: >>> >>> >>> The script compiler isn't really staying. There's the old LSL >>> compiler which might stay in the viewer (or move to the sim, not >>> sure about that yet) and the mono compiler which definitely isn't >>> going into the viewer last we heard. >>> >> >> I keep hearing that, too, but so far it seems all rumours and nothing >> conclusive. Can you cite sources? It's a difficult keyword to search >> for, too many results. (To everybody: With things like that, always, >> ALWAYS make proper citations with sources, please.) >> >> Because if that was so, I'd immediately stop all work with the script >> compiler that I'm currently doing. But I've been in contact with >> Lindens about a sandbox where to test my stuff should things go >> wrong, and noone tried to discourage me. There are various JIRAs with >> feature requests for LSL, but no Linden is answering there saying >> that it's all going to be futile. I know that the current script >> compiler's days are numbered, but features can be ported. If it was >> to be taken away completely though, that would hurt. >> >> It would be good if we could have a statement from the horse's mouth, >> saying it's either this way or that way to stop these rumours. Or a >> pointer if we missed it. At the moment it feels rather uneasy indeed. >> >> Thanks, >> Felix >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From Anders at Arnholm.se Tue Apr 22 04:53:03 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Apr 22 04:55:56 2008 Subject: [sldev] 1.20.0.RC2 source build on Linux Message-ID: <20080422115303.GG3107@arnholm.se> I get core dump what starting i messed something up or anyone else have trouble. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/11f108a2/attachment.pgp From secret.argent at gmail.com Tue Apr 22 04:59:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 04:59:28 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480DC407.2010306@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> Message-ID: <642A3B4D-209C-4540-9CFD-8F7CDCB37A94@gmail.com> On 2008-04-22, at 05:55, Jim Purbrick (Babbage) wrote: > The LSL compiler used by the asset upload framework is exactly the > same code that is used in the current viewer compiler, so we can > accept patches, but personally I would far rather see us move to > allow other .NET languages than spend time patching and extending LSL. I really don't think you're giving LSL enough credit, and I don't think that the endgame is all that close. Yes, LSL is a funky language, but it's going to be what most in-world users are going to be using pretty much indefinitely, and most MFTLs (My Favorite Toy Languages) that are credible alternatives for the in- world scripting environment are not really any better. I suspect a first generation Palm Pilot had more available CPU and storage. A Forth or a Lisp, I could see. Javascript or Lua would be pushing it. From annagulaev at gmail.com Tue Apr 22 05:00:14 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Tue Apr 22 05:00:17 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D31D7.6040202@gmail.com> References: <480789DC.4050306@lindenlab.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: On 4/21/08, Jason Giglio wrote: > Yeah so every competitor can do it, but SL can't, because of a tiny > concerned minority? If by "competitor" you mean the alternate grids, I don't consider them competitors. I think they are unprofessional and their stand on IP and privacy are signs of their unprofessionalism, not some great opportunity. They'll be subject to the same infighting and divided focus and sloppy work as most other unprofessional projects. As long as they have the we're-smarter-than-you technodude attitude they'll always be the GIMP (infinitely flexible for the techno elite, your information wants to be my free information, yadda yadda, but mediocre) to someone else's Photoshop (and that probably won't be LL, who are more like GIMP in professionalism, but show signs of growing up). Linden Lab hosting every byte of content is not a viable plan for the > future. They don't have to. There's already a web tab on the profile, HTML on a prim, which will increase in functionality, and there will be more and more web links in the future, some of them provided by the residents themselves. Those offered by LL will be more carefully considered. Less interesting for the techno elite, perhaps, but better-behaved and ultimately more successful. The "metaverse" that reaches the masses and becomes successful is likely to be less flexible, not more flexible. Technical merit will not rule the future any more than it's ruled the past. The "metaverse" that is successful will be one that adults can take seriously, not one that is most pleasing to the technically adept few. It will be the one that has a good interface and provides an experience that isn't so easy for dorks and trouble makers to screw up. It doesn't *have* to be less technically capable; it's just easier to provide an adult experience with fewer opportunities for "expression". LL seems to be trying to find a balance. They may be pushed to be more like their perceived competitors, and that's made more likely by their being more like them than not like them. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/d498f4eb/attachment-0001.htm From tofu.linden at lindenlab.com Tue Apr 22 05:10:31 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Apr 22 05:10:29 2008 Subject: [sldev] 1.20.0.RC2 source build on Linux In-Reply-To: <20080422115303.GG3107@arnholm.se> References: <20080422115303.GG3107@arnholm.se> Message-ID: <480DD5B7.7080900@lindenlab.com> Anders Arnholm wrote: > I get core dump what starting i messed something up or anyone else have > trouble. Assuming you're using the linden libs bundle, try deleting the libboost_* libraries and substituting the versions from your distro (or your own-built versions). Let us know if that helps. libboost_* compatibility has been a headache for us recently. If this is the problem I'd probably favor removing libboost_* from the linden-libs package and mandating the distro version for opensource builds. -Tofu From Anders at Arnholm.se Tue Apr 22 05:48:50 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Apr 22 05:49:56 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: <20080422124850.GI3107@arnholm.se> On Tue, Apr 22, 2008 at 08:00:14AM -0400, Anna Gulaev wrote: > The "metaverse" that reaches the masses and becomes successful is likely to be > less flexible, not more flexible. Technical merit will not rule the future any Thios is exatly the reason we all use MSN viewer on out AOL net and not some standard web-browser towards at distrubuted internet with amny spread servers. > more than it's ruled the past. The "metaverse" that is successful will be one > that adults can take seriously, not one that is most pleasing to the > technically adept few. It will be the one that has a good interface and The one techology that wuill serve in the end is the one taht is eaisest to access all content almost regardless of who made it. The one thet don't force you into have int one single provider. Not even Microsoft will all there marketing succeded with that. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/7b2c88ba/attachment.pgp From tateru.nino at gmail.com Tue Apr 22 06:07:51 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Apr 22 06:13:02 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480DC407.2010306@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> Message-ID: <480DE327.7080502@weblogsinc.com> It doesn't sound like supporting arbitrary precompiled assemblies is exactly a short term goal. Jim Purbrick (Babbage) wrote: > The plan is to move to server side compilation in the short term so > that we can be sure that LSL bytecode we are executing is the output > of the LSL compiler and not just arbitrary bytes or carefully crafted > LSO files designed to exploit some weakness in the LSL runtime. > > The LSL compiler used by the asset upload framework is exactly the > same code that is used in the current viewer compiler, so we can > accept patches, but personally I would far rather see us move to allow > other .NET languages than spend time patching and extending LSL. > > In the long term I'd like to be able to accept arbitrary CLI > assemblies that we can verify and trust to run in the server sandbox. > This requires significant hardening of the simulator script sandbox > and we'd have to put a lot of faith in Mono's nascent verifier, but I > think it's a compelling endgame: use any language that targets the CLI > to script SL along with the tools and debugging facilities you get > with that language. Or invent your own. and call it LSL3 if you must ;-) > > Cheers, > > Jim > > Felix Duesenburg wrote: >> Tateru Nino wrote: >>> >>> >>> The script compiler isn't really staying. There's the old LSL >>> compiler which might stay in the viewer (or move to the sim, not >>> sure about that yet) and the mono compiler which definitely isn't >>> going into the viewer last we heard. >>> >> >> I keep hearing that, too, but so far it seems all rumours and nothing >> conclusive. Can you cite sources? It's a difficult keyword to search >> for, too many results. (To everybody: With things like that, always, >> ALWAYS make proper citations with sources, please.) >> >> Because if that was so, I'd immediately stop all work with the script >> compiler that I'm currently doing. But I've been in contact with >> Lindens about a sandbox where to test my stuff should things go >> wrong, and noone tried to discourage me. There are various JIRAs with >> feature requests for LSL, but no Linden is answering there saying >> that it's all going to be futile. I know that the current script >> compiler's days are numbered, but features can be ported. If it was >> to be taken away completely though, that would hurt. >> >> It would be good if we could have a statement from the horse's mouth, >> saying it's either this way or that way to stop these rumours. Or a >> pointer if we missed it. At the moment it feels rather uneasy indeed. >> >> Thanks, >> Felix >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From jrn2005 at cs.st-andrews.ac.uk Tue Apr 22 07:13:19 2008 From: jrn2005 at cs.st-andrews.ac.uk (J Ross Nicoll) Date: Tue Apr 22 07:13:38 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480DD1DF.1050907@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> <480DD1DF.1050907@gmx.net> Message-ID: <85575410-F19E-4AEC-8245-4FA6BB7623E5@cs.st-andrews.ac.uk> While LSL as a language is a good start, there's some features it could really do with. Like maps, functions local to states, error handling (in try-catch style), the ability to provide and use function libraries, and persistent storage, off the top of my head. Being able to do revision control using an external SVN repository would also be really useful, while I'm ranting/making a wishlist. Being able to do useful things in case of notecard lines over 255 chars in length (not to mention, why do I have to request each line individually rather than saying "Spool the entire notecard to me"), event queue overflow, more than 16 people in scan range, etc. would also be fantastic. Oh, and having animation perms on more than one person at a time, per script, being able to stop an animation we start if the animation is removed from inventory... In short, I'm not too attached to LSL as is. On 22 Apr 2008, at 12:54, Felix Duesenburg wrote: > That is great to know! Thank you for the reassurance. > > So, for the time being you won't get switch/case for LSL then. Or > regular expressions. Or arrays. Or condensed storage for keys. > > Doesn't matter, there is enough other exciting stuff to work on, > should be glad to strike off a few items from my list :) > > Anyway, I hope LL will stick with another statement made earlier, > that LSL is not going to die. I think a lot of people have grown to > like it, even if one may think that there are enough different > programming languages in the world. Content creators in SL who never > programmed before found it easy to learn. And those who know other > languages found the state based approach quite unusual and highly > suitable for the purpose. Someone has done a great job inventing > this. So we'll see what the future brings, and indeed, 'LSL3' is > just the term I had in mind. :) > > Cheers, > Felix > > > Jim Purbrick (Babbage) wrote: >> The plan is to move to server side compilation in the short term so >> that we can be sure that LSL bytecode we are executing is the >> output of the LSL compiler and not just arbitrary bytes or >> carefully crafted LSO files designed to exploit some weakness in >> the LSL runtime. >> >> The LSL compiler used by the asset upload framework is exactly the >> same code that is used in the current viewer compiler, so we can >> accept patches, but personally I would far rather see us move to >> allow other .NET languages than spend time patching and extending >> LSL. >> >> In the long term I'd like to be able to accept arbitrary CLI >> assemblies that we can verify and trust to run in the server >> sandbox. This requires significant hardening of the simulator >> script sandbox and we'd have to put a lot of faith in Mono's >> nascent verifier, but I think it's a compelling endgame: use any >> language that targets the CLI to script SL along with the tools and >> debugging facilities you get with that language. Or invent your >> own. and call it LSL3 if you must ;-) >> >> Cheers, >> >> Jim >> >> Felix Duesenburg wrote: >>> Tateru Nino wrote: >>>> >>>> >>>> The script compiler isn't really staying. There's the old LSL >>>> compiler which might stay in the viewer (or move to the sim, not >>>> sure about that yet) and the mono compiler which definitely isn't >>>> going into the viewer last we heard. >>>> >>> >>> I keep hearing that, too, but so far it seems all rumours and >>> nothing conclusive. Can you cite sources? It's a difficult keyword >>> to search for, too many results. (To everybody: With things like >>> that, always, ALWAYS make proper citations with sources, please.) >>> >>> Because if that was so, I'd immediately stop all work with the >>> script compiler that I'm currently doing. But I've been in contact >>> with Lindens about a sandbox where to test my stuff should things >>> go wrong, and noone tried to discourage me. There are various >>> JIRAs with feature requests for LSL, but no Linden is answering >>> there saying that it's all going to be futile. I know that the >>> current script compiler's days are numbered, but features can be >>> ported. If it was to be taken away completely though, that would >>> hurt. >>> >>> It would be good if we could have a statement from the horse's >>> mouth, saying it's either this way or that way to stop these >>> rumours. Or a pointer if we missed it. At the moment it feels >>> rather uneasy indeed. >>> >>> Thanks, >>> Felix >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev The University of St Andrews is a charity registered in Scotland : No SC013532 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/9e4a10eb/smime.bin From dmahalko at gmail.com Tue Apr 22 07:35:49 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Apr 22 07:35:54 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480D31D7.6040202@gmail.com> References: <480789DC.4050306@lindenlab.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: On Mon, Apr 21, 2008 at 7:31 PM, Jason Giglio wrote: > Linden Lab hosting every byte of content is not a viable plan for the > future. I think I heard the asset servers are hosting something like > 300 TB already. "Uploading the entire web to Linden Lab" is not a > viable plan. This drifts into the philosophical and technical discussion about virtual-world implementation. For a virtual environment to have a consistent legal standing and governance, it may be necessary to have everything contained within one system, vs just a client connecting to hundreds of disjointed and independent servers. Heh, I am now reminded of some science fiction where a corporately developed virtual world becomes so large and globally important that eventually the UN takes over operation of the system because it is so central and crucial to the operating of commerce and society. How can you have a consistent avatar appearance across a distributed system with no ultimate central authority to store your data? Would the lack of a global inventory and permissions system be a detriment to the use of a distributed virtual environment? Will distributed servers be willing to allow uploading of your avatar from your untrusted client? And if you're traveling, are you required to drag that personal client data around with you to use the distributed environment effectively, vs just sitting down anywhere and having it already made available from a central inventory authorty? This is still all so new that there is no way to answer these questions yet. We're going to have to wait for Croquet to fully go live across the planet, to find out if a distributed virtual environment can work. -Scalar Tardis / Dale Mahalko From jrn2005 at cs.st-andrews.ac.uk Tue Apr 22 07:44:18 2008 From: jrn2005 at cs.st-andrews.ac.uk (J Ross Nicoll) Date: Tue Apr 22 07:44:28 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: <7AE78A02-B7A2-401B-8D29-BFAFE3F34B96@cs.st-andrews.ac.uk> Was just pondering avatar appearance earlier, actually; is this a key requirement? I mean... lets say my avatar looks the same on most grids, where the grid operators have worked out a trust agreement with regard to content, and if I wander out to smaller grids I'm left with only freely copiable parts of my avatar/a cut down avatar/something else. Personally, I tend to think things I own should be stored on my computer, or on a better suited host of my choice (much in the same way I pay for web hosting), and served off that. So if I arrive at a new grid, I go "Hi, I'm Ross from the st-andrews.ac.uk domain", it does a DNS record lookup, finds the content server from SRV records, possibly checks credentials (signed X509 certificates?), grabs "me" from the St Andrews server, and I'm then "there"... On 22 Apr 2008, at 15:35, Dale Mahalko wrote: > How can you have a consistent avatar appearance across a distributed > system with no ultimate central authority to store your data? Would > the lack of a global inventory and permissions system be a detriment > to the use of a distributed virtual environment? Will distributed > servers be willing to allow uploading of your avatar from your > untrusted client? And if you're traveling, are you required to drag > that personal client data around with you to use the distributed > environment effectively, vs just sitting down anywhere and having it > already made available from a central inventory authorty? > > This is still all so new that there is no way to answer these > questions yet. We're going to have to wait for Croquet to fully go > live across the planet, to find out if a distributed virtual > environment can work. > > -Scalar Tardis / Dale Mahalko > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev The University of St Andrews is a charity registered in Scotland : No SC013532 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/585de2b1/smime-0001.bin From Anders at Arnholm.se Tue Apr 22 07:46:27 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Apr 22 07:46:40 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <1504037C-4781-48B5-9061-CC06A629AC0D@ama-zing.co.uk> <48092F9A.7070702@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D31D7.6040202@gmail.com> Message-ID: <20080422144627.GJ3107@arnholm.se> On Tue, Apr 22, 2008 at 09:35:49AM -0500, Dale Mahalko wrote: > How can you have a consistent avatar appearance across a distributed > system with no ultimate central authority to store your data? Would > the lack of a global inventory and permissions system be a detriment > to the use of a distributed virtual environment? Will distributed > servers be willing to allow uploading of your avatar from your > untrusted client? And if you're traveling, are you required to drag > that personal client data around with you to use the distributed > environment effectively, vs just sitting down anywhere and having it > already made available from a central inventory authorty? What is needed for this is a standard shared distributed system, with something like a global unified way of accessing the information, much lite the system we today have for websites, There is no single centralized inventory authority for websites. I don't see the need for it for avatars. The area that is troublesome is the areas of economics. distributed information sharing isn't a technical problem it's a problem of economics. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/71649049/attachment.pgp From kfa at gmx.net Tue Apr 22 08:18:39 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 22 08:18:44 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <85575410-F19E-4AEC-8245-4FA6BB7623E5@cs.st-andrews.ac.uk> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> <480DD1DF.1050907@gmx.net> <85575410-F19E-4AEC-8245-4FA6BB7623E5@cs.st-andrews.ac.uk> Message-ID: <480E01CF.4080303@gmx.net> There are two different things consistently getting mixed up: The LSL language structure and features that go into the compiled code (whether compilation happens on client or server side), and the backend capabilities that a script calls upon. Only the compiled part can be tweaked by us, in the future that is if after the move we'll be given the ability to upload CIL. Of the things you stated, only the first 3 (up to try-catch) fall into that category. The dataserver stuff, event queue serving and its limitations, the llfunction library, etc. are at the other end and we'll have to beg the Lindens with good reasons to get something changed there. Bringing in other .NET languages won't change anything on the backend side by itself. And that thing with the animations has nothing directly to do with the scripting language capabilities, it's a problem of how permissions are tied to objects, which is being discussed in other contexts. The ideas I was tossing out before solely had to do with making the compiled code more efficient and getting the most out of a small embedded machine, within the realm that we are given access to. J Ross Nicoll wrote: > While LSL as a language is a good start, there's some features it > could really do with. Like maps, functions local to states, error > handling (in try-catch style), the ability to provide and use function > libraries, and persistent storage, off the top of my head. Being able > to do revision control using an external SVN repository would also be > really useful, while I'm ranting/making a wishlist. Being able to do > useful things in case of notecard lines over 255 chars in length (not > to mention, why do I have to request each line individually rather > than saying "Spool the entire notecard to me"), event queue overflow, > more than 16 people in scan range, etc. would also be fantastic. Oh, > and having animation perms on more than one person at a time, per > script, being able to stop an animation we start if the animation is > removed from inventory... > > In short, I'm not too attached to LSL as is. > From carjay at gmx.net Tue Apr 22 08:23:43 2008 From: carjay at gmx.net (Carsten Juttner) Date: Tue Apr 22 08:23:51 2008 Subject: [sldev] 1.20.0.RC2 source build on Linux In-Reply-To: <480DD5B7.7080900@lindenlab.com> References: <20080422115303.GG3107@arnholm.se> <480DD5B7.7080900@lindenlab.com> Message-ID: <480E02FF.4040904@gmx.net> Tofu Linden wrote: > Let us know if that helps. libboost_* compatibility has been a > headache for us recently. If this is the problem I'd probably > favor removing libboost_* from the linden-libs package and > mandating the distro version for opensource builds. Just as a reassurance, since I use a 64 bit (Kubuntu Feisty) system exclusively, I have always linked against the distro boost libs and the 1.20 RC from SVN is actually the most stable version of the viewer I have used so far. Of course this requires removing the compiler-related version numbers from the link library names (I use gcc 4.1.2). Regards, Carsten From gigstaggart at gmail.com Tue Apr 22 08:45:22 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 22 08:45:31 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> Message-ID: <480E0812.1030007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: > And don't give me any of that "if you have nothing to hide" crap. > You're just begging for a dose of Godwin's Law. I don't think anyone's arguing that. It's just that IP addresses are inherently public information. It's *how computers communicate on the internet*. No one ever intended for IP addresses to be private, not even the original design of SL has this as a goal. It just happened, for the most part, as a side effect of the old architecture. You know, the one that doesn't scale. - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIDggSvPhJdUgWbXsRAgOgAKCoN7j6uoMz163NTVCqE3rOvOHLIACXRlYy sOJdIkp0YU1DQCv2glcTxA== =b56I -----END PGP SIGNATURE----- From dmahalko at gmail.com Tue Apr 22 08:51:20 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Apr 22 08:58:01 2008 Subject: [sldev] Grid redundancy in face of disaster (Re: Navigations and Landmark Project) Message-ID: On Tue, Apr 22, 2008 at 12:41 AM, SignpostMarv Martin wrote: > Storing all your eggs in one basket is a very, very bad idea. > > Do take into account that a sizeable chunk of Second Life is not too far > from a major fault line. > > Decentralisation FTW! Technically the LL grid is already capable of being decentralized and redundant to survive such regional catastrophes. Redundant sim distribution and sparing is doable, using the base architecture that LL already has in place now. Sims are currently assigned to run only from a specific machine in a specific colo at a specific network address, but they do not have to be like that. Any server is capable of running any simstate, and if storage of simstates is decentalized across the country then a sim can be run from any colo if a recent copy of the simstate is available. If powered-down reserve servers are permitted to exist in colos around the country, a local earthquake, fire, flood, hurricane, etc, need not take out large portions of SL. If LL's main sim facility goes down in California due to a quake, start all those sims up again in Texas and Chicago and Miami on the reserve servers. About an hour after a major disaster, clients need only be told to reconnect to the other colos to find those same sims again, while the main LL server facility might be going up in flames or whatever. The core grid systems can already potentially do this, but right now I believe moving sims to run on different servers is a manual process (recall the recent address move project that took a few days). A properly redundant grid would need an automated "sim concurrency" mechanism able to monitor the colo facilities, and to quickly boot up a recent simstate on a new server and rapidly inform all clients to use that newly assigned network address. Also, with the current asset system design I don't know if simstates are distributed across the country to other colo asset servers, to permit a hot-restart of servers that suddenly just went down permanently possibly thousands of miles away. But with the current grid architecture, it is definitely possible to be able to quickly work around and tolerate regional server facility disasters, without severely impacting the sims that were running from the destroyed facility. It mainly requires an investment in reserve server racks at each colo, wide distribution of simstates across regional asset servers at each colo, and a distributed grid management and monitoring system. -Scalar Tardis / Dale Mahalko From justizin at gmail.com Tue Apr 22 09:36:45 2008 From: justizin at gmail.com (Justin Ryan) Date: Tue Apr 22 09:36:56 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> Message-ID: <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> On Mon, Apr 21, 2008 at 8:31 PM, Argent Stonecutter wrote: > On 2008-04-21, at 20:22, Justin Ryan wrote: > > > GPL code is not valuable simply because it exists in GPL, but because > > it is, or should be, original ideas protected from ever being non-GPL. > > > > That's certainly a point of view. > > It's not shared by the entire open source community. > Hello Argent. The following is NOT an opinion: Open-Source != Free Software You have a lot of reading to do. The problem is frankly that it is unethical and illegal without proper permission to take Free Software and turn it into Open-Source. I simply have a lot of trouble believing that everything contributed under this agreement will be an original idea, not derived from another GPL work that someone not agreeing to these terms have rights over. I've a feeling that for many people, ignorance is bliss. Frankly this is more of a plea to Linden Lab not to follow the dark path which mostly puts them at risk and puts off the Free Software Community, which has given them ALL of the building blocks of their business, shrinkwrapped with a bow. -- Justin Alan Ryan Independent Interaction Architect http://www.bitmonk.net/ * : +1-415-226-1199 From justizin at gmail.com Tue Apr 22 09:52:19 2008 From: justizin at gmail.com (Justin Ryan) Date: Tue Apr 22 09:59:29 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> Message-ID: <77be04730804220952u6119ce24xb464105a8c5e6f0c@mail.gmail.com> On Mon, Apr 21, 2008 at 7:02 PM, Jesse Barnett wrote: > > Some will always disagree with the license, which is fine. Other view points > keep everyone constantly thinking about an incredibly important matter. But > you can't really > lump the other arguments about what others think of the platform into the > same response. > Telling a person that they "can't" do something they have already done is a highly sophomoric debate tactic. I'd also venture to say that as is the case with many people, including my ex-wife, you parse my communications looking for opportunities to respond, showing how smart you are, not actually engaging in true communications. I assure you, you are very, VERY, smart. *pats on head* In any case, Licensing and Agreements are about nothing but PEOPLE. LL is sitting on more than a gold mine - though clearly distracted by that experience - they are sitting on a thought mine, and other thought miners, even people who've been mining for longer and may have written some of the original code that SL is based on, are told that they can come and mine, without pay, alongside the employees, but all the spoils will go into LL's carts. We can take pictures home and please pay the "guest miner fee" on the way out. Anyway, my conclusion is that this direction will harm SL. Experience tells me that nothing I say can influence this decision, based on fear, but perhaps I can use this opportunity to educate the sldev community about the nature of Free Software. Free Software is about copyleft, "Intellectual Wealth" for all versus "Intellectual Property". The spirit of this is unquestionably violated when people claim they can call something Free Software while designing it as private property. I am even a bit concerned, ongoing, at RMS' growing ambivalence toward this problem. I am glad that the GPL is becoming popular, but its' power seems diluted when people essentially use it as if it were a BSD license. If you want to take contributors' code away and do with it what you want, use BSD, you will have no _less_ ability to derive existing GPL codebases than you have under this contributor agreement. If the contributor agreement were to include a clause such as RMS proposed, I believe that would make an argument for using the GPL here, but IMO the GPL has been nailed to a stake and had tomatoes thrown at it by LL here. And that's no great insult, LL, welcome to the long line of private interests that have messed up. You can grow from this, but I fear you are in the infinite loop of: "People will always disagree." Listen a bit closer. ;) -- Justin Alan Ryan Independent Interaction Architect http://www.bitmonk.net/ * : +1-415-226-1199 From justizin at gmail.com Tue Apr 22 10:02:38 2008 From: justizin at gmail.com (Justin Ryan) Date: Tue Apr 22 10:02:42 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <480D704F.6040308@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> Message-ID: <77be04730804221002n684581b3n27b4b439a583d362@mail.gmail.com> On Mon, Apr 21, 2008 at 9:57 PM, Rob Lanphier wrote: > > Our contribution agreement is a joint copyright assignment, so the original > author retains full rights of authorship, and can ensure that the > modifications remain freely available. > That is much better than the Plone Foundation, and I commend you for it, but I still think you're inviting trouble unless you can prove that these contributors have never worked on or studied GPL code that is not dual licensed under BSD, MIT, X11, or similar. IMO these sort of agreements laugh in the face of Free Software. Why do you deserve to privately license features jointly developed and initially paid for by your general customers? This is an unnatural assertion which can only stem from one of: * LL are planning something that you don't want to fully explain because it may limit interest in signing the contributor agreement. * LL are simply afraid of giving up control >From the perspective of someone whom has done Free Software PR for a good half of his life, the likelihood is the latter, but will cast aspersions toward the former. We all choose our own fate, LL. ;) -- Justin Alan Ryan Independent Interaction Architect http://www.bitmonk.net/ * : +1-415-226-1199 "I never meant to hurt anyone, or help anyone.." -Bender From justizin at gmail.com Tue Apr 22 10:05:34 2008 From: justizin at gmail.com (Justin Ryan) Date: Tue Apr 22 10:05:37 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804221002n684581b3n27b4b439a583d362@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <77be04730804221002n684581b3n27b4b439a583d362@mail.gmail.com> Message-ID: <77be04730804221005r4b2d9ef6w4274b9debdcacb3b@mail.gmail.com> BTW, folks, I bid Adieu to sldev, as I'm not really interested in contributing to the development of a platform under these terms, which I was not aware of until this thread. Best Wishes! J From sldev at free.fr Tue Apr 22 10:12:57 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 22 10:12:59 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> Message-ID: <20080422191257.6cc34cec.sldev@free.fr> On Mon, 21 Apr 2008 12:51:10 -0700, Harold Brown wrote: > The release client is not GPL. Without the contribution agreement > they can't add that code to the release client. Which means it then > can't be added to the GPL code, because that code is derived from the > closed license release client. The release client is not GPL because it includes code licensed under other licenses than the GPL. But to build the release client, they _do_ use GPL sources (among which the ones of viewer) together with non-GPL ones. And guess what... All my patches only apply to the GPLed source of the viewer. So, let's do some very high level mathematics... GPL sources + GPL patches = GPL sources Wow !... What a discovery !!! Like I said, LL does not need any license agreement from me to apply my GPL patches to their GPL sources. Beside, by posting my patches onto the JIRA, I did implicitely agree to their license agreement. Citation: "All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you've read, understood, and agreed to those terms." So, what's the matter ? Henri. From kfa at gmx.net Tue Apr 22 10:15:57 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 22 10:16:00 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080422191257.6cc34cec.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <20080422191257.6cc34cec.sldev@free.fr> Message-ID: <480E1D4D.7040004@gmx.net> Henri Beauchamp wrote: > So, what's the matter ? > > Henri. > > /SIGH From sldev at free.fr Tue Apr 22 10:36:43 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 22 10:36:45 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <34cc66250804211243h4f5c018bubdf5e22790a2659e@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <34cc66250804211243h4f5c018bubdf5e22790a2659e@mail.gmail.com> Message-ID: <20080422193643.2b807d67.sldev@free.fr> On Mon, 21 Apr 2008 15:43:37 -0400, Teravus Ovares wrote: > This seems a bit like a flame if you won't sign the contribution > agreement. I don't sign the paper they ask because I wish to keep my privacy and anonimity, like the French Law "Informatique et Libert?" entitles me to do. I don't see why I would give away my mailing address and phone number to LL just for seeing them use my contributions. SL is a game, nothing more for me. I don't intend to give away things that I keep private in real life (like my phone number, which is on a "red list", i.e. never published anywhere and that no company can ever access from a database) for just a game. Mind you, in France we do know what the respect of people privacy and peace means. > Why complain that they have not applied your patches if you > won't follow the project rules? I do follow and abide the GPL, and even LL's damned agreement (see my previous message about contributions to the JIRA), but I won't give away strictly personal and private data to an Internet-based company for it, sorry. Remember when LL got the Residents' credit card data stollen ? Well, call me paranoid, but I never trust Internet-based companies for keeping private data safe, and I trust them even less as to what they could do later themselves with this private data. 'nuff said. Henri. From danteferret at gmail.com Tue Apr 22 10:37:22 2008 From: danteferret at gmail.com (Dante Tucker) Date: Tue Apr 22 10:37:25 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080422191257.6cc34cec.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <20080422191257.6cc34cec.sldev@free.fr> Message-ID: <4d211a610804221037y1f282d4cv5d908dd6b3fee9d8@mail.gmail.com> On Tue, Apr 22, 2008 at 1:12 PM, Henri Beauchamp wrote: > On Mon, 21 Apr 2008 12:51:10 -0700, Harold Brown wrote: > > > So, what's the matter ? > What is the matter is the patches you submit are not going to be applyed to there GPL sources. So GPL sources + GPL patches = GPL sources may be true. But also completely unrelated to you submiting a patch to jira. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/e07b133c/attachment.htm From matthew.dowd at hotmail.co.uk Tue Apr 22 10:54:21 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Apr 22 10:54:23 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080422193643.2b807d67.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <34cc66250804211243h4f5c018bubdf5e22790a2659e@mail.gmail.com> <20080422193643.2b807d67.sldev@free.fr> Message-ID: LL sources are GPL but LL, as the owner of the code, has the right to make their source code available under different negotiated licenses if they wish to do so - and indeed have done so in the case of the CSI viewer. If source contributions are made as GPL, whilst LL could still make the source available as GPL, if LL wished to make the source code available under a different license it would need to seek explicit permission from those contributors. For that permission have legal viability, that permission needs to be signed and attributable to a real person (hence the blanket statement on the jira is not sufficient). The contributor agreement is essential prior permission to allow LL to do that. Some might have objections to giving LL the right to effectively sell their code if LL wish to do so without going back to the contributor. It should be noted however that a) the majority of patches have no real value outside of the SL viewer b) you still have full rights to the code yourself under the agreement and can sell or make it available under a free non-GPL license if you wish c) if the patch does have significant value (e.g. a new algorithm for rendering 3D which delivers high end GPU results on a 8Mhz 8086 processor for example), you do have the option *not* to contribute the source, or negotiate a different license with LL Unfortunately your wish for anonymity is precisely why LL can't accept your patches. If they did accept "Henri Beauchamp"'s patches, and negotiated a commercial license such as an updated CSI viewer, and then some RL French person claimed that LL had distributed code under a non-GPL license which they were not entitled to distribute under a non-GPL license, they would have no evidence to defend themselves to the contrary which would stand up in court. If, on the other hand, they had a document signed by a real person, LL at the very least have evidence acceptable by a court that they acted in good faith. Matthew > Date: Tue, 22 Apr 2008 19:36:43 +0200> From: sldev@free.fr> To: teravus@gmail.com> Subject: Re: [sldev] What is the point of firstlook and giving feedback to LL> CC: sldev@lists.secondlife.com> > On Mon, 21 Apr 2008 15:43:37 -0400, Teravus Ovares wrote:> > > This seems a bit like a flame if you won't sign the contribution> > agreement.> > I don't sign the paper they ask because I wish to keep my privacy> and anonimity, like the French Law "Informatique et Libert?"> entitles me to do.> > I don't see why I would give away my mailing address and phone> number to LL just for seeing them use my contributions.> > SL is a game, nothing more for me. I don't intend to give away> things that I keep private in real life (like my phone number,> which is on a "red list", i.e. never published anywhere and> that no company can ever access from a database) for just a game.> > Mind you, in France we do know what the respect of people privacy> and peace means.> > > Why complain that they have not applied your patches if you> > won't follow the project rules?> > I do follow and abide the GPL, and even LL's damned agreement> (see my previous message about contributions to the JIRA), but> I won't give away strictly personal and private data to an> Internet-based company for it, sorry.> > Remember when LL got the Residents' credit card data stollen ?> > Well, call me paranoid, but I never trust Internet-based companies> for keeping private data safe, and I trust them even less as to> what they could do later themselves with this private data.> > 'nuff said.> > Henri.> _______________________________________________> Click here to unsubscribe or manage your list subscription:> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ 100?s of prizes to be won at BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/2033cc08/attachment.htm From gigstaggart at gmail.com Tue Apr 22 11:05:56 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Apr 22 11:06:02 2008 Subject: [sldev] Grid redundancy in face of disaster (Re: Navigations and Landmark Project) In-Reply-To: References: Message-ID: <480E2904.2050000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dale Mahalko wrote: > Sims are currently assigned to run only from a specific machine in a > specific colo at a specific network address, but they do not have to > be like that. Any server is capable of running any simstate, and if > storage of simstates is decentalized across the country then a sim can > be run from any colo if a recent copy of the simstate is available. What makes you think that? That's not how it is at all. The pools are broken up by sim class and coloc. Other than that sims migrate around to spare boxes all the time. > If powered-down reserve servers are permitted to exist in colos around > the country, a local earthquake, fire, flood, hurricane, etc, need not > take out large portions of SL. If LL's main sim facility goes down in > California due to a quake, start all those sims up again in Texas and > Chicago and Miami on the reserve servers. I think the only reason simulators are tied to colocs right now is to prevent them migrating over the slower internet links unnecessarily. Sorry you wrote so many words based on false assumptions. :) - -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIDikEvPhJdUgWbXsRApAtAJ0ZiSPdD1A2ndpacIytLOOq/49/wwCfcD9S iE2GYvkPLo5z9X18uqdkvDs= =4ShX -----END PGP SIGNATURE----- From sldev at free.fr Tue Apr 22 11:12:05 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Apr 22 11:12:12 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <4d211a610804221037y1f282d4cv5d908dd6b3fee9d8@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <20080422191257.6cc34cec.sldev@free.fr> <4d211a610804221037y1f282d4cv5d908dd6b3fee9d8@mail.gmail.com> Message-ID: <20080422201205.1d02337e.sldev@free.fr> On Tue, 22 Apr 2008 13:37:22 -0400, Dante Tucker wrote: > On Tue, Apr 22, 2008 at 1:12 PM, Henri Beauchamp wrote: > > > On Mon, 21 Apr 2008 12:51:10 -0700, Harold Brown wrote: > > > > > > So, what's the matter ? > > > > What is the matter is the patches you submit are not going to be applyed to > there GPL sources. So GPL sources + GPL patches = GPL sources may be true. > But also completely unrelated to you submiting a patch to jira. When you cite someone's email, please do it properly. The "What's the matter" question was following the phrase in which I demonstrated that I by submitting patches to the JIRA I _did_ implicitely agree to LL's license agreement. So, the question stands: what's the matter, as I did agree already, even if not in the form of a written paper ? On Tue, 22 Apr 2008 17:54:21 +0000, Matthew Dowd wrote: > Unfortunately your wish for anonymity is precisely why LL can't accept your > patches. If they did accept "Henri Beauchamp"'s patches, and negotiated a > commercial license such as an updated CSI viewer, and then some RL French > person claimed that LL had distributed code under a non-GPL license which > they were not entitled to distribute under a non-GPL license, they would > have no evidence to defend themselves to the contrary which would stand > up in court. Yes, they have !!! My IP address is enough an evidence, and should LL need to find out who I trully am for whatever legal issue, they could ask a French judge who would in turn order my ISP to give away my true identity. But until then, and by the "Informatique et Libert?" Law, LL does not need any such private information from me, and I am well entitled not to give it away. Amuzingly, this thread gets closer to another on this list, about IP and privacy... :-D Henri. From Anders at Arnholm.se Tue Apr 22 11:43:19 2008 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Apr 22 11:43:31 2008 Subject: [sldev] 1.20.0.RC2 source build on Linux In-Reply-To: <480E02FF.4040904@gmx.net> References: <20080422115303.GG3107@arnholm.se> <480DD5B7.7080900@lindenlab.com> <480E02FF.4040904@gmx.net> Message-ID: <20080422184319.GK3107@arnholm.se> On Tue, Apr 22, 2008 at 05:23:43PM +0200, Carsten Juttner wrote: > Tofu Linden wrote: >> Let us know if that helps. libboost_* compatibility has been a >> headache for us recently. If this is the problem I'd probably >> favor removing libboost_* from the linden-libs package and >> mandating the distro version for opensource builds. > > Just as a reassurance, since I use a 64 bit (Kubuntu Feisty) system > exclusively, I have always linked against the distro boost libs and the > 1.20 RC from SVN is actually the most stable version of the viewer I have > used so far. > > Of course this requires removing the compiler-related version numbers from > the link library names (I use gcc 4.1.2). Yes changing to the distrib boost libraries fixed it and i took away the gcc version number from the scons file. Not sure it's as stable and 1.19.1.4 (with patches yet, the LL built version isn't). Hopefully have 1.20, patched and stable soon. There are some good and some bad thing about the new GUI looks. Some colors stuff is still unreadable like the (no mod) in inventory. The IM tab flashing got even less visible in this version. I guess that is going to make many more really pissed off, but that blame all on Dazzle, I think it would have been smart to make Phase 0 and Phase 1 (at least) before making main stream. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/b92cb1bb/attachment.pgp From matthew.dowd at hotmail.co.uk Tue Apr 22 11:47:33 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Apr 22 11:47:35 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080422201205.1d02337e.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <20080422191257.6cc34cec.sldev@free.fr> <4d211a610804221037y1f282d4cv5d908dd6b3fee9d8@mail.gmail.com> <20080422201205.1d02337e.sldev@free.fr> Message-ID: > Yes, they have !!! My IP address is enough an evidence, and should LL> need to find out who I trully am for whatever legal issue, they could ask> a French judge who would in turn order my ISP to give away my true identity. Apart from the minor fact that under EU Data Retention Directive which attempts (to some degree) to honour that privacy you seek: a) logs of ip addresses and activities against them need not be kept for longer than 6 months, and must be destroyed after 2 years (and of course LL can't know a priori whether you have a fixed ip or dynamic ip from your ISP, nor whether you will continue to do so and will not change ISPs) b) access to such logs by law enforcement agencies should be for "serious crimes" As such, it is unlikely that a French court would not order an ISP to turn over such data to a US court for a civil case, a major privacy infringement if the ISP offered this information without such an order; if the patch was submitted longer than 6 months previous to the case, there is a good chance that the ISP could not oblige with the data even if ordered to do so and after 2 years would not defintely be able to. A peice of paper at LL is a lot cheaper, simpler and permanent than attempting to get an International Court Order to access a foreign national's ISP data - even ignoring that under EU privacy laws such an attempt is likely to fail. Matthew _________________________________________________________________ Bag extra points with the Walkers Brit Trip Game http://www.walkersbrittrips.co.uk/game -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/eb65b7f7/attachment.htm From matthew.dowd at hotmail.co.uk Tue Apr 22 11:48:45 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Apr 22 11:48:47 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <20080422191257.6cc34cec.sldev@free.fr> <4d211a610804221037y1f282d4cv5d908dd6b3fee9d8@mail.gmail.com> <20080422201205.1d02337e.sldev@free.fr> Message-ID: Damn - typing too quickly for "it is unlikely that a French court would not order an ISP to turn over such data to a US court for a civil case" read "it is unlikely that a French court would order an ISP to turn over such data to a US court for a civil case"!!! From: matthew.dowd@hotmail.co.ukTo: sldev@free.fr; danteferret@gmail.comSubject: RE: [sldev] What is the point of firstlook and giving feedback to LLDate: Tue, 22 Apr 2008 18:47:33 +0000CC: sldev@lists.secondlife.com > Yes, they have !!! My IP address is enough an evidence, and should LL> need to find out who I trully am for whatever legal issue, they could ask> a French judge who would in turn order my ISP to give away my true identity.Apart from the minor fact that under EU Data Retention Directive which attempts (to some degree) to honour that privacy you seek: a) logs of ip addresses and activities against them need not be kept for longer than 6 months, and must be destroyed after 2 years (and of course LL can't know a priori whether you have a fixed ip or dynamic ip from your ISP, nor whether you will continue to do so and will not change ISPs)b) access to such logs by law enforcement agencies should be for "serious crimes" As such, it is unlikely that a French court would not order an ISP to turn over such data to a US court for a civil case, a major privacy infringement if the ISP offered this information without such an order; if the patch was submitted longer than 6 months previous to the case, there is a good chance that the ISP could not oblige with the data even if ordered to do so and after 2 years would not defintely be able to. A peice of paper at LL is a lot cheaper, simpler and permanent than attempting to get an International Court Order to access a foreign national's ISP data - even ignoring that under EU privacy laws such an attempt is likely to fail. Matthew Get fish-slapping on Messenger Play Now _________________________________________________________________ Bag extra points with the Walkers Brit Trip Game http://www.walkersbrittrips.co.uk/game -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/85afedea/attachment.htm From kfa at gmx.net Tue Apr 22 12:18:18 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 22 12:18:23 2008 Subject: [sldev] What is the point of firstlook and giving feedback to LL In-Reply-To: <20080422193643.2b807d67.sldev@free.fr> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <47FD2C76.2060101@lindenlab.com> <20080410172044.5cb31e9b.sldev@free.fr> <47FE5AF0.6080109@gmx.net> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <34cc66250804211243h4f5c018bubdf5e22790a2659e@mail.gmail.com> <20080422193643.2b807d67.sldev@free.fr> Message-ID: <480E39FA.8080105@gmx.net> Sorry for the previous reply which was a little short and did not contribute any information. However, I wonder why we have to go through this on every other list where you'd think that people ought to know better: Henri Beauchamp wrote: > On Mon, 21 Apr 2008 15:43:37 -0400, Teravus Ovares wrote: > > >> This seems a bit like a flame if you won't sign the contribution >> agreement. >> > > I don't sign the paper they ask because I wish to keep my privacy > and anonimity, like the French Law "Informatique et Libert?" > entitles me to do. > French law has no bearing there whatsoever. LL is in California, so the law of the state of California and the United States of America applies. If one doesn't like it, one doesn't have to deal with American companies. This is coming from your neighbour in "Old Europe", Germany, where we have a similar stance on certain issues. > I don't see why I would give away my mailing address and phone > number to LL just for seeing them use my contributions. > You never ordered anything, did you? They would need your mailing address to get the stuff to you. You never signed any kind of contract? They'd need your address and birthdate to identify you, even in France. You never registered a domain? There your address and phone number are public for everyone doing a whois lookup. Even if you use a domain by proxy service, you just give your address to /them/ instead on their promise not to hand it out. Along with your credit card details. You have to opt out of society altogether, be a hermit living in a cave to avoid any of this. A joint copyright agreement or any legal agreement at all can only be forged between parties that identify themselves. You know LL's address, they gets yours. > SL is a game, nothing more for me. I don't intend to give away > things that I keep private in real life (like my phone number, > which is on a "red list", i.e. never published anywhere and > that no company can ever access from a database) for just a game. > > Just a game? I was under the impression that in this place people do have a vision. You don't give out your private phone number to business contacts. Use a separate one, even a mobile, so long as it's registered to you and not an anonymous throwaway sim card. > Mind you, in France we do know what the respect of people privacy > and peace means. > > Now we could turn this into something, but we're already down to usenet niveau. >> Why complain that they have not applied your patches if you >> won't follow the project rules? >> > > I do follow and abide the GPL, and even LL's damned agreement > (see my previous message about contributions to the JIRA), but > I won't give away strictly personal and private data to an > Internet-based company for it, sorry. > What are you sorry for other than your work that's going to the wastebin. Who cares for the many standards that anyone abides by. To get your patches accepted you gotta sign the damn sheet, and that won't change after the umpteenth rant. > Remember when LL got the Residents' credit card data stollen ? > Aargh. You know what? I don't have a credit card. Maybe it's better to not have anything at all. They stole my bicycle and smashed the windows of my car to take a bottle of lubricant and a stuffed squirrel, plus the license plates. > Well, call me paranoid, but I never trust Internet-based companies > for keeping private data safe, and I trust them even less as to > what they could do later themselves with this private data. > They could visit you at your home and haunt you. > 'nuff said. > Whenever someone says that I brace myself for another flush. > Henri. > If you're still reading, I'd like to say I'm puzzled that we're having such vibes here on a public list. Your work is good and very welcome. What's the problem, man, is it pride? Said it before that programmers are a proud bunch with egos sometimes as big as cathedrals, yours truly no exception. But it's so silly to let that get in your way to fame and recognition - which would be to have one of your patches go into the official release and your name listed under the contributors in the 'About' dialog. If you want more than that, or if you're worried about your /free/ contribution resulting in an advantage for someone else, you're in the wrong place. Peace, Felix From jrn2005 at cs.st-andrews.ac.uk Tue Apr 22 15:07:14 2008 From: jrn2005 at cs.st-andrews.ac.uk (J Ross Nicoll) Date: Tue Apr 22 15:07:19 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480E0812.1030007@gmail.com> References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> <480E0812.1030007@gmail.com> Message-ID: <3B67ECAD-27AB-4E76-83A0-5F03B33853B0@cs.st-andrews.ac.uk> Agreed. Not to mention IP addresses are incredibly hard to keep hidden, because they're fundamental to so many things. Better to spend the effort minimising the data attached to the IP address, IMHO (which unfortunately is more an ISP issue). On 22 Apr 2008, at 16:45, Jason Giglio wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Argent Stonecutter wrote: >> And don't give me any of that "if you have nothing to hide" crap. >> You're just begging for a dose of Godwin's Law. > > I don't think anyone's arguing that. It's just that IP addresses are > inherently public information. It's *how computers communicate on the > internet*. No one ever intended for IP addresses to be private, not > even the original design of SL has this as a goal. It just happened, > for the most part, as a side effect of the old architecture. You > know, > the one that doesn't scale. > > - -Jason > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD4DBQFIDggSvPhJdUgWbXsRAgOgAKCoN7j6uoMz163NTVCqE3rOvOHLIACXRlYy > sOJdIkp0YU1DQCv2glcTxA== > =b56I > -----END PGP SIGNATURE----- > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev The University of St Andrews is a charity registered in Scotland : No SC013532 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2437 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080422/87451ac8/smime.bin From warkirby3333 at hotmail.co.uk Tue Apr 22 16:58:18 2008 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Tue Apr 22 16:58:20 2008 Subject: [sldev] A forum In-Reply-To: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> Message-ID: A new topic. I find myself wondering why this mailing list exists. It contains a lot of useful information and helpful people, but I mean, why does it exist as a mailing list? It's not exactly optimal to have to read through discussions you're not interested in, in a linear monolithic manner. It also has the problem of spamming up my inbox, even when in digest mode. And aside from that, we get random ads from microsoft in our mails from hotmail adresses. Given that the official SL forums are being overhauled, I'd like to suggest that this mailing list would work better as a subforum within the LL forums, perhaps. The forum/bulletin board structure has a lot of advantages over a single monolithic list like this, making it easy to keep up with particular topics and ignore those one isn't interested in, and not have a crammed full inbox every day. Does this seem like a good idea? _________________________________________________________________ Bag extra points with the Walkers Brit Trip Game http://www.walkersbrittrips.co.uk/game -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/1d02f5aa/attachment.htm From poppy at lindenlab.com Tue Apr 22 18:08:56 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Tue Apr 22 18:08:52 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <480D704F.6040308@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com><77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> Message-ID: <480E8C28.3080508@lindenlab.com> Richard Stallman reads SLDev? And thinks that as long as a policy lets you keep ownership it's decent? ?! + poppy Rob Lanphier wrote: > Richard Stallman's original message probably didn't make it to the sldev > list, since we're automatically bouncing non-member mails now (he's > whitelisted now). Quoted in entirety below, with my response afterward: > > On 4/21/08 9:21 PM, Richard Stallman wrote: >> [Justin Ryan wrote:] >> You won't get any contributions from me directly as a >> member of the F/OSS community to a project where you can take credit >> for my code, and decide without my permission to use it as part of >> your business, without compensation. >> >> If I were the author of a change, the crucial question for me would be >> whether my change might be released in a non-free version of the >> program. The worst outcome would be that some of my code might be >> available to users _only_ in a non-free version. So I would seek to >> put something in the contract to rule that out. >> > > Our contribution agreement is a joint copyright assignment, so the > original author retains full rights of authorship, and can ensure that > the modifications remain freely available. > > Rob > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From poppy at lindenlab.com Tue Apr 22 18:36:16 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Tue Apr 22 18:36:12 2008 Subject: [sldev] Nav and Landmark Project In-Reply-To: <480789DC.4050306@lindenlab.com> References: <480789DC.4050306@lindenlab.com> Message-ID: <480E9290.8010103@lindenlab.com> Stephany Filimon wrote: > This project will be public. This means that: > * PJIRA tasks and wiki pages will be available in the near future. Any links yet? Will the Landmarks not be in inventory anymore? Thanks for making this public! + poppy From sarah77 at gmail.com Tue Apr 22 18:43:22 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Tue Apr 22 18:43:24 2008 Subject: [sldev] Nav and Landmark Project In-Reply-To: <480E9290.8010103@lindenlab.com> References: <480789DC.4050306@lindenlab.com> <480E9290.8010103@lindenlab.com> Message-ID: <9010c35c0804221843v45e8cb78ra1d51a314919cd7a@mail.gmail.com> The WIKI page can be found here: http://wiki.secondlife.com/wiki/Landmarks_and_Navigation_Project The team will be updating it shortly with updates on research, ongoing resident discussions, and ideas! We are, indeed, investigating the feasibility of removing Landmarks from the inventory as a part of this project. Cheers, Kippie Friedkin On Tue, Apr 22, 2008 at 9:36 PM, Paul Oppenheim (Poppy Linden) < poppy@lindenlab.com> wrote: > Stephany Filimon wrote: > > > This project will be public. This means that: > > * PJIRA tasks and wiki pages will be available in the near future. > > > > Any links yet? > > Will the Landmarks not be in inventory anymore? > > Thanks for making this public! > > + poppy > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/9c95a8ef/attachment.htm From dmahalko at gmail.com Tue Apr 22 19:19:43 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue Apr 22 19:19:50 2008 Subject: [sldev] A forum In-Reply-To: References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> Message-ID: This mailing list is forum-ish, if your email program supports threading. Under Gmail it looks like a huge forum with only one "category" for every subject, and I have it all go into its own category/folder on arrival so it doesn't spam the main inbox. Using email vs a web board does seem a step backwards rather than forwards, but a web forum would likely invite more posting from irate users. I think LL is using this mailing list more as a bozo filter than anything else. The common blog comment whiner and complainer is apparantly not aware this list even exists or how to subscribe to it, so they just regularly spam the blog with complaints but don't know how to do it here. -Dale On Tue, Apr 22, 2008 at 6:58 PM, Paul Cook wrote: > A new topic. > > I find myself wondering why this mailing list exists. It contains a lot of > useful information and helpful people, but I mean, why does it exist as a > mailing list? > > It's not exactly optimal to have to read through discussions you're not > interested in, in a linear monolithic manner. It also has the problem of > spamming up my inbox, even when in digest mode. And aside from that, we get > random ads from microsoft in our mails from hotmail adresses. > > Given that the official SL forums are being overhauled, I'd like to suggest > that this mailing list would work better as a subforum within the LL forums, > perhaps. > > The forum/bulletin board structure has a lot of advantages over a single > monolithic list like this, making it easy to keep up with particular topics > and ignore those one isn't interested in, and not have a crammed full inbox > every day. > > Does this seem like a good idea? > > ________________________________ > Get fish-slapping on Messenger Play Now > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From secret.argent at gmail.com Tue Apr 22 20:11:32 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 20:11:30 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <480E0812.1030007@gmail.com> References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> <480E0812.1030007@gmail.com> Message-ID: <1DDAB8F7-E13A-4698-9FE1-D284744326C3@gmail.com> On 2008-04-22, at 10:45, Jason Giglio wrote: > Argent Stonecutter wrote: >> And don't give me any of that "if you have nothing to hide" crap. >> You're just begging for a dose of Godwin's Law. > > I don't think anyone's arguing that. It's just that IP addresses are > inherently public information. First, my IP address is only shared with computers I connect to. Not every computer on the Internet. So it's "public information" for a subset of the public. Just as your phone number is "public information" for people who have ANI. Second, my IP address is only associated with my identity if I divulge my identity to you. So the association "my IP address" and "my identity" is not "public information". That is, your IP address is like an 'unlisted' number. Third, the fact that my IP address has connected to your IP address is only known to me and you. That's private information. It's like knowing who you've called on the phone... the equivalent of having a pen recorder on your phone. Fourth, the intersection of the second and third cases is an even smaller subset. When you use third-party web content in world you take information that is in the fourth category, and put it in the third category: your IP address, your in-world identity, and information about what systems you (identified by your IP address, and closely identified with your in-world identity) and not just putting it in category 1, but doing so for computers you did not intend to connect to. From secret.argent at gmail.com Tue Apr 22 20:20:40 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 20:20:20 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> Message-ID: <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> On 2008-04-22, at 11:36, Justin Ryan wrote: > On Mon, Apr 21, 2008 at 8:31 PM, Argent Stonecutter > wrote: >> On 2008-04-21, at 20:22, Justin Ryan wrote: >>> GPL code is not valuable simply because it exists in GPL, but >>> because >>> it is, or should be, original ideas protected from ever being non- >>> GPL. >> That's certainly a point of view. >> It's not shared by the entire open source community. > Hello Argent. The following is NOT an opinion: > Open-Source != Free Software Yes, that is an opinion. It's not one I agree with. As it turns out, I was writing free software long before RMS penned the GNU Manifesto, so I am neither ignorant nor uneducated: I simply have a different opinion about the value of the GPL and about Richard Stallman's right to redefine the meaning of "free software" out from under the people who created the community that he hijacked. From secret.argent at gmail.com Tue Apr 22 20:22:37 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 20:22:24 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804221002n684581b3n27b4b439a583d362@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <77be04730804221002n684581b3n27b4b439a583d362@mail.gmail.com> Message-ID: On 2008-04-22, at 12:02, Justin Ryan wrote: > That is much better than the Plone Foundation, and I commend you for > it, but I still think you're inviting trouble unless you can prove > that these contributors have never worked on or studied GPL code that > is not dual licensed under BSD, MIT, X11, or similar. That's SCO's argument against Linux. Please tell me you don't honestly believe that if SCO had been a bit smarter about their contract with Novell they really WOULD have the rights to control the distribution of Linux that they claimed. From secret.argent at gmail.com Tue Apr 22 20:27:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 22 20:27:22 2008 Subject: [sldev] Linden Lab Navigations and Landmark Project In-Reply-To: <3B67ECAD-27AB-4E76-83A0-5F03B33853B0@cs.st-andrews.ac.uk> References: <480789DC.4050306@lindenlab.com> <003f01c8a1d1$b0385de0$647ba8c0@a644000> <711DD325-B796-4C02-A2E7-7968B0E7E111@ama-zing.co.uk> <1208595944.22067.64.camel@localhost> <1089A4FA-1CF9-4FA3-A9A8-FC357986BD99@gmail.com> <480A5327.6040308@gmail.com> <480D4B33.2000006@weblogsinc.com> <10847CC9-2CD1-4F8E-9393-B7984E979E57@gmail.com> <480D5CFE.9010309@weblogsinc.com> <34cc66250804212103p11a577cexf3a20666c9444d38@mail.gmail.com> <480E0812.1030007@gmail.com> <3B67ECAD-27AB-4E76-83A0-5F03B33853B0@cs.st-andrews.ac.uk> Message-ID: On 2008-04-22, at 17:07, J Ross Nicoll wrote: > Agreed. Not to mention IP addresses are incredibly hard to keep > hidden, because they're fundamental to so many things. Better to > spend the effort minimising the data attached to the IP address, IMHO That is the whole point: minimizing the data attached to your IP address, in this case reducing the chance of having your SL identity associated with your IP address. From GordonWendt at gmail.com Tue Apr 22 20:59:08 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Apr 22 20:59:12 2008 Subject: Contribution agreements (Re: [sldev] What is the point offirstlook and giving feedback to LL) In-Reply-To: <480E8C28.3080508@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <480E8C28.3080508@lindenlab.com> Message-ID: <493033a70804222059l2bcc3fb7kdb19bd9e3581238b@mail.gmail.com> I found that strange too but to each their own I guess and I guess that some good conversations (occassionally) happen here on the topic of software development. It sometimes surprises me more that Lindens actually read sldev and reply to it, not to mention how scary it is that you know how to insert the heart symbol into a message :) -G.W. On Tue, Apr 22, 2008 at 9:08 PM, Paul Oppenheim (Poppy Linden) < poppy@lindenlab.com> wrote: > Richard Stallman reads SLDev? And thinks that as long as a policy lets you > keep ownership it's decent? > > ?! > > + poppy > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080422/00d982f4/attachment.htm From tateru.nino at gmail.com Tue Apr 22 23:02:50 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Apr 22 23:08:03 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> Message-ID: <480ED10A.4070906@gmail.com> Argent Stonecutter wrote: >> Hello Argent. The following is NOT an opinion: > >> Open-Source != Free Software > > Yes, that is an opinion. It's not one I agree with. As it turns out, I > was writing free software long before RMS penned the GNU Manifesto, so > I am neither ignorant nor uneducated: I simply have a different > opinion about the value of the GPL and about Richard Stallman's right > to redefine the meaning of "free software" out from under the people > who created the community that he hijacked. I'm in complete agreement with Argent on this point. From seg at haxxed.com Tue Apr 22 23:13:10 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue Apr 22 23:13:17 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <480D704F.6040308@lindenlab.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> Message-ID: <1208931190.5050.8.camel@localhost> > On 4/21/08 9:21 PM, Richard Stallman wrote: > > [Justin Ryan wrote:] > > You won't get any contributions from me directly as a > > member of the F/OSS community to a project where you can take credit > > for my code, and decide without my permission to use it as part of > > your business, without compensation. > > > > If I were the author of a change, the crucial question for me would be > > whether my change might be released in a non-free version of the > > program. The worst outcome would be that some of my code might be > > available to users _only_ in a non-free version. So I would seek to > > put something in the contract to rule that out. People love to constantly vilify RMS as some kind of radical extremist. But every time I actually read his words he seems like a pretty sane reasonable guy to me. People spend too much time listening to his followers and critics, and not enough time listening to RMS himself. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080423/aebfa081/attachment-0001.pgp From robin.cornelius at gmail.com Tue Apr 22 23:28:11 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Apr 22 23:28:20 2008 Subject: [sldev] A forum In-Reply-To: References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> Message-ID: <480ED6FB.3020801@gmail.com> Paul Cook wrote: > A new topic. > > I find myself wondering why this mailing list exists. It contains a lot > of useful information and helpful people, but I mean, why does it exist > as a mailing list? This is the stuff of flame wars ;-) some people just prefer mailing lists and find them easier to deal with. I am one of those people. > > It's not exactly optimal to have to read through discussions you're not > interested in, in a linear monolithic manner. It also has the problem of > spamming up my inbox, even when in digest mode. And aside from that, we > get random ads from microsoft in our mails from hotmail adresses. I use thunderbird on my linux and windows boxes and it is perfectly capable of threading the message display so its very clear what the topic thread is. Only issue is if someone replies and changes the topic then it ends up out of thread. I get mails from some 10+ high volume lists, they all go into there own folders away from inbox and are all nicely threaded for me to see. > > Given that the official SL forums are being overhauled, I'd like to > suggest that this mailing list would work better as a subforum within > the LL forums, perhaps. I would polity request not to do this. > > The forum/bulletin board structure has a lot of advantages over a single > monolithic list like this, making it easy to keep up with particular > topics and ignore those one isn't interested in, and not have a crammed > full inbox every day. Mail filters and threaded display in your mail client? Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080423/0df5350a/signature.pgp From seg at haxxed.com Wed Apr 23 00:35:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed Apr 23 00:35:36 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> Message-ID: <1208936129.5050.27.camel@localhost> On Tue, 2008-04-22 at 09:36 -0700, Justin Ryan wrote: > You have a lot of reading to do. The problem is frankly that it is > unethical and illegal without proper permission to take Free Software > and turn it into Open-Source. I simply have a lot of trouble > believing that everything contributed under this agreement will be an > original idea, not derived from another GPL work that someone not > agreeing to these terms have rights over. The "FLOSS" world has been fighting against "intellectual property" for some time now. The FSF/RMS wants to eliminate the idea entirely. So what is with this sudden trend of using the idea of "intellectual property" to drive a wedge between "free software" and "open source" projects? When did we become enemies? This is completely un-necessary, hypocritical and ultimately self destructive. This thread proves it is not just BSD people, the GPL zealots are doing it too. Seriously, what the fuck is wrong with you people? http://www.gnu.org/philosophy/not-ipr.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080423/03cc604d/attachment.pgp From matthew.dowd at hotmail.co.uk Wed Apr 23 01:07:59 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 23 01:08:00 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <1208936129.5050.27.camel@localhost> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> <1208936129.5050.27.camel@localhost> Message-ID: > On Tue, 2008-04-22 at 09:36 -0700, Justin Ryan wrote:> > You have a lot of reading to do. The problem is frankly that it is> > unethical and illegal without proper permission to take Free Software> > and turn it into Open-Source. I simply have a lot of trouble> > believing that everything contributed under this agreement will be an> > original idea, not derived from another GPL work that someone not> > agreeing to these terms have rights over. That sounds like an argument against any project (open source or not) taking any contributions from any programmer (employed or not) on the basis that most code will not be original and will resemble code in another project (GPLed or not). Matthew _________________________________________________________________ Play the Andrex Hello Softie Game & win great prizes http://www.thehellosoftiegame.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080423/70ef3b64/attachment.htm From matthew.dowd at hotmail.co.uk Wed Apr 23 01:15:34 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 23 01:15:36 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> Message-ID: > > Open-Source != Free Software I don't think LL ever claimed that making the viewer Open-Source was making the viewer "free" (although admittedly LL's main revenue stream *isn't* from selling the viewer). The GPL license is an interesting double edged sword - whilst its viral nature is motivated by the idea of keeping free software free, its viral nature also makes it the license of choice for a commercial company wanting to open source its software whilst preserving its exclusive ability to make money from that software. The owner of GPL'ed code is still free to make the software available under other licenses (e.g. paid for licenses) if they wish, but the viral nature of GPL means they can prevent anyone else making money from derivatives apart from by special arrangement (e.g. paying royalties)! Matthew _________________________________________________________________ Be a superhero and win! Play the Iron Man Mashup Game http://www.ironmanmashup.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080423/aabe6602/attachment.htm From tateru.nino at gmail.com Wed Apr 23 01:19:53 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 23 01:25:06 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <398B694B-FF42-4B67-B5C4-CC8DDE9A6C44@gmail.com> <77be04730804220936g1db9c6d0ud5bcd1eedc557b01@mail.gmail.com> <8521F973-CF06-4A79-8FE1-4975EB8F2BAC@gmail.com> Message-ID: <480EF129.8000709@gmail.com> This is really great stuff! Where's the mailing list where we talk about development, architecture and code? :) From soft at lindenlab.com Wed Apr 23 04:26:24 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 23 04:26:28 2008 Subject: [sldev] Grid redundancy in face of disaster (Re: Navigations andLandmark Project) In-Reply-To: References: Message-ID: On Tue, Apr 22, 2008 at 10:51 AM, Dale Mahalko wrote: > > but right now I > believe moving sims to run on different servers is a manual process > (recall the recent address move project that took a few days). Any simulator (machine) on the simulator VPN, with the correct certificates, and with the correct simulator binary can bring up any region (island/"sim"). Pragmatically, we limit machines to specific data centers. This is done because adjacent regions chatter back and forth considerably and there's no sense in sending that traffic across the country. But 2 seconds in a web tool and you can change the home colo for a thousand regions. But within a datacenter, regions can and do migrate between simulators when simulators fail or if a region repeatedly crashes on the same simulator. The address move project that I believe you're thinking about was for changing simulators' IP addresses. That's a bit more touchy. From soft at lindenlab.com Wed Apr 23 04:39:39 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 23 04:39:41 2008 Subject: [sldev] A forum In-Reply-To: References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> Message-ID: On Tue, Apr 22, 2008 at 6:58 PM, Paul Cook wrote: > > A new topic. > > I find myself wondering why this mailing list exists. It contains a lot of > useful information and helpful people, but I mean, why does it exist as a > mailing list? I've got one mailbox, and I subscribe to 40+ lists - thankfully I can check all those in one place instead of hitting multiple forums manually. Using keyboard navigation, I can quickly scan through messages, with most demanding less than one second's attention. I've got the ability to mute further traffic on subjects I don't need to follow. I can easily search for messages on a subject across the many lists where discussion may happen. All of the above go away if we switch to a web forum or a newsgroup. It would be much better to use a threaded mail reader, as others suggest. From secret.argent at gmail.com Wed Apr 23 04:41:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 23 04:41:56 2008 Subject: Contribution agreements (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <1208931190.5050.8.camel@localhost> References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <1208931190.5050.8.camel@localhost> Message-ID: <4705EC8E-DB29-4BC2-9B2E-03A3C03F6473@gmail.com> On 2008-04-23, at 01:13, Callum Lerwick wrote: > People love to constantly vilify RMS as some kind of radical > extremist. > But every time I actually read his words he seems like a pretty sane > reasonable guy to me. People spend too much time listening to his > followers and critics, and not enough time listening to RMS himself. Does listening to him in person count? How about talking to him? How does spamming him with carbon-copies of messages to a mailing list fit in? From anthonyrbundy at gmail.com Wed Apr 23 06:08:31 2008 From: anthonyrbundy at gmail.com (Tony) Date: Wed Apr 23 06:08:36 2008 Subject: [sldev] A forum In-Reply-To: <480ED6FB.3020801@gmail.com> References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> <480ED6FB.3020801@gmail.com> Message-ID: <480F34CF.5090507@gmail.com> I agree that this can become a pretty heated issue pretty quickly. I'm not 100% sure that we can't have both worlds, at least to some degree as many forums have capabilities to be monitored and have new posts sent out similar to email lists. Personally, I would prefer the forums with notifications of some sort because I'd prefer not to store all the messages locally. Thunderbird now pauses for a moment before opening my SLDEV folder, even though I limit it to the last 60 days. The mailing list has archives, but responses don't always get put in the same thread all together. This adds to the complexity when someone new to the list wants to search for an answer to something. That answer may be spread out across several days in the archive. Forums tend to have the threads organized much better. Would it be possible to either create a forum that sends new posts out to the mailing list (but keeps threads organized the way forums usually do), or have the mailing list archive message in a forum like fashion? This would seem to make everybody happy so those that want to be informed immediately can, and those that just want to browse topics periodically (without having to subscribe, can...). Tony Robin Cornelius wrote: > Paul Cook wrote: > >> A new topic. >> >> I find myself wondering why this mailing list exists. It contains a lot >> of useful information and helpful people, but I mean, why does it exist >> as a mailing list? >> > > This is the stuff of flame wars ;-) some people just prefer mailing > lists and find them easier to deal with. I am one of those people. > > >> It's not exactly optimal to have to read through discussions you're not >> interested in, in a linear monolithic manner. It also has the problem of >> spamming up my inbox, even when in digest mode. And aside from that, we >> get random ads from microsoft in our mails from hotmail adresses. >> > > I use thunderbird on my linux and windows boxes and it is perfectly > capable of threading the message display so its very clear what the > topic thread is. Only issue is if someone replies and changes the topic > then it ends up out of thread. I get mails from some 10+ high volume > lists, they all go into there own folders away from inbox and are all > nicely threaded for me to see. > > >> Given that the official SL forums are being overhauled, I'd like to >> suggest that this mailing list would work better as a subforum within >> the LL forums, perhaps. >> > > I would polity request not to do this. > > >> The forum/bulletin board structure has a lot of advantages over a single >> monolithic list like this, making it easy to keep up with particular >> topics and ignore those one isn't interested in, and not have a crammed >> full inbox every day. >> > > Mail filters and threaded display in your mail client? > > Robin > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Wed Apr 23 06:40:11 2008 From: soft at lindenlab.com (Soft) Date: Wed Apr 23 06:40:14 2008 Subject: [sldev] Open Source Meeting call for items - Thursday 2pm Message-ID: The usual deal! We meet in Hippotropolis on Thursdays. If there's something you'd like discussed, please add it to the agenda: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From open at autistici.org Wed Apr 23 07:48:30 2008 From: open at autistici.org (Opensource Obscure) Date: Wed Apr 23 07:48:33 2008 Subject: [sldev] A forum In-Reply-To: <480F34CF.5090507@gmail.com> References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> <480ED6FB.3020801@gmail.com> <480F34CF.5090507@gmail.com> Message-ID: <6022449f775d8afc7e1a040c9fe5c5fa@localhost> On Wed, 23 Apr 2008 06:08:31 -0700, Tony wrote: > I agree that this can become a pretty heated issue pretty quickly. I don't think that our discussion about it would change anything, though. By the way, a couple of other advantages of mailing lists against (LL) forums: - everybody can read this mailing list (LL forums are restricted to pre-August-2006-users and users with Payment Info on File) - discussions can be found using web search engines - you can set filters so that messages coming from known trolls or people you can't stand (or even boring threads) get automatically deleted > Personally, I would prefer the forums with notifications of some sort > because I'd prefer not to store all the messages locally. Thunderbird > now pauses for a moment before opening my SLDEV folder, even though I > limit it to the last 60 days. Sorry for going offtopic and saying something you (probably) already know, however .. if you use Thunderbird, compact your folders - or your 'deleted' messages won't never really get deleted from your hard disk (so that those pauses in the application will persist and will keep growing): http://kb.mozillazine.org/Compacting_folders Opensource Obscure http://friendfeed.com/oobscure From josh at lindenlab.com Wed Apr 23 09:13:13 2008 From: josh at lindenlab.com (Joshua Bell) Date: Wed Apr 23 09:13:19 2008 Subject: [sldev] Grid redundancy in face of disaster (Re: Navigations andLandmark Project) In-Reply-To: References: Message-ID: <480F6019.8010803@lindenlab.com> Soft wrote: > Any simulator (machine) on the simulator VPN, with the correct > certificates, and with the correct simulator binary can bring up any > region (island/"sim"). Modulo different hardware classes (and simulator-to-CPU ratio), as Jason pointed out in a fork of this thread. That's also easily tweaked in our management tool, but pricing for the host capabilities (i.e. Quality of Service) comes into it. > Pragmatically, we limit machines to specific > data centers. This is done because adjacent regions chatter back and > forth considerably and there's no sense in sending that traffic across > the country. > Specifically, it makes region crossings much less prone to rubber-banding since the handoff is faster. > The address move project that I believe you're thinking about was for > changing simulators' IP addresses. That's a bit more touchy The reason this was problematic was that prior to 1.21 Server (which we'll deploy some day, I swear...) the way that this redundancy worked is that sim hosts running simulators that weren't hosting regions would poll the central database asking "got anything for me to run?" - we call these "spares". Too many spares and you have too many machines polling the database. Too few spares (or too infrequent polling) and you don't have enough reserve capacity to handle the demand when you shut down a few hundred sim hosts for maintenance work. The 1.21 Server update replaces this polling with a service based around an HTTP "long poll", so we can in theory have an arbitrary number of spares, and the glorious future of "half the grid dies, but the grid just routes around the problem" has arrived. Turning this service on will be done slowly with lots of monitoring and will happen after the 1.21 rollout itself, to avoid fireworks. Joshua From robin.cornelius at gmail.com Wed Apr 23 09:40:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 23 09:40:38 2008 Subject: [sldev] [VWR] cmake-8 troubles Message-ID: Hi Everyone, Still seem to be having a few issues with cmake-8, wonder if anyone else is seeing the same or is it just me *again* Working on a windows system with visual studio 2003.net ATM, i have had this for a few weeks and its still present in the SVN checked out a few hours ago. * VWR-6370 - bison.bat seems to be called in visual studio project file but does not exist * VWR-6794 - cmake.py seems to be calling a tool called tools\vstool\vstool.exe, which i can't find the project files seem ok though. * VWR-6233 - glh/glh_linear.h still missing from cmake tree (not in svn or libs packages) and now i can't find the correct glh_linear.h. I did have one that worked, but it seems the one from the 1.19.1 branch is too old. I *think* the one in 1.20.X is ok but don't have that to hand anyway, i do know this part builds ok if you can find the correct header. There are a few other misc issues under VWR-2871's sub tasks too. * VWR-6369 - libexpatMT.lib missing (required for windows crash logger) not in libs package. * VWR-6372 - quicktime headers not found (windows)(cmake-8) actually a feature request. The Quicktime SDK installs its self in c:\Program Files\Quicktime SDK\ To save the builder the haste of copying headers around which is messy, let cmake search the default QuickTime SDK path (patch attached, or in line actualy on the comments as its so trival) and a linux issue :- * VWR-6330 Cmake: prebuilt libraries missing xmlrpc-epi.so can't currently confirm this one,as its not one of mine but it was an issue very recently. Thanks for any help here! Robin From qarl at lindenlab.com Wed Apr 23 09:43:23 2008 From: qarl at lindenlab.com (Karl Stiefvater) Date: Wed Apr 23 09:43:54 2008 Subject: (Re: [sldev] What is the point of firstlook and giving feedback to LL) In-Reply-To: <20080423114155.4B24E41B29B@stupor.lindenlab.com> References: <20080423114155.4B24E41B29B@stupor.lindenlab.com> Message-ID: On Apr 23, 2008, at 4:41 AM, Tateru Nino wrote: > This is really great stuff! Where's the mailing list where we talk > about > development, architecture and code? :) hear hear! i propose the creation of a new list, "sldev-politics" for the discussion of all these meta-issues, and allow sldev to return to mere code. or, perhaps we leave the politics in "sldev" and we create "sldev-dev" for code talk? :) K. From bos at lindenlab.com Wed Apr 23 10:46:57 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Apr 23 10:47:00 2008 Subject: [sldev] [VWR] cmake-8 troubles In-Reply-To: References: Message-ID: <480F7611.3060207@lindenlab.com> Robin Cornelius wrote: > Still seem to be having a few issues with cmake-8, wonder if anyone > else is seeing the same or is it just me *again* Thanks for bringing these up here. If you're filing cmake bugs, it might be a good idea to assign them to me or Soft right now, to make sure we see them. I didn't know about any of these, unfortunately, because I'm too lame to check the public JIRA. It looks like they are all simply oversights. We'll fix 'em up within the next few days. References: <781e4b420804081908p2abeb0b5u87e8de41288e03c1@mail.gmail.com> <47FC6B7F.2030803@gmail.com> <20080410172044.5cb31e9b.sldev@free.fr> <20080410203552.22e899b0.sldev@free.fr> <480A1F12.5060004@lindenlab.com> <20080421213235.0bf03195.sldev@free.fr> <480D342C.6060203@lindenlab.com> <480D3929.3070505@lindenlab.com> <77be04730804211822v22c52fa5sa872a35eb95dd2ae@mail.gmail.com> <480D704F.6040308@lindenlab.com> <1208931190.5050.8.camel@localhost> <4705EC8E-DB29-4BC2-9B2E-03A3C03F6473@gmail.com> Message-ID: <480F76C6.8000701@lindenlab.com> Argent Stonecutter wrote: > On 2008-04-23, at 01:13, Callum Lerwick wrote: >> People love to constantly vilify RMS as some kind of radical extremist. >> But every time I actually read his words he seems like a pretty sane >> reasonable guy to me. People spend too much time listening to his >> followers and critics, and not enough time listening to RMS himself. > > Does listening to him in person count? > > How about talking to him? > > How does spamming him with carbon-copies of messages to a mailing list > fit in? > Can we keep our e-peens in check please? Everyone on the internet has a doctorate in and has tea with the every Tuesday afternoon, and has on speed dial. It doesn't matter if it is true or not, no one can verify it and it just really, really, really doesn't matter. We are here to discuss ideas and code - and to evaluate, judge and vilify those ideas on the merits of the actual ideas - not on the e-peens of those writing the ideas. Thanks, - Kelly From steve at lindenlab.com Wed Apr 23 12:29:21 2008 From: steve at lindenlab.com (Steve) Date: Wed Apr 23 12:29:55 2008 Subject: [sldev] Viewer Roadmap Message-ID: <480F8E11.5030706@lindenlab.com> *Hello everyone.* This is Steve Linden. I am a studio director at Linden Lab, focused on development of the Second Life Viewer. I don't post here very often -- not because I don't value the input and contributions of the open source community, but simply because we have a lot to do, and *good* communication takes time, lots of time. However, I want to at least do a better job of communicating what we are currently working on in the Viewer and why. Starting this quarter, we will be regularly updating the Viewer Roadmap public wiki page, posting here with a summary, and answering any questions that come up. *Viewer Roadmap* This quarter, we are focusing our efforts on four things: 1. Stability of the client: Viewer Stability 2. Small changes to improve the experience of new residents 3. Notifications and Skinning 4. Texture Pipeline Improvements The project pages linked above describe the objectives and priority of the respective projects. Briefly, we are primarily focused on stability, while making time for improving some other key pieces of our system. As the Roadmap Diagram illustrates, all of these projects work towards two primary goals: 1. Make the Viewer more *stable* 2. Make the Viewer more *usable* *FAQ* I realize that everyone has a different perspective and many will wonder why we are not working on certain features that are important to some or many of our residents. Let me attempt to address a couple of likely questions here: Q: What about "Feature X"? A: We have been very feature focused in our development for a while now. As anyone who has spent a lot of time looking through our code will know, much of our code base is poorly structured and difficult to maintain. And as every resident of SL knows, the client suffers from crashes and memory leaks. Improving stability requires a lot of resources. So, for a little while, we are keeping feature development down to a minimum. Q: What about fixing bugs? A: We will continue to address bugs as they come up and prioritize them as usual. Critical bugs will be fixed and others will be evaluated and addressed as we can get to them. Much of this effort is done during the Release Candidate process, and many of the bugs come from the public Jira issue tracker, so any contribution to that process helps us considerably. Q: What about resident provided changes? A: These are always tricky. Writing code to solve a problem is only a small percentage of the work required to introduce a feature or change existing behavior. Broad design issues need to be considered; the code needs to be checked for vulnerabilities and edge cases; the changes need to be tested; and invariably, bugs associated with the change need to be fixed. Outside of straightforward bug fixes, we are unlikely in the near term to integrate external changes, just as we are keeping new features to a minimum internally this quarter. Q: What will we work on in Q3, Q4, and beyond? A: Right now we are proceeding cautiously when looking past the end of Q2. As we make progress on projects in Q2, we will start to put together a project list for Q3 and expect to have a Q3 roadmap available before the end of Q2. *"Dazzle" and Skinning* There has been some amount of feedback regarding the release of the Dazzle UI changes before we release "Skinning Phase 1 " (which will allow residents to install custom skins and switch between them, e.g. switch to a "classic" skin). This was an internal decision based primarily on the desire not to try to support more than one official skin. We plan to release Skinning Phase 1 before we make 1.20 mandatory (hopefully well before-- we are trying to keep mandatory updates to a minimum), so we will support switching skins before imposing this release on everyone. However, this is the look we are planning to support going forward. That being said, because the majority of the objections to the new look appear to be contrast and color scheme issues, we are going to immediately prioritize a project to provide an in-client interface for modification of custom colors and maintenance of these customizations across updates, just like we do for other settings. *More Questions? *I will do my best to answer any direct questions, but it's a busy start to the quarter! I'd like to focus my available time, so please put specific *feature* discussions on a different thread, thanks! In particular, let's continue any Dazzle related discussions on another thread -- other than trying to be very transparent with the roadmap I can't offer much more on that subject and will defer additional comments on that topic to others. -Steve Director of Studio Shiny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080423/645b57b9/attachment.htm From anthonyrbundy at gmail.com Wed Apr 23 16:46:37 2008 From: anthonyrbundy at gmail.com (Tony) Date: Wed Apr 23 16:46:40 2008 Subject: [sldev] A forum In-Reply-To: <6022449f775d8afc7e1a040c9fe5c5fa@localhost> References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> <480ED6FB.3020801@gmail.com> <480F34CF.5090507@gmail.com> <6022449f775d8afc7e1a040c9fe5c5fa@localhost> Message-ID: <480FCA5D.7010507@gmail.com> Opensource Obscure wrote: > On Wed, 23 Apr 2008 06:08:31 -0700, Tony wrote: > > >> I agree that this can become a pretty heated issue pretty quickly. >> > > > > I don't think that our discussion about it would change anything, though. > > > > By the way, a couple of other advantages of mailing > > lists against (LL) forums: > > - everybody can read this mailing list (LL forums are restricted > > to pre-August-2006-users and users with Payment Info on File) > A forum could be used that doesn't have this requirement. Many forums don't require logging in to read. > - discussions can be found using web search engines > Forums can be searched to (maybe not the current LL ones, but that doesn't mean the best answer is to use the existing forums > - you can set filters so that messages coming from known trolls > or people you can't stand (or even boring threads) get automatically > > deleted > I believe this can be done for forums and other formats. I know of a greasemonkey script used to block someone's JIRA comments that were becoming distracting. > > > > > >> Personally, I would prefer the forums with notifications of some sort >> > > >> because I'd prefer not to store all the messages locally. Thunderbird >> > > >> now pauses for a moment before opening my SLDEV folder, even though I >> > > >> limit it to the last 60 days. >> > > > > Sorry for going offtopic and saying something you (probably) > > already know, however .. if you use Thunderbird, compact > > your folders - or your 'deleted' messages won't never really > > get deleted from your hard disk (so that those pauses in the > > application will persist and will keep growing): > > http://kb.mozillazine.org/Compacting_folders > > Thank you for this tip, I didn't know this. > > > > Opensource Obscure > > http://friendfeed.com/oobscure > > > Mostly my point was that I think that maybe there is a way to get the things that everyone likes about both options in a single package. For instance, this topic has come up many times before, and the initial poster could have continued or may have seen the previous thread (or this thread could be merged into an existing thread) if we weren't limited to the current method. I was not suggesting that the list go back to the LL current forum. If everyone's experience is improved, and productivity would be better, why not try a new option. From stephany at lindenlab.com Wed Apr 23 20:28:57 2008 From: stephany at lindenlab.com (Stephany Filimon) Date: Wed Apr 23 20:29:06 2008 Subject: [sldev] Landmarks and Navigation Project Update 2008-04-23 Message-ID: <480FFE79.8060102@lindenlab.com> As promised, this week's project update, which consists of: * Call for participation: Tomorrow's office hour at 3 PM Pacific in Beaumont * Summary of the past week's activities * This week's plans *Call for Participation* Tomorrow - Thursday, April 24 at 3 PM (Pacific), in Beaumont - we'll hold our second office hour focused on navigation and landmarks. We've received very valuable, creative, and thoughtful feedback from you so far (some of which Vectorform will share at tomorrow's meeting) and would love more of it. *Past Week: We're deep in our research phase. ** Last Wednesday, the project team (see http://www.vectorform.com/secondlife/ if you haven't met them yet) held an extended office hour (from 2-4 PM Pacific) to gather feedback on landmarks and navigation. The early start time was due to an email miscommunication on my part, but we did at least obtain two hours worth of feedback instead of one. * The project team is currently in the process of reading, culling, and analyzing the wealth of information gathered so far. Common themes and patterns are starting to emerge; we hope to have more detail on this for you in next week's update. * We're also assessing the feasibility of many of the specific suggestions we've received. * The team is looking at the many existing, resident-created HUDs that aid navigation in SL, to see which ones might be helpful to this project and possibly incorporated. * The project team has read every message added to this thread on SLDEV. We've added your email feedback to the office hour and PJIRA information we've collected, so please be assured that it is in, and will continue to be added to, the growing user-feedback-and-research pool. * The project team has also reviewed existing LL internal research on account abandonment and general "reasons for leaving SL" that are relevant to this project. *This Week: More research and wireframes.* * We'll hold one more office hour for feedback... * At which Vectorform will share some findings so far and gather more feedback. * Residents who have expressed explicit interest in research participation may be contacted about participating in survey-based or other research. Vectorform will begin to create wireframes based on all of the above. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080423/e2a2e76a/attachment.htm From kfa at gmx.net Wed Apr 23 23:30:46 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 23 23:30:51 2008 Subject: [sldev] A forum In-Reply-To: <6022449f775d8afc7e1a040c9fe5c5fa@localhost> References: <20080422190024.D04AA41B3C3@stupor.lindenlab.com> <480ED6FB.3020801@gmail.com> <480F34CF.5090507@gmail.com> <6022449f775d8afc7e1a040c9fe5c5fa@localhost> Message-ID: <48102916.1070000@gmx.net> There certainly are pros and cons for both list and forum, but I'd also agree that the mailing list format has more advantages than disadvantages in this case. Searching for things is really a lot easier that way. Mostly I don't even use the threaded view (takes slightly longer to display), I just use the ad hoc filter ('Subject or Sender contains...'). I also archive my messages in one subfolder per month to keep file size manageable. Thunderbird (or SeaMonkey which I use) offers compression as well. And replies are faster because you get it shoved into your face and must make a decision to dismiss or write back, but I can see that this appears to be a stress factor for some. But one thing that would speak for keeping a forum, too, or possibly a separate list: Where do you ask for help with fundamental things, those really noobish questions? Apart from support with getting the thing to compile, sldev doesn't appear to be the proper place for this. Of course there are plenty of public forums not tied to this project where you could ask for help e.g. when hassling with getting a call-by-reference right that keeps giving errors... stuff that happens when you've been with other OO languages for too long ;). Should we have a place within the SL community for that or does the majority feel it would be redundant? Felix Opensource Obscure wrote: > On Wed, 23 Apr 2008 06:08:31 -0700, Tony wrote: > >> I agree that this can become a pretty heated issue pretty quickly. >> > > I don't think that our discussion about it would change anything, though. > > By the way, a couple of other advantages of mailing > lists against (LL) forums: > - everybody can read this mailing list (LL forums are restricted > to pre-August-2006-users and users with Payment Info on File) > - discussions can be found using web search engines > - you can set filters so that messages coming from known trolls > or people you can't stand (or even boring threads) get automatically > deleted > > > >> Personally, I would prefer the forums with notifications of some sort >> because I'd prefer not to store all the messages locally. Thunderbird >> now pauses for a moment before opening my SLDEV folder, even though I >> limit it to the last 60 days. >> > > Sorry for going offtopic and saying something you (probably) > already know, however .. if you use Thunderbird, compact > your folders - or your 'deleted' messages won't never really > get deleted from your hard disk (so that those pauses in the > application will persist and will keep growing): > http://kb.mozillazine.org/Compacting_folders > > > Opensource Obscure > http://friendfeed.com/oobscure > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From matthew.dowd at hotmail.co.uk Thu Apr 24 02:11:56 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 24 02:11:58 2008 Subject: Dazzle comments (was RE: [sldev] Viewer Roadmap) In-Reply-To: <480F8E11.5030706@lindenlab.com> References: <480F8E11.5030706@lindenlab.com> Message-ID: Thanks for the roadmap. but (presuming the roadmap was sent out for comment/feedback not just for information)... "Dazzle" and SkinningThere has been some amount of feedback regarding the release of the Dazzle UI changes before we release "Skinning Phase 1" (which will allow residents to install custom skins and switch between them, e.g. switch to a "classic" skin). This was an internal decision based primarily on the desire not to try to support more than one official skin. As many have indicated this was a predictable (and predicted) PR disaster - the result is that Dazzle now has strong negative connotations which will be particularly difficult to shift - particularly if LL proceed by just minor tweaks rather than a proper rethink initiated by the feedback, as this will just perpetuate the feelings that LL do not take notice of users comments. Having now written a patch to enable skin switching, I was struck that most of the foundation code - particularly in handling fallbacks to defaults - is already there. The actual code to load a designated skin is only a few dozen lines of added/modded code - the rest (and bulk) of the patch is to add a UI panel to preferences to allow the user to change the setting. Whilst I can understand the motivation to only support one skin, this doesn't reflect the user demand. I think you will need to support a minimum of two skins due to one simple reason - a well designed dark skin will not be harsh on the eyes whether you are using SL in a brightly lit room or a dimly lit room; however a bright skin, even well designed, will always seem harsh on the eyes in a dimly lit room (and your userbase will be working in both). Whilst you could get away with a single skin if you went with the dark one (e.g. the current one), going for a bright one, does force you into also supporting a dark one. That being said, because the majority of the objections to the new look appear to be contrast and color scheme issues, we are going to immediately prioritize a project to provide an in-client interface for modification of custom colors and maintenance of these customizations across updates, just like we do for other settings. This feels like sticking plaster over a problem rather than addressing the problem directly - also if this customization does not change the colours in textures (such as buttons, icons, etc.) its effectiveness will be limited. The current palette underlying the Dazzle scheme is fundamentally flawed (see Aimee's comments in the jira issue), and it really needs a redesign not a few tweaks. Moreover, you shouldn't be expecting a large proportion of your users to have to customise the colours before they being to use SL just to make the default UI usable - this is hardly going to help new signup retention. Matthew _________________________________________________________________ Search and win with BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080424/669e6044/attachment.htm From matthew.dowd at hotmail.co.uk Thu Apr 24 02:16:32 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 24 02:16:35 2008 Subject: [sldev] [VWR] cmake-8 troubles In-Reply-To: <480F7611.3060207@lindenlab.com> References: <480F7611.3060207@lindenlab.com> Message-ID: > I didn't know about any of these, unfortunately,> because I'm too lame to check the public JIRA. Mmmmm, I don't want to single Bryan out (essentially for being honest!!!), but I find it a little disturbing that the people working on things in LL, don't know about related bugs/issues being reported, commented (and possibly even patched) in PJIRA as a matter of course! Matthe _________________________________________________________________ Play the Andrex Hello Softie Game & win great prizes http://www.thehellosoftiegame.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080424/568ee59f/attachment.htm From kfa at gmx.net Thu Apr 24 03:20:17 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Thu Apr 24 03:20:27 2008 Subject: Refactoring UI, Skinning, Translating - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> Message-ID: <48105EE1.6050304@gmx.net> IMHO the xml files are in dire need of refactoring. Should we not do this: In the XUI files, separate the structure from the skin. Only colors, text labels, border styles etc. go into the skin overlay. Even that could again be separated into a style pack and a language pack only containing the labels and tooltips. All info necessary to display a widget, its elements and their positioning, are essential for the program to function at all. In the current state, it's a nightmare to maintain if you have to adapt all available skins whenever you want to change or extend some GUI functionality. While you could say that the current files simply contain everything to have a default to fall back on for all elements that a skin or language pack doesn't contain, it would be a great asset for future skinning or translation efforts if we had that separated also in the en-us default version along with the source/release distribution. Then you'd just take the package with the parts you want to work on and edit away. As it is, you have to manually (or with a programmatic tool) eliminate all the info you don't need i.o. to create an overlay. Am I overlooking some info that a similar plan already exists, either on the JIRA or elsewhere? Felix Kent Quirk (Q Linden) wrote: > [...] > To tie in the other discussion going on right now, we're fully aware > that the viewer isn't as modular as anyone would like, and that > there's too much coupling between the various pieces. Some of us are > working very hard on taking some of that apart right now. I, for > example, am one of three developers who have been working on > refactoring the notifications and alerts systems, with the help of our > UI team and some excellent feedback I got earlier from this list. > > We're also doing a lot of work toward making the viewer more and more > data-driven. For example, the Notifications system is quite a bit more > flexible now, because we're adding capabilities to the XML file we use > for localization. > [...] > Q > From gwardell at gwsystems.co.il Thu Apr 24 06:17:14 2008 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Thu Apr 24 06:17:25 2008 Subject: [sldev] A forum In-Reply-To: <48102916.1070000@gmx.net> Message-ID: <000201c8a60d$841b33a0$a400000a@gwsystems2.com> Hmm, It seems that some people have forgotten that the list is archived online, here: https://lists.secondlife.com/pipermail/sldev/. For example you can find this thread here at the bottom of the page https://lists.secondlife.com/pipermail/sldev/2008-April/thread.html You will also note this thread was a reply to another thread. So it looks like we already have the best of both worlds (threaded view, subject view, author view, date view, archived online, searchable, publicly accessible, and you can download the archive), except that you can only post via your mail reader. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Felix > Duesenburg > Sent: Thu, April 24, 2008 2:31 AM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] A forum > > > There certainly are pros and cons for both list and forum, > but I'd also > agree that the mailing list format has more advantages than > disadvantages in this case. Searching for things is really a > lot easier > that way. Mostly I don't even use the threaded view (takes slightly > longer to display), I just use the ad hoc filter ('Subject or Sender > contains...'). I also archive my messages in one subfolder > per month to > keep file size manageable. Thunderbird (or SeaMonkey which I > use) offers > compression as well. And replies are faster because you get it shoved > into your face and must make a decision to dismiss or write > back, but I > can see that this appears to be a stress factor for some. > > But one thing that would speak for keeping a forum, too, or > possibly a > separate list: Where do you ask for help with fundamental > things, those > really noobish questions? Apart from support with getting the > thing to > compile, sldev doesn't appear to be the proper place for > this. Of course > there are plenty of public forums not tied to this project where you > could ask for help e.g. when hassling with getting a > call-by-reference > right that keeps giving errors... stuff that happens when you've been > with other OO languages for too long ;). Should we have a > place within > the SL community for that or does the majority feel it would > be redundant? > > Felix > > > From brad at lindenlab.com Thu Apr 24 11:08:18 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Thu Apr 24 11:06:27 2008 Subject: Dazzle comments (was RE: [sldev] Viewer Roadmap) In-Reply-To: References: <480F8E11.5030706@lindenlab.com> Message-ID: <4810CC92.7060808@lindenlab.com> Matthew Dowd wrote: > > This feels like sticking plaster over a problem rather than addressing > the problem directly - also if this customization does not change the > colours in textures (such as buttons, icons, etc.) its effectiveness > will be limited. The current palette underlying the Dazzle scheme is > fundamentally flawed (see Aimee's comments in the jira issue), and it > really needs a redesign not a few tweaks. Moreover, you shouldn't be > expecting a large proportion of your users to have to customise the > colours before they being to use SL just to make the default UI usable > - this is hardly going to help new signup retention. > The skinning team is addressing the problem directly as Steve said with Skinning Phase 1 . But it's not gonna be released soon enough for a lot of people so this "plaster" as you call it is a compromise in an attempt to respond in some way to that feedback and get something to those people quickly. Again, the major effort with a project such as skinning is not necessarily the code itself, but producing something that's maintainable, testable, and well documented. It's better to take such things slow to reduce the risk of introducing bugs in other parts of the system, or design flaws that limit our forward compatibility. In the end it probably won't take a whole lot of code to implement user switchable skins, but we have to do it precisely right because we don't want to just release a shortsighted implementation that will end up with users skins getting broken 3 releases later. -Brad From seg at haxxed.com Thu Apr 24 11:18:24 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu Apr 24 11:18:32 2008 Subject: Refactoring UI, Skinning, Translating - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <48105EE1.6050304@gmx.net> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <48105EE1.6050304@gmx.net> Message-ID: <1209061104.5050.58.camel@localhost> On Thu, 2008-04-24 at 06:20 -0400, Felix Duesenburg wrote: > IMHO the xml files are in dire need of refactoring. Should we not do this: > > In the XUI files, separate the structure from the skin. Only colors, > text labels, border styles etc. go into the skin overlay. Even that > could again be separated into a style pack and a language pack only > containing the labels and tooltips. Can you say... CSS? Maybe LL should take a look at HippoCanvas: http://developer.mugshot.org/wiki/Hippo_Canvas (C'mon, the name... it's a sign.) Which apparently recently gained CSS based theming: http://groups.google.com/group/mugshot/browse_thread/thread/73ba19bdd8f2f993 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080424/ffadc293/attachment.pgp From matthew.dowd at hotmail.co.uk Thu Apr 24 12:01:53 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 24 12:01:55 2008 Subject: Dazzle comments (was RE: [sldev] Viewer Roadmap) In-Reply-To: <4810CC92.7060808@lindenlab.com> References: <480F8E11.5030706@lindenlab.com> <4810CC92.7060808@lindenlab.com> Message-ID: > The skinning team is addressing the problem directly as Steve said with > Skinning Phase 1 . > But it's not gonna be released soon enough for a lot of people so this > "plaster" as you call it is a compromise in an attempt to respond in > some way to that feedback and get something to those people quickly. But if you hold off introducing a new colour scheme until after phase 1, then you *don't* need to respond to those people quickly: you don't need to rush out some sticky plaster! > It's better to take such > things slow to reduce the risk of introducing bugs in other parts of the > system, or design flaws that limit our forward compatibility. In the > end it probably won't take a whole lot of code to implement user > switchable skins, (it doesn't - I've had a go ;-) ) > but we have to do it precisely right because we don't > want to just release a shortsighted implementation that will end up with > users skins getting broken 3 releases later. These are almost precisely the same arguments why you shouldn't rush out with a short-sighted (no pun intended) re-skinning which will cause more problems, and require quick interim measures and tweaks to compensate over the next 2 or 3 releases! The underlying Dazzle code is fine (well there are still some problems in 1.20RC3 but that might not be related to the Dazzle code per se - a lot of the problems seem to be related to using boost to handle configuration setting); the Dazzle skin as a test of the new Dazzle functionality is fine; but the Dazzle skin is nowhere near ready for use in a release viewer yet - that's the overwhelming feedback from jira, blog comments and forums... Matthew _________________________________________________________________ 100?s of prizes to be won at BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080424/8c3371bc/attachment.htm From matthew.dowd at hotmail.co.uk Thu Apr 24 12:23:01 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Thu Apr 24 12:23:03 2008 Subject: Dazzle comments (was RE: [sldev] Viewer Roadmap) In-Reply-To: <4810CC92.7060808@lindenlab.com> References: <480F8E11.5030706@lindenlab.com> <4810CC92.7060808@lindenlab.com> Message-ID: > we have to do it precisely right because we don't > want to just release a shortsighted implementation that will end up with > users skins getting broken 3 releases later. Isn't this going to happen anyway - people are releasing use skins now - driven by the problems inherent in the Dazzle skin. The problems in Dazzle go beyond just the colours - hence these skins include new UI textures and even modified XUI files. As the XUI format is being revised as part of the Dazzle roadmap (and also see the other discussion thread on this list), it is very likely that the skins being created now will be broken by further work in the Dazzle roadmap (by the XUI changes if not by other things planned in the Dazzle roadmap) regardless of whether you implement skin switching now or later. Matthew _________________________________________________________________ Bag extra points with the Walkers Brit Trip Game http://www.walkersbrittrips.co.uk/game -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080424/2a1378a1/attachment.htm From kwerks.sl at gmail.com Thu Apr 24 14:47:21 2008 From: kwerks.sl at gmail.com (JB Kraft) Date: Thu Apr 24 14:47:25 2008 Subject: Dazzle comments (was RE: [sldev] Viewer Roadmap) In-Reply-To: References: <480F8E11.5030706@lindenlab.com> <4810CC92.7060808@lindenlab.com> Message-ID: <7b61e3970804241447g450d3de2q88ec590021f03bd4@mail.gmail.com> FWIW, the first thing I did when I saw dazzle, 1.20, was exit. The second thing I did was fire up gimp and make a dark skin. I would very much like to contribute to planning/implementing some method of making choosing skins from the client and a way of packaging them for distribution. Please contact me if there is any way I can help. I regret to say the current skin is completely unusable so I have to agree that that a mechanism for choosing skins should have come first before the client look was altered. However, here we are so if there is anyway I can help with planning, coding or implementing please do let me know. regards JB Kraft My dark skin is here if anyone is interested. I apologize for my mediocre gimp skills and would never have attempted such a feat were it not for finding the test client unusable. http://wiki.secondlife.com/wiki/Viewer_Skins/Dark_Skin http://kwerkslabs.com/skins On Thu, Apr 24, 2008 at 3:23 PM, Matthew Dowd wrote: > > we have to do it precisely right because we don't > > want to just release a shortsighted implementation that will end up with > > users skins getting broken 3 releases later. > > Isn't this going to happen anyway - people are releasing use skins now - > driven by the problems inherent in the Dazzle skin. The problems in Dazzle > go beyond just the colours - hence these skins include new UI textures and > even modified XUI files. As the XUI format is being revised as part of the > Dazzle roadmap (and also see the other discussion thread on this list), it > is very likely that the skins being created now will be broken by further > work in the Dazzle roadmap (by the XUI changes if not by other things > planned in the Dazzle roadmap) regardless of whether you implement skin > switching now or later. > > Matthew > > ------------------------------ > Get fish-slapping on Messenger Play Now > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080424/2b9413d6/attachment.htm From poppy at lindenlab.com Thu Apr 24 14:56:48 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Thu Apr 24 14:56:50 2008 Subject: [sldev] [VWR] cmake-8 troubles In-Reply-To: References: <480F7611.3060207@lindenlab.com> Message-ID: <48110220.6030806@lindenlab.com> Please assign me (mac) and sardonyx (linux, general) and mani (windows) as watchers in pjira for cmake issues. I can say that I respond to the watcher pings, but don't routinely sift through cmake issues (i do sometimes, but not often enough for good response times). + poppy Matthew Dowd wrote: > > I didn't know about any of these, unfortunately, > > because I'm too lame to check the public JIRA. > > Mmmmm, I don't want to single Bryan out (essentially for being > honest!!!), but I find it a little disturbing that the people working on > things in LL, don't know about related bugs/issues being reported, > commented (and possibly even patched) in PJIRA as a matter of course! > > Matthe > > ------------------------------------------------------------------------ > Get 5GB of online storage for free! Get it Now! > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From wuhanzymail at 163.com Thu Apr 24 17:45:27 2008 From: wuhanzymail at 163.com (wuhanzymail) Date: Thu Apr 24 17:45:32 2008 Subject: [sldev] Compile errors of SL viewer 1.20 in VS2005 Message-ID: <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> Hi, This is the first time I compile secondlife viewer using VS2005. I download source code of 1.20 (slviewer-src-Branch_1-20-Viewer-r85643) and try to compile them but get below errors: 1>------ Build started: Project: lscript_compile, Configuration: ReleaseNoOpt Win32 ------ 1>Compiling... 1>lex_yy.cpp 1>...\linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 1>Build log was saved at "...\linden\indra\lscript\lscript_compile\ReleaseNoOpt\BuildLog.htm" 1>lscript_compile - 1 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 1>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ 1>Compiling resources... 1>.\res\newViewRes.rc(66) : error RC2135 : file not found: icon1.ico 1>.\res\newViewRes.rc(224) : error RC2135 : file not found: toolplay.cur 1>.\res\newViewRes.rc(225) : error RC2135 : file not found: toolpause.cur 1>.\res\newViewRes.rc(226) : error RC2135 : file not found: toolmediaopen.cur 1>Build log was saved at "...\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" 1>newview - 4 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== 1>------ Build started: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ 1>Compiling... 1>llcrashloggerwindows.cpp 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss 1>.\llcrashloggerwindows.cpp(102) : error C2440: 'initializing' : cannot convert from 'llutf16string' to 'std::basic_string<_Elem,_Traits,_Ax>' 1> with 1> [ 1> _Elem=wchar_t, 1> _Traits=std::char_traits, 1> _Ax=std::allocator 1> ] 1> No constructor could take the source type, or constructor overload resolution was ambiguous 1>Build log was saved at "...\linden\indra\win_crash_logger\ReleaseNoOpt\BuildLog.htm" 1>win_crash_logger - 1 error(s), 2 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== I don't know what's the problems. Would you please give me some suggestions or solutions? I will appreciate for that. Thank you very much! Best Regards, Ying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080425/06ac74f2/attachment.htm From kfa at gmx.net Thu Apr 24 18:45:19 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Thu Apr 24 18:50:51 2008 Subject: Refactoring UI, Skinning, Translating - was: Re: [sldev] sljirastats.com Linden Metrics Report In-Reply-To: <1209061104.5050.58.camel@localhost> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <48105EE1.6050304@gmx.net> <1209061104.5050.58.camel@localhost> Message-ID: <481137AF.5080203@gmx.net> Callum Lerwick wrote: > On Thu, 2008-04-24 at 06:20 -0400, Felix Duesenburg wrote: >> IMHO the xml files are in dire need of refactoring. Should we not do this: >> >> In the XUI files, separate the structure from the skin. Only colors, >> text labels, border styles etc. go into the skin overlay. Even that >> could again be separated into a style pack and a language pack only >> containing the labels and tooltips. > > Can you say... CSS? > Very good... but will have to be implemented from scratch... Here's a little tool attached that I had lying around somewhere and could adapt. It rips the xui files apart and separates function, skin and language parts as suggested. It scans the skins/xui/en-us for all xml files that contain floaters, panels or menus. Then it filters by attributes, and distributes the elements into 3 different document trees. This is just quick fix, the filter may need some fine-tuning (in start_element in the handler package). The output is formatted in a patch-friendly format. The resulting folder structure is just a proposal, too: ./xui for the functional part, ./skins/default for the styles, and ./lang/en-us for the text. Simply place it in the source tree under the newview folder and run from the command line. (Sorry no Python, my mother tongue is Perl). It doesn't overwrite any existing files. Not sure if this makes sense to anybody, but at least it can create you a clean set of files for skinning or translation work. Cheers, Felix -------------- next part -------------- #!/usr/bin/perl use XML::Parser::PerlSAX; use File::Path; $handler = MyXMLHandler->new(); $parser = XML::Parser::PerlSAX->new(Handler => $handler); $lang = 'en-us'; mkpath(["./xui", "./skin/default", "./lang/$lang"], 1); $dir = "./skins/xui/$lang"; opendir(DIR, $dir) or die "can't opendir $dir: $!\n"; while (my $file = readdir(DIR)) { next unless $file =~ /\.xml$/; print "parsing $dir/$file\n"; $handler->set_outfiles("./xui/$file", "./skin/default/$file", "./lang/$lang/$file"); $parser->parse(Source => {SystemId => "$dir/$file"}); } closedir DIR; exit; package MyXMLHandler; use XML::DOM; use Data::Dumper; my ($root, $process, $level, $text); my ($xui_doc, $skin_doc, $lang_doc); my ($xui_n, $skin_n, $lang_n); my ($xui_file, $skin_file, $lang_file); my ($xui_node, $skin_node, $lang_node); my ($xui_parent, $skin_parent, $lang_parent); sub set_outfiles { my ($self, $f1, $f2, $f3) = @_; $xui_file = $f1; $skin_file = $f2; $lang_file = $f3; } sub new { my $type = shift; $filter = {}; return bless {}, $type; } sub start_document { my ($self) = @_; $level = 0; $xui_doc = XML::DOM::Document->new; $xui_n = 0; $skin_doc = XML::DOM::Document->new; $skin_n = 0; $lang_doc = XML::DOM::Document->new; $lang_n = 0; } sub start_element { my ($self, $element) = @_; my $tag = lc($element->{Name}); my $attrs = $element->{Attributes}; if ($level == 0) { $root = $tag; $process = ($root =~ /^(.*floater.*|.*panel.*|menu)$/); } if ($process) { $xui_parent = $level ? $xui_node : $xui_doc; $xui_node = $xui_doc->createElement($tag); $xui_parent->appendChild($xui_node); $skin_parent = $level ? $skin_node : $skin_doc; $skin_node = $skin_doc->createElement($tag); $skin_parent->appendChild($skin_node); $lang_parent = $level ? $lang_node : $lang_doc; $lang_node = $lang_doc->createElement($tag); $lang_parent->appendChild($lang_node); foreach my $attr (sort keys %$attrs) { if ($attr =~ /^(name)$/i) { $xui_node->setAttribute($attr, $attrs->{$attr}); $lang_node->setAttribute($attr, $attrs->{$attr}); $skin_node->setAttribute($attr, $attrs->{$attr}); } elsif ($attr =~ /^(label|tool_tip)$/i) { $lang_node->setAttribute($attr, $attrs->{$attr}); $lang_n++; } elsif ($attr =~ /^(.*style|.*color|border.*)$/i) { $skin_node->setAttribute($attr, $attrs->{$attr}); $skin_n++; } else { $xui_node->setAttribute($attr, $attrs->{$attr}); $xui_n++; } } $text =~ s/^\s+//s; $text =~ s/\s+$//s; if ($text ne '') { $lang_node->addText($text); $lang_n++; $text = ''; } } $level++; } sub characters { my ($self, $characters) = @_; if ($process) { $text .= $characters->{Data}; } } sub end_element { my ($self, $element) = @_; my $tag = lc($element->{Name}); $level--; if ($process) { $text =~ s/^\s+//s; $text =~ s/\s+$//s; if ($text ne '') { $lang_node->addText($text); $lang_n++; $text = ''; } $xui_node = $xui_parent; $xui_parent = $xui_parent->getParentNode() if $level > 0; $skin_node = $skin_parent; $skin_parent = $skin_parent->getParentNode() if $level > 0; $lang_node = $lang_parent; $lang_parent = $lang_parent->getParentNode() if $level > 0; } } sub end_document { my ($self) = @_; if ($process && $xui_n) { if (open FILE, ">$xui_file") { print "writing $xui_file\n"; traverse(FILE, $xui_doc); close FILE; } else { print "can't write to $xui_file: $!\n"; } } if ($process && $lang_n) { if (open FILE, ">$lang_file") { print "writing $lang_file\n"; traverse(FILE, $lang_doc); close FILE; } else { print "can't write to $lang_file: $!\n"; } } if ($process && $skin_n) { if (open FILE, ">$skin_file") { print "writing $skin_file\n"; traverse(FILE, $skin_doc); close FILE; } else { print "can't write to $skin_file: $!\n"; } } } sub traverse { my($fp, $node, $indent)= @_; my $ind = "\t" x $indent; my $inda = "$ind\t"; if ($node->getNodeType == DOCUMENT_NODE) { print $fp qq~\n~; foreach my $child ($node->getChildNodes) { traverse($fp, $child, 0); } } elsif ($node->getNodeType == ELEMENT_NODE) { my $name = $node->getNodeName; my $attrs = $node->getAttributes; print $fp qq~$ind<$name\n~; for my $attr (sort attr_sort $attrs->getValues) { my $key = $attr->getNodeName; my $val = $attr->getNodeValue; print $fp qq~$inda$key="$val"\n~; } print $fp qq~$ind>\n~; foreach my $child ($node->getChildNodes) { traverse($fp, $child, $indent + 1); } print $fp qq~$ind\n~; } elsif ($node->getNodeType == TEXT_NODE) { my $text = $node->getData; print $fp qq~$text\n~; } } sub attr_sort { return -1 if $a->getNodeName eq 'name'; return 1 if $b->getNodeName eq 'name'; return $a->getNodeName cmp $b->getNodeName; } 1; #Ye Olde 'Return True' for the in-line package... From kfa at gmx.net Fri Apr 25 03:26:14 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 25 03:26:23 2008 Subject: [sldev] Compile errors of SL viewer 1.20 in VS2005 In-Reply-To: <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> References: <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> Message-ID: <4811B1C6.2000108@gmx.net> Hi, I think you first need to make sure that your build environment is setup properly. Actually you shouldn't get these include errors then. http://wiki.secondlife.com/wiki/Microsoft_Visual_Studio http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 The last step shouldn't be necessary anymore, but it helps looking there in case you still run into trouble. Good luck! Felix wuhanzymail wrote: > Hi, > > This is the first time I compile secondlife viewer using VS2005. I download source code of 1.20 (slviewer-src-Branch_1-20-Viewer-r85643) and try to compile them but get below errors: > > 1>------ Build started: Project: lscript_compile, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling... > 1>lex_yy.cpp > 1>...\linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory > 1>Build log was saved at "...\linden\indra\lscript\lscript_compile\ReleaseNoOpt\BuildLog.htm" > 1>lscript_compile - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > 1>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling resources... > 1>.\res\newViewRes.rc(66) : error RC2135 : file not found: icon1.ico > 1>.\res\newViewRes.rc(224) : error RC2135 : file not found: toolplay.cur > 1>.\res\newViewRes.rc(225) : error RC2135 : file not found: toolpause.cur > 1>.\res\newViewRes.rc(226) : error RC2135 : file not found: toolmediaopen.cur > 1>Build log was saved at "...\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 1>newview - 4 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > 1>------ Build started: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling... > 1>llcrashloggerwindows.cpp > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > 1>.\llcrashloggerwindows.cpp(102) : error C2440: 'initializing' : cannot convert from 'llutf16string' to 'std::basic_string<_Elem,_Traits,_Ax>' > 1> with > 1> [ > 1> _Elem=wchar_t, > 1> _Traits=std::char_traits, > 1> _Ax=std::allocator > 1> ] > 1> No constructor could take the source type, or constructor overload resolution was ambiguous > 1>Build log was saved at "...\linden\indra\win_crash_logger\ReleaseNoOpt\BuildLog.htm" > 1>win_crash_logger - 1 error(s), 2 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > I don't know what's the problems. Would you please give me some suggestions or solutions? I will appreciate for that. Thank you very much! > > Best Regards, > Ying > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From wuhanzymail at 163.com Fri Apr 25 06:47:20 2008 From: wuhanzymail at 163.com (wuhanzymail) Date: Fri Apr 25 06:47:29 2008 Subject: [sldev] Compile errors of SL viewer 1.20 in VS2005 In-Reply-To: <4811B1C6.2000108@gmx.net> References: <4811B1C6.2000108@gmx.net> <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> Message-ID: <27278208.555091209131240359.JavaMail.coremail@bj163app43.163.com> Thanks Felix, I think I've already done all of things mentioned in these three links. But the first problem still exists. "linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory" I checked the whole directory of 'linden' and did not find 'unistd.h'. It seems that the lex_yy.cpp is created dynamically when I compile 'lscript_compile_fb'? The problem is located in Ln2516 of lex_yy.cpp --------------------------------------------------------------------------------- ... #ifndef YY_NO_UNISTD_H /* Special case for "unistd.h", since it is non-ANSI. We include it way * down here because we want the user's section 1 to have been scanned first. * The user has a chance to override it with an option. */ #include #endif ... --------------------------------------------------------------------------------- Is there any other setting of environment I missed? Ying ?2008-04-25?"Felix Duesenburg" ??? Hi, I think you first need to make sure that your build environment is setup properly. Actually you shouldn't get these include errors then. http://wiki.secondlife.com/wiki/Microsoft_Visual_Studio http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 The last step shouldn't be necessary anymore, but it helps looking there in case you still run into trouble. Good luck! Felix wuhanzymail wrote: > Hi, > > This is the first time I compile secondlife viewer using VS2005. I download source code of 1.20 (slviewer-src-Branch_1-20-Viewer-r85643) and try to compile them but get below errors: > > 1>------ Build started: Project: lscript_compile, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling... > 1>lex_yy.cpp > 1>...\linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory > 1>Build log was saved at "...\linden\indra\lscript\lscript_compile\ReleaseNoOpt\BuildLog.htm" > 1>lscript_compile - 1 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > 1>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling resources... > 1>.\res\newViewRes.rc(66) : error RC2135 : file not found: icon1.ico > 1>.\res\newViewRes.rc(224) : error RC2135 : file not found: toolplay.cur > 1>.\res\newViewRes.rc(225) : error RC2135 : file not found: toolpause.cur > 1>.\res\newViewRes.rc(226) : error RC2135 : file not found: toolmediaopen.cur > 1>Build log was saved at "...\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > 1>newview - 4 error(s), 0 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > 1>------ Build started: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ > 1>Compiling... > 1>llcrashloggerwindows.cpp > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > 1>.\llcrashloggerwindows.cpp(102) : error C2440: 'initializing' : cannot convert from 'llutf16string' to 'std::basic_string<_Elem,_Traits,_Ax>' > 1> with > 1> [ > 1> _Elem=wchar_t, > 1> _Traits=std::char_traits, > 1> _Ax=std::allocator > 1> ] > 1> No constructor could take the source type, or constructor overload resolution was ambiguous > 1>Build log was saved at "...\linden\indra\win_crash_logger\ReleaseNoOpt\BuildLog.htm" > 1>win_crash_logger - 1 error(s), 2 warning(s) > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > I don't know what's the problems. Would you please give me some suggestions or solutions? I will appreciate for that. Thank you very much! > > Best Regards, > Ying > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080425/e4c11308/attachment.htm From kfa at gmx.net Fri Apr 25 06:59:58 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Fri Apr 25 07:00:05 2008 Subject: [sldev] Compile errors of SL viewer 1.20 in VS2005 In-Reply-To: <27278208.555091209131240359.JavaMail.coremail@bj163app43.163.com> References: <4811B1C6.2000108@gmx.net> <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> <27278208.555091209131240359.JavaMail.coremail@bj163app43.163.com> Message-ID: <4811E3DE.4030502@gmx.net> Just did a search to give a qualified answer, when I saw... unistd.h is included in about 10 places, but /only/ on OS's other than Windows. Every single instance is filtered by a compiler directive. Did you do any tweaking of the project settings that could disable LL_WINDOWS? wuhanzymail wrote: > Thanks Felix, I think I've already done all of things mentioned in these three links. But the first problem still exists. > > "linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory" > > I checked the whole directory of 'linden' and did not find 'unistd.h'. It seems that the lex_yy.cpp is created dynamically when I compile 'lscript_compile_fb'? > The problem is located in Ln2516 of lex_yy.cpp > --------------------------------------------------------------------------------- > ... > #ifndef YY_NO_UNISTD_H > /* Special case for "unistd.h", since it is non-ANSI. We include it way > * down here because we want the user's section 1 to have been scanned first. > * The user has a chance to override it with an option. > */ > #include > #endif > ... > > --------------------------------------------------------------------------------- > > Is there any other setting of environment I missed? > > Ying > From kaleajinkya at gmail.com Fri Apr 25 07:17:15 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Apr 25 07:17:17 2008 Subject: [sldev] Compile errors of SL viewer 1.20 in VS2005 In-Reply-To: <27278208.555091209131240359.JavaMail.coremail@bj163app43.163.com> References: <9670912.44801209084327219.JavaMail.coremail@bj163app99.163.com> <4811B1C6.2000108@gmx.net> <27278208.555091209131240359.JavaMail.coremail@bj163app43.163.com> Message-ID: I got the same error once in VS2005. I tried the 3rd link mentioned by Felix and it worked for me. 2008/4/25 wuhanzymail : > Thanks Felix, I think I've already done all of things mentioned in these > three links. But the first problem still exists. > > "linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: > Cannot open include file: 'unistd.h': No such file or directory" > > I checked the whole directory of 'linden' and did not find 'unistd.h'. It > seems that the lex_yy.cpp is created dynamically when I compile > 'lscript_compile_fb'? > The problem is located in Ln2516 of lex_yy.cpp > > --------------------------------------------------------------------------------- > ... > #ifndef YY_NO_UNISTD_H > /* Special case for "unistd.h", since it is non-ANSI. We include it way > * down here because we want the user's section 1 to have been scanned > first. > * The user has a chance to override it with an option. > */ > #include > #endif > ... > > --------------------------------------------------------------------------------- > > Is there any other setting of environment I missed? > > Ying > > ?2008-04-25?"Felix Duesenburg" ??? > > Hi, > > I think you first need to make sure that your build environment is setup > properly. Actually you shouldn't get these include errors then. > http://wiki.secondlife.com/wiki/Microsoft_Visual_Studiohttp://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > > The last step shouldn't be necessary anymore, but it helps looking there > in case you still run into trouble. > > Good luck! > > Felix > > > wuhanzymail wrote: > > Hi, > > > > This is the first time I compile secondlife viewer using VS2005. I download source code of 1.20 (slviewer-src-Branch_1-20-Viewer-r85643) and try to compile them but get below errors: > > > > 1>------ Build started: Project: lscript_compile, Configuration: ReleaseNoOpt Win32 ------ > > 1>Compiling... > > 1>lex_yy.cpp > > 1>...\linden\indra\lscript\lscript_compile\lex_yy.cpp(2514) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory > > 1>Build log was saved at "...\linden\indra\lscript\lscript_compile\ReleaseNoOpt\BuildLog.htm" > > 1>lscript_compile - 1 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > > > > > 1>------ Build started: Project: newview, Configuration: ReleaseNoOpt Win32 ------ > > 1>Compiling resources... > > 1>.\res\newViewRes.rc(66) : error RC2135 : file not found: icon1.ico > > 1>.\res\newViewRes.rc(224) : error RC2135 : file not found: toolplay.cur > > 1>.\res\newViewRes.rc(225) : error RC2135 : file not found: toolpause.cur > > 1>.\res\newViewRes.rc(226) : error RC2135 : file not found: toolmediaopen.cur > > 1>Build log was saved at "...\linden\indra\newview\ReleaseNoOpt\BuildLog.htm" > > 1>newview - 4 error(s), 0 warning(s) > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > > > > > 1>------ Build started: Project: win_crash_logger, Configuration: ReleaseNoOpt Win32 ------ > > 1>Compiling... > > 1>llcrashloggerwindows.cpp > > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > > 1>...\linden\libraries\include\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss > > 1>.\llcrashloggerwindows.cpp(102) : error C2440: 'initializing' : cannot convert from 'llutf16string' to 'std::basic_string<_Elem,_Traits,_Ax>' > > 1> with > > 1> [ > > 1> _Elem=wchar_t, > > 1> _Traits=std::char_traits, > > 1> _Ax=std::allocator > > 1> ] > > 1> No constructor could take the source type, or constructor overload resolution was ambiguous > > 1>Build log was saved at "...\linden\indra\win_crash_logger\ReleaseNoOpt\BuildLog.htm" > > 1>win_crash_logger - 1 error(s), 2 warning(s) > > ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== > > > > > > I don't know what's the problems. Would you please give me some suggestions or solutions? I will appreciate for that. Thank you very much! > > > > Best Regards, > > Ying > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------ > ????????? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080425/9b1a6c03/attachment-0001.htm From overtake at keynet.com.br Fri Apr 25 09:52:28 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Fri Apr 25 09:57:23 2008 Subject: [sldev] New idea in JIRA References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com><4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net><1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net><8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com><48105EE1.6050304@gmx.net> <1209061104.5050.58.camel@localhost> Message-ID: <00da01c8a6f5$611f78f0$6e00a8c0@eaurouge> Guys, a friend put a nice idea on JIRA, to let us change size of IM window to down to 2 lines instead of the 10 lines limit. Plus, she suggest some change on the data on the top area of window. I would be already happy with the 2 lines limit... https://jira.secondlife.com/browse/VWR-6837 {}Overtake From darien_caldwell at comcast.net Fri Apr 25 10:59:38 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Fri Apr 25 10:59:42 2008 Subject: [sldev] New idea in JIRA Message-ID: <042520081759.216.48121C0A0003B2EF000000D8221205921404040A990B040E0CA1020A079D0E0B@comcast.net> As of 1.19 client you can detach the "Contacts" portion of the Communcations window, this allows IMs to be resized down to as small as you like. (thank goodness). However, if a Group IM is among the IMs open, the resizing is still limited. Thanks for the JIRA link. -------------- Original message ---------------------- From: "Sylvio Deutsch" > Guys, a friend put a nice idea on JIRA, to let us change size of IM window > to down to 2 lines instead of the 10 lines limit. Plus, she suggest some > change on the data on the top area of window. I would be already happy with > the 2 lines limit... > > https://jira.secondlife.com/browse/VWR-6837 > > > > {}Overtake > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From lenglish5 at cox.net Fri Apr 25 15:44:32 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Apr 25 15:44:35 2008 Subject: [sldev] Script compiler - was: Re: Refactoring and development economy In-Reply-To: <480DC407.2010306@lindenlab.com> References: <48064D58.5050003@gmail.com> <48066426.9020807@lindenlab.com> <4806D58C.7050103@cox.net> <480880E9.2060305@gmx.net> <1208554111.22067.47.camel@localhost> <48093659.8010907@gmx.net> <8D5C38BE-0C7B-4617-9B82-74E28BA0F09F@lindenlab.com> <4809C3FE.6030700@gmx.net> <14C15F31-D46C-4ECA-A1B2-B77B78A5167B@gmail.com> <480A1A65.4010509@gmx.net> <480A677B.8080500@weblogsinc.com> <480ADB99.6010506@gmx.net> <480DC407.2010306@lindenlab.com> Message-ID: <48125ED0.6040706@cox.net> Jim Purbrick (Babbage) wrote: > The plan is to move to server side compilation in the short term so > that we can be sure that LSL bytecode we are executing is the output > of the LSL compiler and not just arbitrary bytes or carefully crafted > LSO files designed to exploit some weakness in the LSL runtime. > > The LSL compiler used by the asset upload framework is exactly the > same code that is used in the current viewer compiler, so we can > accept patches, but personally I would far rather see us move to allow > other .NET languages than spend time patching and extending LSL. > > In the long term I'd like to be able to accept arbitrary CLI > assemblies that we can verify and trust to run in the server sandbox. > This requires significant hardening of the simulator script sandbox > and we'd have to put a lot of faith in Mono's nascent verifier, but I > think it's a compelling endgame: use any language that targets the CLI > to script SL along with the tools and debugging facilities you get > with that language. Or invent your own. and call it LSL3 if you must ;-) As an interim solution to speed up the migration to other languages, say , C#, I suggest creating an "LSL3" option which is really a subset of C# that is similar to the functionality (and appearance) of LSL2 and start cautiously adding "safe" features to it, such as the ability to use switch(integer) statements and perhaps others, as found in http://wiki.secondlife.com/wiki/LSL3 or https://jira.secondlife.com/browse/SVC-1657 . This would (could?) allow you to add at least a few new features (really unlock more C# syntax) without waiting for a more reliable script sandbox and Mono verifier. At the same time, work could start on more rational versions of the current LSL functions that fix all the broken bits, such as child rotations that don't work right. Also, a new syntax could be devised and tested for the functions that lists of parameters, such as the llSetPrimitiveParameters and llGetPrimitiveParameters that isn't backwards compatible with LSL2 but is easier to use in a mono compiler world. Lawson From tom at streamsense.net Fri Apr 25 21:46:40 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri Apr 25 21:47:00 2008 Subject: [sldev] Okay.. Message-ID: <4812B3B0.5030402@streamsense.net> Who broke SL? From secret.argent at gmail.com Fri Apr 25 22:15:16 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Apr 25 22:15:05 2008 Subject: [sldev] Okay.. In-Reply-To: <4812B3B0.5030402@streamsense.net> References: <4812B3B0.5030402@streamsense.net> Message-ID: Oh, it's not just me? I've been beating on my router with the thighbone of an antelope since Linden Labs isn't. :) On 2008-04-25, at 23:46, Thomas Grimshaw wrote: > Who broke SL? From kfa at gmx.net Sat Apr 26 07:20:48 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Sat Apr 26 07:21:02 2008 Subject: [sldev] Bells'n'whistles: Present list of alt avatars upon login Message-ID: <48133A40.4050807@gmx.net> Hi @, Here is a new patch to play with :) https://jira.secondlife.com/browse/VWR-6891 I had a faint memory of this feature being requested before, but I couldn't find it. (Or was it on a wiki?) Cheers, Felix From hawk.carter at unix-dev.de Sun Apr 27 02:54:00 2008 From: hawk.carter at unix-dev.de (hawk.carter@unix-dev.de) Date: Sun Apr 27 02:54:03 2008 Subject: [sldev] error while compiling on vc8/9 (unistd.h) Message-ID: <61409.78.94.98.187.1209290040.squirrel@h620153.serverkompetenz.net> I get on compiling (VC8/VC9) this Error : 10>.\lex_yy.cpp(2509) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 23>LINK : fatal error LNK1181: cannot open input file 'lscript_compile.lib' I know that the link error depends on the uinst.h error. i tried now several ways, but seems i'm unable to remove that error. Would be nice if anyone could help. lecina From wuhanzymail at 163.com Sun Apr 27 12:18:51 2008 From: wuhanzymail at 163.com (wuhanzymail) Date: Sun Apr 27 12:19:02 2008 Subject: [sldev] error while compiling on vc8/9 (unistd.h) In-Reply-To: <61409.78.94.98.187.1209290040.squirrel@h620153.serverkompetenz.net> References: <61409.78.94.98.187.1209290040.squirrel@h620153.serverkompetenz.net> Message-ID: <9684262.340061209323931056.JavaMail.coremail@bj163app15.163.com> I met this error and here is what I did: 1) right click project lscript_compile, choose properties, c/c++, Preprocessor, add 'YY_NO_UNISTD_H' to Preporcessor Definitions. 2) in lex_yy.cpp, line 5915 change: #ifndef __cplusplus extern int isatty (int ); #endif to: #ifndef YY_NEVER_INTERACTIVE extern int isatty (int ); #endif 3) still in lex_yy.cpp, line 5943 change: b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; to: #if YY_NEVER_INTERACTIVE b->yy_is_interactive = 0; #else b->yy_is_interactive = file ? (isatty( fileno(file) ) > 0) : 0; #endif I don't know why this will happen and if my solution is correct. But at least the compile is successful. I use VS2005 to compile the viewer 1.19.1.4. Good luck Ying ?2008-04-27?hawk.carter@unix-dev.de ??? I get on compiling (VC8/VC9) this Error : 10>.\lex_yy.cpp(2509) : fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory 23>LINK : fatal error LNK1181: cannot open input file 'lscript_compile.lib' I know that the link error depends on the uinst.h error. i tried now several ways, but seems i'm unable to remove that error. Would be nice if anyone could help. lecina _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080428/1fa8f107/attachment.htm From hawk.carter at unix-dev.de Mon Apr 28 01:12:15 2008 From: hawk.carter at unix-dev.de (hawk.carter@unix-dev.de) Date: Mon Apr 28 01:12:18 2008 Subject: [sldev] lltexteditor.cpp Message-ID: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> Heya`s, ok getting now the vanilla viewer compiled..but after adding bunches of patches i get this error ..or better errors : 1>------ Build started: Project: llui, Configuration: Release Win32 ------ 1>Compiling... 1>lltexteditor.cpp 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(143) : error C2146: syntax error : missing ';' before identifier 'PROPSHEETPAGE_RESOURCE' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(143) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(143) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(207) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(216) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(228) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(234) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C2146: syntax error : missing ';' before identifier 'pResource' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C2146: syntax error : missing ';' before identifier 'pfnDlgProc' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(243) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(531) : error C2146: syntax error : missing ';' before identifier 'hdr' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(531) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\prsht.h(531) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(322) : error C2146: syntax error : missing ';' before identifier 'hdr' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(322) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(322) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(329) : error C2146: syntax error : missing ';' before identifier 'hdr' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(329) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(329) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(345) : error C2146: syntax error : missing ';' before identifier 'hdr' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(345) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(345) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(353) : error C2146: syntax error : missing ';' before identifier 'hdr' 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(353) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>c:\program files\microsoft platform sdk for windows server 2003 r2\include\commdlg.h(353) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1>Build log was saved at "file://c:\linden\indra\llui\Release\BuildLog.htm" 1>llui - 54 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== From soft at lindenlab.com Mon Apr 28 05:58:25 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 28 05:58:29 2008 Subject: [sldev] lltexteditor.cpp In-Reply-To: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> References: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> Message-ID: On Mon, Apr 28, 2008 at 3:12 AM, wrote: > Heya`s, ok getting now the vanilla viewer compiled..but after adding > bunches of patches i get this error ..or better errors : > > 1>------ Build started: Project: llui, Configuration: Release Win32 ------ > 1>Compiling... > 1>lltexteditor.cpp > 1>c:\program files\microsoft platform sdk for windows server 2003 > r2\include\prsht.h(143) : error C2146: syntax error : missing ';' before > identifier 'PROPSHEETPAGE_RESOURCE' > 1>c:\program files\microsoft platform sdk for windows server 2003 For people reading newer threads first - Hawk's is a VS2005 or VS2008 compile attempt. From hawk.carter at unix-dev.de Mon Apr 28 06:10:28 2008 From: hawk.carter at unix-dev.de (hawk.carter@unix-dev.de) Date: Mon Apr 28 06:10:35 2008 Subject: [sldev] lltexteditor.cpp In-Reply-To: References: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> Message-ID: <58564.78.94.98.187.1209388228.squirrel@h620153.serverkompetenz.net> Opps sorry Soft, yes it is a VC2008 try, and i added some of Nicks and Cool SL Viewer patches....well the vanilla compile worked after the unistd.h problem like a charm (i used the cygwin/mingw/sys version of unist.h). But one Patch throwed the compile to these Errors... again i tried several ways..but nothing worked (it`s normally my last way to ask here, because i like to fiddle on myself ;) ) ----- Original Message ----- From: "Soft" To: Cc: Sent: Monday, April 28, 2008 2:58 PM Subject: Re: [sldev] lltexteditor.cpp > On Mon, Apr 28, 2008 at 3:12 AM, wrote: >> Heya`s, ok getting now the vanilla viewer compiled..but after adding >> bunches of patches i get this error ..or better errors : >> >> 1>------ Build started: Project: llui, Configuration: Release Win32 ------ >> 1>Compiling... >> 1>lltexteditor.cpp >> 1>c:\program files\microsoft platform sdk for windows server 2003 >> r2\include\prsht.h(143) : error C2146: syntax error : missing ';' before >> identifier 'PROPSHEETPAGE_RESOURCE' >> 1>c:\program files\microsoft platform sdk for windows server 2003 > > For people reading newer threads first - Hawk's is a VS2005 or VS2008 > compile attempt. > From robin.cornelius at gmail.com Mon Apr 28 06:29:12 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Apr 28 06:29:15 2008 Subject: [sldev] lltexteditor.cpp In-Reply-To: <58564.78.94.98.187.1209388228.squirrel@h620153.serverkompetenz.net> References: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> <58564.78.94.98.187.1209388228.squirrel@h620153.serverkompetenz.net> Message-ID: On Mon, Apr 28, 2008 at 2:10 PM, wrote: > Opps sorry Soft, yes it is a VC2008 try, and i added some of Nicks and > Cool SL Viewer patches....well the vanilla compile worked after the > unistd.h problem like a charm (i used the cygwin/mingw/sys version of > unist.h). > > But one Patch throwed the compile to these Errors... again i tried several > ways..but nothing worked (it`s normally my last way to ask here, because i > like to fiddle on myself ;) ) > Whats the patch that is doing this? can you dump it in a pastebin or link it somewhere? Does it have any funky unix line endings or UTF-8 encoding that is throwing visual studio? Robin From hawk.carter at unix-dev.de Mon Apr 28 06:42:04 2008 From: hawk.carter at unix-dev.de (hawk.carter@unix-dev.de) Date: Mon Apr 28 06:42:06 2008 Subject: [sldev] lltexteditor.cpp In-Reply-To: References: <56877.78.94.98.187.1209370335.squirrel@h620153.serverkompetenz.net> <58564.78.94.98.187.1209388228.squirrel@h620153.serverkompetenz.net> Message-ID: <59108.78.94.98.187.1209390124.squirrel@h620153.serverkompetenz.net> I'll patch it patch by patch now, to figure out which patch made these. maybe i'll get it on my self then, maybe not..but i'll post it anyways. Hawk PS: I was 4month off, i must say..things have changed ^^ > > Whats the patch that is doing this? can you dump it in a pastebin or > link it somewhere? > > Does it have any funky unix line endings or UTF-8 encoding that is > throwing visual studio? > > Robin > From tom at streamsense.net Mon Apr 28 17:57:29 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Apr 28 17:57:57 2008 Subject: [sldev] SL Database purge Message-ID: <48167279.4090204@streamsense.net> This from a friend: "Hi. Not so great news, I'm afraid. I talked to the project manager on Inventory Management, and was informed that on September 12, 2007, they ran a program that collected unused objects and removed them from the database. "Any older objects which [you] didn't rez between then and early December (during which time they would have been automatically recovered) could be candidates" for the category "missing from database", and unfortunately are not recoverable. (This is true for the 4 I tried to rez from my own inventory, as well -- and no doubt many others.) That will apply anywhere in SL, not just your own regions. Rowan" How on earth can LL justify this? With no warning or announcement? Don't worry folks, just rez your entire inventory every 2 months and you won't lose anything.. ~Tom From seg at haxxed.com Mon Apr 28 18:18:30 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon Apr 28 18:18:37 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167279.4090204@streamsense.net> References: <48167279.4090204@streamsense.net> Message-ID: <1209431910.3380.88.camel@localhost> On Tue, 2008-04-29 at 01:57 +0100, Thomas Grimshaw wrote: > This from a friend: Does your friend work at LL? If not, this is the definition of hearsay. Which doesn't necessarily mean it's incorrect, but the SL community has a long track record of spreading rumors, hoaxes, scams and outright lies like the flu. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080428/320dd174/attachment.pgp From tom at streamsense.net Mon Apr 28 18:21:57 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Mon Apr 28 18:22:25 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167279.4090204@streamsense.net> References: <48167279.4090204@streamsense.net> Message-ID: <48167835.4060107@streamsense.net> Thomas Grimshaw wrote: > This from a friend: > > "Hi. Not so great news, I'm afraid. I talked to the project manager > on Inventory Management, and was informed that on September 12, 2007, > they ran a program that collected unused objects and removed them from > the database. "Any older objects which [you] didn't rez between then > and early December (during which time they would have been > automatically recovered) could be candidates" for the category > "missing from database", and unfortunately are not recoverable. (This > is true for the 4 I tried to rez from my own inventory, as well -- and > no doubt many others.) That will apply anywhere in SL, not just your > own regions. Rowan" > > How on earth can LL justify this? With no warning or announcement? > Don't worry folks, just rez your entire inventory every 2 months and > you won't lose anything.. > > ~Tom > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev Just to clarify, this is a response to a support ticket from a linden labs representative. Ticket number available on request.. Tom From seg at haxxed.com Mon Apr 28 18:37:52 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon Apr 28 18:38:01 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167835.4060107@streamsense.net> References: <48167279.4090204@streamsense.net> <48167835.4060107@streamsense.net> Message-ID: <1209433072.3380.101.camel@localhost> On Tue, 2008-04-29 at 02:21 +0100, Thomas Grimshaw wrote: > Thomas Grimshaw wrote: > > This from a friend: > > > > "Hi. Not so great news, I'm afraid. I talked to the project manager > > on Inventory Management, and was informed that on September 12, 2007, > > they ran a program that collected unused objects and removed them from > > the database. "Any older objects which [you] didn't rez between then > > and early December (during which time they would have been > > automatically recovered) could be candidates" for the category > > "missing from database", and unfortunately are not recoverable. (This > > is true for the 4 I tried to rez from my own inventory, as well -- and > > no doubt many others.) That will apply anywhere in SL, not just your > > own regions. Rowan" > > > > How on earth can LL justify this? With no warning or announcement? > > Don't worry folks, just rez your entire inventory every 2 months and > > you won't lose anything.. > Just to clarify, this is a response to a support ticket from a linden > labs representative. Ticket number available on request.. Well it would carry more weight if it was your friend themself were posting to a mostly off topic mailing list. And even better if we could see the actual ticket, yes. I'm missing a crapload of inventory myself. And more seems to disappear every day. Gestures, especially. All the more reason to implement "Save As..." in the client. (There, I'm redirecting this towards being on topic and using it as yet another opportunity to push my own personal talking points. Muhahaha...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080428/d3d49c89/attachment.pgp From soft at lindenlab.com Mon Apr 28 18:39:18 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 28 18:39:22 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167279.4090204@streamsense.net> References: <48167279.4090204@streamsense.net> Message-ID: On Mon, Apr 28, 2008 at 7:57 PM, Thomas Grimshaw wrote: > > "Hi. Not so great news, I'm afraid. I talked to the project manager on > Inventory Management, and was informed that on September 12, 2007, they ran > a program that collected unused objects and removed them from the database. > "Any older objects which [you] didn't rez between then and early December > (during which time they would have been automatically recovered) could be > candidates" for the category "missing from database", and unfortunately are > not recoverable. (This is true for the 4 I tried to rez from my own > inventory, as well -- and no doubt many others.) That will apply anywhere in > SL, not just your own regions. Rowan" > > How on earth can LL justify this? With no warning or announcement? Don't > worry folks, just rez your entire inventory every 2 months and you won't > lose anything.. That's not how asset purges work at all - support misunderstood. The assets that get purged are ones that aren't in anyone's inventory any longer, aren't contained in any objects, aren't clearly referenced from scripts (as with a hard-coded asset ID), etc. There are problems with missing assets, which we're looking at. But there is absolutely no system that intentionally destroys items that are still in your inventory. From jessesa at gmail.com Mon Apr 28 19:47:30 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Mon Apr 28 19:47:36 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> Message-ID: But I had a freind who's great aunt had a nephew who worked with a guy that knew someone that heard it from a freind that said a Linden told him it was true.;) On 4/28/08, Soft wrote: > > On Mon, Apr 28, 2008 at 7:57 PM, Thomas Grimshaw > wrote: > > > > "Hi. Not so great news, I'm afraid. I talked to the project manager on > > Inventory Management, and was informed that on September 12, 2007, they > ran > > a program that collected unused objects and removed them from the > database. > > "Any older objects which [you] didn't rez between then and early > December > > (during which time they would have been automatically recovered) could > be > > candidates" for the category "missing from database", and unfortunately > are > > not recoverable. (This is true for the 4 I tried to rez from my own > > inventory, as well -- and no doubt many others.) That will apply > anywhere in > > SL, not just your own regions. Rowan" > > > > How on earth can LL justify this? With no warning or announcement? > Don't > > worry folks, just rez your entire inventory every 2 months and you won't > > lose anything.. > > > That's not how asset purges work at all - support misunderstood. > > The assets that get purged are ones that aren't in anyone's inventory > any longer, aren't contained in any objects, aren't clearly referenced > from scripts (as with a hard-coded asset ID), etc. There are problems > with missing assets, which we're looking at. But there is absolutely > no system that intentionally destroys items that are still in your > inventory. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080428/e80e94ac/attachment.htm From soft at lindenlab.com Mon Apr 28 20:23:01 2008 From: soft at lindenlab.com (Soft) Date: Mon Apr 28 20:23:04 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> Message-ID: On Mon, Apr 28, 2008 at 9:47 PM, Jesse Barnett wrote: > > But I had a freind who's great aunt had a nephew who worked with a guy that > knew someone that heard it from a freind that said a Linden told him it was > true.;) Let's not carry on too much with this. The message he quoted from support was admittedly ambiguous or even misleading. I'm asking if they've got a standard message template for explaining that, and will offer to help make one if not. I'd be pretty wound up too, if I thought my stuff was going to expire without warning. From jessesa at gmail.com Tue Apr 29 04:21:04 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Apr 29 04:21:08 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> Message-ID: On 4/28/08, Soft wrote: > > On Mon, Apr 28, 2008 at 9:47 PM, Jesse Barnett wrote: > > > > But I had a freind who's great aunt had a nephew who worked with a guy > that > > knew someone that heard it from a freind that said a Linden told him it > was > > true.;) > > > Let's not carry on too much with this. The message he quoted from > support was admittedly ambiguous or even misleading. I'm asking if > they've got a standard message template for explaining that, and will > offer to help make one if not. I'd be pretty wound up too, if I thought my stuff was going to expire > without warning. I am not poking fun at Thomas. Face it we don't have a choice but to either laugh or cry at the inventory loss problem. It is far from a new problem with the first reports coming in the last quarter of 2006. Still remember the blog post when Beast was named as the person to send inventory loss reports to in December 2006. We were hopefull at that point that it would be resolved. That hope is gone even thou it costs some residents a great deal of RL money. So yes, it is ironic that you used the term : "Let's not carry on too much with this." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080429/543e17c7/attachment-0001.htm From jessesa at gmail.com Tue Apr 29 05:11:52 2008 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Apr 29 05:11:54 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> Message-ID: Now to try to make this topic relevant for this newsgroup. Can we get any official word from LL about the possibility of a dev doing an integrated backup to xml for limited perms inventory items? This has been asked many times, but I don't recall a response from LL stating "no way in hell" or "maybe". Second Inventory just doesn't address the key issue here, the ability to backup items that are no copy or no transfer. Eddy Stryker has http://jira.secondlife.com/browse/VWR-4165 which will allow prims/linksets to be imported/exported. So the ability to do more is definitely possible. Can we carry this line of development to it's logical conclusion? Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080429/19c111b1/attachment.htm From thomas.shikami at online.de Tue Apr 29 06:01:41 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Tue Apr 29 06:01:51 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> Message-ID: <48171C35.1030004@online.de> What I can imagine to be possible for not fully permissive items, that no transfer items and including assets could be encrypted relating to the agent UUID server side and sent as a BLOB to the viewer to store on harddisk. For full permissive items, it could be an encryption with a generic key or no encryption at all. This would allow backup of assets on the client side. Sadly I see no acceptible way to do this with no copy items. Please consider server side encrypted downloads for inventory including assets for all copyable items. It is possible technically. Thanks Jesse Barnett wrote: > Now to try to make this topic relevant for this newsgroup. > > Can we get any official word from LL about the possibility of a dev > doing an integrated backup to xml for limited perms inventory items? > This has been asked many times, but I don't recall a response from LL > stating "no way in hell" or "maybe". Second Inventory just doesn't > address the key issue here, the ability to backup items that are no > copy or no transfer. Eddy Stryker has > http://jira.secondlife.com/browse/VWR-4165 which will allow > prims/linksets to be > imported/exported. So the ability to do more is definitely possible. > Can we carry this line of development to it's logical conclusion? > > Jesse Barnett From tom at streamsense.net Tue Apr 29 06:03:59 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Apr 29 06:04:33 2008 Subject: [sldev] SL Database purge In-Reply-To: <48171C35.1030004@online.de> References: <48167279.4090204@streamsense.net> <48171C35.1030004@online.de> Message-ID: <48171CBF.6080204@streamsense.net> Thomas Shikami wrote: > Please consider server side encrypted downloads for inventory > including assets for all copyable items. It is possible technically. > Thanks This would require the storage of encryption keys on linden equipment, therefore no redundancy is provided, therefore it's not a backup. Unless you're planning on using the same key for everything, in which case it will be cracked wide open. Tom From thomas.shikami at online.de Tue Apr 29 06:25:05 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Tue Apr 29 06:25:10 2008 Subject: [sldev] SL Database purge In-Reply-To: <48171CBF.6080204@streamsense.net> References: <48167279.4090204@streamsense.net> <48171C35.1030004@online.de> <48171CBF.6080204@streamsense.net> Message-ID: <481721B1.8030201@online.de> Thomas Grimshaw wrote: > Thomas Shikami wrote: > This would require the storage of encryption keys on linden equipment, > therefore no redundancy is provided, therefore it's not a backup. I think of using the same key more or less. But keyed using the Agent UUID and a good salt to make cracking hard enough. Someone who studied cryptography could help with this. I'm thinking of generated keys here, so virtually no storage is needed to store keys. > > Unless you're planning on using the same key for everything, in which > case it will be cracked wide open. That's why cryptography isn't easy. It's easy to make something that seems safe but is cracked quickly if it's some homebrewn stuff. To make it secure, I think it's best to make that system open-source and allow wide testing of it. From tateru.nino at gmail.com Tue Apr 29 11:11:37 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Apr 29 11:17:02 2008 Subject: [sldev] SL Database purge In-Reply-To: <48171C35.1030004@online.de> References: <48167279.4090204@streamsense.net> <48171C35.1030004@online.de> Message-ID: <481764D9.70104@weblogsinc.com> This would require Linden Lab's databases keeping the encryption keys more effectively than the items, would it not? Thomas Shikami wrote: > What I can imagine to be possible for not fully permissive items, that > no transfer items and including assets could be encrypted relating to > the agent UUID server side and sent as a BLOB to the viewer to store > on harddisk. For full permissive items, it could be an encryption with > a generic key or no encryption at all. > This would allow backup of assets on the client side. Sadly I see no > acceptible way to do this with no copy items. > Please consider server side encrypted downloads for inventory > including assets for all copyable items. It is possible technically. > Thanks > > Jesse Barnett wrote: >> Now to try to make this topic relevant for this newsgroup. >> >> Can we get any official word from LL about the possibility of a dev >> doing an integrated backup to xml for limited perms inventory items? >> This has been asked many times, but I don't recall a response from LL >> stating "no way in hell" or "maybe". Second Inventory just doesn't >> address the key issue here, the ability to backup items that are no >> copy or no transfer. Eddy Stryker has >> http://jira.secondlife.com/browse/VWR-4165 which will allow >> prims/linksets to be imported/exported. So the ability to do more is >> definitely possible. Can we carry this line of development to it's >> logical conclusion? >> >> Jesse Barnett > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From phoenix at secondlife.com Tue Apr 29 11:33:44 2008 From: phoenix at secondlife.com (Phoenix) Date: Tue Apr 29 11:32:27 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167279.4090204@streamsense.net> References: <48167279.4090204@streamsense.net> Message-ID: <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> This has probably be addressed, but I want to be super clear. We only intentionally remove unreferenced assets. This means that it's in no agent/task/region/etc inventory, and not even referenced via uuid in a script state. There have been bugs, our asset cluster has crashed, we've had our isp drop connectivity between the colos, and similar problems, but no one at linden has even suggested deleting things which have not been rezzed for a while. You or your friend misunderstood something. This list is also probably not a good forum for "friend of a friend told me" gossip. On 2008-04-28, at 17:57, Thomas Grimshaw wrote: > This from a friend: > > "Hi. Not so great news, I'm afraid. I talked to the project > manager on Inventory Management, and was informed that on September > 12, 2007, they ran a program that collected unused objects and > removed them from the database. "Any older objects which [you] > didn't rez between then and early December (during which time they > would have been automatically recovered) could be candidates" for > the category "missing from database", and unfortunately are not > recoverable. (This is true for the 4 I tried to rez from my own > inventory, as well -- and no doubt many others.) That will apply > anywhere in SL, not just your own regions. Rowan" > > How on earth can LL justify this? With no warning or announcement? > Don't worry folks, just rez your entire inventory every 2 months > and you won't lose anything.. > > ~Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080429/de600e31/PGP.pgp From sean at lindenlab.com Tue Apr 29 12:00:50 2008 From: sean at lindenlab.com (Sean Lynch) Date: Tue Apr 29 12:01:32 2008 Subject: [sldev] SL Database purge In-Reply-To: <48167279.4090204@streamsense.net> References: <48167279.4090204@streamsense.net> Message-ID: <48177062.5060504@lindenlab.com> Just to add to Soft's and Phoenix's explanations, the actual event that led to this was an earlier attempt to separate referenced assets from unreferenced ones that had some bugs. We never deleted any of the unreferenced assets, we just moved them to a different directory where they couldn't be reached. After this, we had a script called auditor running that would look for 404 errors on the asset servers and move the assets in question back into the "good" folder. Once we started working on rewriting the whole garbage collection system, we just moved these old "maybe garbage" assets back in with the rest. So there are no assets still missing because of this particular event. For what should be obvious reasons, Linden Lab takes any bug that causes people to lose stuff *very* seriously. This does not mean we can develop a huge amount of support or developer time to each individual case of loss, because then we would not have any time left over to fix the root causes. Huge progress has been made in getting rid of the old causes of loss, but SL is a very complex system and the volume of transactions is growing, and every time someone loses an object, it's pretty annoying (or even devastating to them in some cases), so it's going to get a lot of attention, leading to the impression that nothing has changed with regard to inventory loss. This does not make it any less important for us to stomp out every single thing that can cause content loss and it does not diminish the heartbreak that each individual loss event causes. Regarding backing stuff up to your hard drive, I believe there are open source efforts underway already to enable exporting of content you have mod permissions on for use on opensim and other alternative simulators; these same projects will presumably enable the re-import of such content to Second Life. As for things you don't have permissions to, as others have already pointed out, this would be difficult to implement without also making it easy to bypass permissions. This same dev time could (and I believe should) be spent eliminating remaining and newly invented causes of causes of content loss. Thomas Grimshaw wrote: > This from a friend: > > "Hi. Not so great news, I'm afraid. I talked to the project manager > on Inventory Management, and was informed that on September 12, 2007, > they ran a program that collected unused objects and removed them from > the database. "Any older objects which [you] didn't rez between then > and early December (during which time they would have been > automatically recovered) could be candidates" for the category > "missing from database", and unfortunately are not recoverable. (This > is true for the 4 I tried to rez from my own inventory, as well -- and > no doubt many others.) That will apply anywhere in SL, not just your > own regions. Rowan" > > How on earth can LL justify this? With no warning or announcement? > Don't worry folks, just rez your entire inventory every 2 months and > you won't lose anything.. > > ~Tom > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080429/35f3da6e/signature.pgp From secret.argent at gmail.com Tue Apr 29 18:35:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Apr 29 18:35:16 2008 Subject: [sldev] SL Database purge In-Reply-To: <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> Message-ID: <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> On 2008-04-29, at 13:33, Phoenix wrote: > We only intentionally remove unreferenced assets. This means that > it's in no agent/task/region/etc inventory, and not even referenced > via uuid in a script state. Even if it's in a box inside a box inside a box inside a box, N deep? From kfa at gmx.net Tue Apr 29 20:42:17 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Tue Apr 29 20:42:37 2008 Subject: [sldev] SL Database purge In-Reply-To: <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> Message-ID: <4817EA99.2070905@gmx.net> Argent Stonecutter wrote: > On 2008-04-29, at 13:33, Phoenix wrote: >> We only intentionally remove unreferenced assets. This means that it's >> in no agent/task/region/etc inventory, and not even referenced via >> uuid in a script state. > > Even if it's in a box inside a box inside a box inside a box, N deep? > That shouldn't make a difference to whether an asset key can be found or not. The box is really just a kind of reference, either in a relational database or in a directory structure. What I would find interesting to learn though (unaware if this has been mentioned before), isn't there an audit trail implemented for transactions? That should make it possible to deal with any lost items in a highly automated way. From thomas.shikami at online.de Wed Apr 30 01:52:48 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed Apr 30 01:52:55 2008 Subject: [sldev] SL Database purge In-Reply-To: <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> Message-ID: <48183360.1050506@online.de> Argent Stonecutter wrote: > Even if it's in a box inside a box inside a box inside a box, N deep? Why should that be a problem? The Inventory system is non-recursive by design. Recursion cannot happen. If it happens, there's a big problem anyway From secret.argent at gmail.com Wed Apr 30 04:03:06 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 30 04:02:38 2008 Subject: [sldev] SL Database purge In-Reply-To: <4817EA99.2070905@gmx.net> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> Message-ID: <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> On 2008-04-29, at 22:42, Felix Duesenburg wrote: > Argent Stonecutter wrote: >> On 2008-04-29, at 13:33, Phoenix wrote: >>> We only intentionally remove unreferenced assets. This means that >>> it's >>> in no agent/task/region/etc inventory, and not even referenced via >>> uuid in a script state. >> >> Even if it's in a box inside a box inside a box inside a box, N deep? > That shouldn't make a difference to whether an asset key can be > found or > not. The box is really just a kind of reference, either in a > relational > database or in a directory structure. Indeed, but there are any number of ways that can be implemented that would make the reference to the contents of the box require checking an additional data structure, and even unpacking a serialized data structure. From kfa at gmx.net Wed Apr 30 04:47:31 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 30 04:47:36 2008 Subject: [sldev] SL Database purge In-Reply-To: <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> Message-ID: <48185C53.1040308@gmx.net> Argent Stonecutter wrote: > On 2008-04-29, at 22:42, Felix Duesenburg wrote: >> Argent Stonecutter wrote: >>> On 2008-04-29, at 13:33, Phoenix wrote: >>>> We only intentionally remove unreferenced assets. This means that it's >>>> in no agent/task/region/etc inventory, and not even referenced via >>>> uuid in a script state. >>> > >>> Even if it's in a box inside a box inside a box inside a box, N deep? > >> That shouldn't make a difference to whether an asset key can be found or >> not. The box is really just a kind of reference, either in a relational >> database or in a directory structure. > > Indeed, but there are any number of ways that can be implemented that > would make the reference to the contents of the box require checking an > additional data structure, and even unpacking a serialized data structure. > How do I explain this... Try to understand that what you see on the surface, e.g. a box seemingly hiding away something, is not the way how things are physically stored. The information about the asset itself and the information about its location are two completely different things, so different that they are /physically/ kept in separate places. The asset alone consists of a key and an attached file of various types and is most likely stored in a flat structure, e.g. a database table with the keys as index and the contents as blobs ('binary large objects' in MySQL), or simply as files in a folder with the key as filename (which is probably more efficient). The information about its location on the other hand requires a tree structure of some sophistication, since here we don't have just folders similar to the ones on your hard drive or SL inventory, but objects can also reside in-world or in the inventory of other objects. Nevertheless this is no hindrance to traversing the tree to any depth of nesting. I have previously implemented such structures for relational databases, but it's even cooler to do with links in UNIX-like file systems. It is really quite easy to search both parts for asset keys and make a comparison to see if either an asset itself or the info about its location has gone missing. This is done in two steps: - One, for all keys in the asset list, traverse the structure tree and see if you can find it. If there is at least one match, it has at least one instance living in someone's inventory or in-world, and everything is ok. If there is no match, the connection between the asset and its owner has somehow been lost, and this is the case being talked about above. - Two, traverse the structure tree and look up every key if you can find it in the asset list. If yes, ok, if not, we have a reference but no asset (inventory loss). Other than for backup or archiving, it makes no sense to serialize all this stuff as it would make searching really hard indeed, or a performance killer at least. I am of course not representing how LL has implemented all of this, because I have no knowledge about their internals. This is simply the most likely way how such a technology can be conceived, and I'm sure LL has opted for the solution that is the most efficient and suitable for the purpose. HTH, Felix From secret.argent at gmail.com Wed Apr 30 05:32:26 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 30 05:31:58 2008 Subject: [sldev] SL Database purge In-Reply-To: <48185C53.1040308@gmx.net> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> Message-ID: <45675031-4918-457C-930D-BE46E0948006@gmail.com> On 2008-04-30, at 06:47, Felix Duesenburg wrote: > How do I explain this... You don't have to. I'm not naive. I've written this kind of code myself. One of the things you have to deal with in this kind of code is circular references. In a sufficiently conservative garbage collector loops can prevent even unreferenced data from being collected: remember this old saw from the '70s? Reclaimer, spare that tree! Take not a single bit. It used to point to me, Now I'm protecting it! In a tree-walking collector, that doesn't happen, but on the other hand loops can hang the collector indefinitely. The operations on the SL database should prevent explicit loops from happening, but they're also inferring references from the contents of some assets, such as scripts, and database corruption can create the damndest structures. So what do you do? Well, one common solution is to simply cut off the walk after a certain distance. So... > The information about its location on the other hand requires a tree > structure of some sophistication, since here we don't have just > folders > similar to the ones on your hard drive or SL inventory, but objects > can > also reside in-world or in the inventory of other objects. > Nevertheless > this is no hindrance to traversing the tree to any depth of nesting. My question is not "can this be done" but "how far is this being done". > I am of course not representing how LL has implemented all of this, > because I have no knowledge about their internals. Neither do I, which is why I'm asking *them*. Because it's not clear that they are actually following all the references in all the data structures involved to the depth necessary. Every time I log in I get the message "Gesture is missing from the database", which means that somewhere, somewhen, they neglected to keep track of something that's not even nested at all. I've got another gesture where I can play every sound and animation in it, but the gesture itself fails. So I don't think it's unreasonable to ask. Do you, really? From thomas.shikami at online.de Wed Apr 30 05:46:05 2008 From: thomas.shikami at online.de (Thomas Shikami) Date: Wed Apr 30 05:46:12 2008 Subject: [sldev] SL Database purge In-Reply-To: <45675031-4918-457C-930D-BE46E0948006@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> Message-ID: <48186A0D.8050109@online.de> Argent Stonecutter wrote: > ... . The operations on the SL database should prevent explicit loops > from happening, but they're also inferring references from the > contents of some assets, such as scripts, and database corruption can > create the damndest structures. So what do you do? > > Well, one common solution is to simply cut off the walk after a > certain distance. So... The other way would be to keep a list of assets already scanned and another list of assets that are in use. The first pass would be to fill the list of assets in use from inventory and sim database. Then there will be as many passes as needed doing the following, search of assets used that aren't scanned yet. Scan them through and fill the list of assets in use. Add each scanned asset to the list of assets already scanned. Repeat until the list of assets already scanned and the list of assets in use match. With this algorithm, even repeats won't do any harm and box in box in box in box is scanned to any arbitrary depth. From kfa at gmx.net Wed Apr 30 06:52:37 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 30 06:52:45 2008 Subject: [sldev] SL Database purge In-Reply-To: <48186A0D.8050109@online.de> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <48186A0D.8050109@online.de> Message-ID: <481879A5.2070903@gmx.net> Thomas Shikami wrote: > Argent Stonecutter wrote: >> ... . The operations on the SL database should prevent explicit loops >> from happening, but they're also inferring references from the >> contents of some assets, such as scripts, and database corruption can >> create the damndest structures. So what do you do? >> >> Well, one common solution is to simply cut off the walk after a >> certain distance. So... > The other way would be to keep a list of assets already scanned and > another list of assets that are in use. The first pass would be to fill > the list of assets in use from inventory and sim database. Then there > will be as many passes as needed doing the following, search of assets > used that aren't scanned yet. Scan them through and fill the list of > assets in use. Add each scanned asset to the list of assets already > scanned. Repeat until the list of assets already scanned and the list of > assets in use match. With this algorithm, even repeats won't do any harm > and box in box in box in box is scanned to any arbitrary depth. Wash, rinse, repeat... ;) Ok, this is not meant to send LL recipes about how to do their job. That would mean the same as sending the French recipes how to make a croissant that doesn't crumble. But the guesswork comment about serializing triggered an explanation, not meaning to call anyone naive (sorry if it came across as such). It may have been misaddressed, but with the intent of also getting to those who started this thread by spreading badly researched rumours. Otherwise I would have replied off list. I am getting the missing gesture thing, too. However, I /do/ think it's unreasonable to suggest LL doesn't know how to do a proper search through a system that they created themselves. There is obviously a bug somewhere in the retrieval system, but it doesn't have to mean that all is lost. Or maybe it is. Who knows. What I find more disturbing is the fact that we ever had any case of inventory loss at all that could not be resolved. If you have a collection of assets that are worth anything to anyone, regardless whether measured in terms of money or otherwise, then you /should/ have a full audit trail recording all relevant transactions from the very beginning. If it ever happens that a link between an object and the information where/whom it belongs to gets lost, it can be restored upon request. (Unless the audit trail itself gets lost... which leads us to another kind of circular reference...) Such a system is obviously not in place, or it's not functioning properly (yet). What about the transaction history on the website, how does it look like at the backend? Could it be used to also record rezzing/unrezzing or other events, is that being considered or in development? I'd really care to learn more about what are the actual facts here, and I do believe that LL would get much less heat if this was addressed with the same openness that is applied in other contexts, and which always draws more praise than criticism even when things go wrong. Hope I didn't miss anything I should have read, but if so then too many others missed it as well. From marvin24 at gmx.de Wed Apr 30 07:42:08 2008 From: marvin24 at gmx.de (Marvin) Date: Wed Apr 30 07:42:16 2008 Subject: [sldev] slviewer, gcc-4.3 and scons >= 0.98 Message-ID: <200804301642.09130.marvin24@gmx.de> Hi, new Linux Distributions are coming up, so I tried to compile the viewer on openSUSE_Factory, which will be released soon. It comes with gcc-4.3 and also a new scons (0.98.2) package. Attached is a minimum build fix for 1.19.1.4 viewer (backported form 1.20 branch), which also includes a correction for SConstruct and scons. The newer scons version seems to have significant problems with dependencies. I'm not sure if this is a bug in scons or in the build-system. Has anyone also experiences with this version? Marvin -------------- next part -------------- A non-text attachment was scrubbed... Name: slviewer-1.19.1.4-fixes_for_gcc43.patch Type: text/x-diff Size: 1967 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/05a13fd1/slviewer-1.19.1.4-fixes_for_gcc43.bin From robin.cornelius at gmail.com Wed Apr 30 07:49:25 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 30 07:49:28 2008 Subject: [sldev] slviewer, gcc-4.3 and scons >= 0.98 In-Reply-To: <200804301642.09130.marvin24@gmx.de> References: <200804301642.09130.marvin24@gmx.de> Message-ID: On Wed, Apr 30, 2008 at 3:42 PM, Marvin wrote: > Hi, > > new Linux Distributions are coming up, so I tried to compile the viewer on > openSUSE_Factory, which will be released soon. It comes with gcc-4.3 and also > a new scons (0.98.2) package. > Attached is a minimum build fix for 1.19.1.4 viewer (backported form 1.20 > branch), which also includes a correction for SConstruct and scons. > The newer scons version seems to have significant problems with dependencies. > I'm not sure if this is a bug in scons or in the build-system. Has anyone > also experiences with this version? > I wouldn't go too mad fixing things for scons. It may be an idea checking out the cmake-8 branch, its reasonably upto date and apart from the -Wno-write-strings (VWR-4456) it will build/did build with gcc-4.3. If your going to invest any time with the build system and gcc compatibility throw it at cmake-8 (VWR-2871) the last i heard cmake was due to switch in any time now really but i assume its backed up behind 1.20.X, any updated estimates for going live? Robin From tofu.linden at lindenlab.com Wed Apr 30 07:58:03 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed Apr 30 07:57:54 2008 Subject: [sldev] slviewer, gcc-4.3 and scons >= 0.98 In-Reply-To: References: <200804301642.09130.marvin24@gmx.de> Message-ID: <481888FB.9080804@lindenlab.com> Robin Cornelius wrote: > If your going to invest any time with the build system and > gcc compatibility throw it at cmake-8 (VWR-2871) the last i heard > cmake was due to switch in any time now really but i assume its backed > up behind 1.20.X, any updated estimates for going live? It's still cycling through QA. I'm guessing it'll just miss 1.21, but will likely land before 1.22. From matthew.dowd at hotmail.co.uk Wed Apr 30 08:14:38 2008 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Apr 30 08:14:40 2008 Subject: [sldev] SL Database purge In-Reply-To: <48177062.5060504@lindenlab.com> References: <48167279.4090204@streamsense.net> <48177062.5060504@lindenlab.com> Message-ID: > As for things you don't have permissions to, as others > have already pointed out, this would be difficult to implement without > also making it easy to bypass permissions. This same dev time could (and > I believe should) be spent eliminating remaining and newly invented > causes of causes of content loss. Mmmm, this seems like a never ending bottomless pit of resource time. Given the complexity of the SL backend systems, given all the additional things outside of LL control (bugs in the underlying software such as MySQL, hardware failures, network problems/latency etc.) there must be literally thousands of unknown ways in which inventory loss might happen, many extremely difficult to reproduce. Every new update to the SL server code, every update to the network infrastructure etc. has the potential to add new content loss causes. Trying to pin down and fix every one sounds to me like trying to cut off all the heads of a hydra! Accepting that even after an infinite amount of development time, content loss would still inevitably happen, and implementing something to rectify the situation when it did, would, IMHO, be a better use of dev time. Dealing with permissions *is* an issue but there are quite a large number idea of how this might be solvable on the jira. Matthew _________________________________________________________________ Search and win with BigSnapSearch.com http://www.bigsnapsearch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/cf5b9c32/attachment.htm From gbrandon at gmail.com Wed Apr 30 09:38:45 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Apr 30 09:38:48 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object Message-ID: Hey everyone, I decided to look through the JIRA today for this long-standing issue with the official Second Life viewers. 1. Have three objects: - One with no group set - One set to group A - One set to group B 2. Select the object set to group A 3. Select the object with no group set. - Observe the edit window saying the object is set to group A 4. Select the object set to group B 5. Select the object with no group set - Observe the edit window saying the object is set to group B It appears this issue has been around for quite a while. I thought since there was no patch attached I'd encourage someone to write a patch. I'm not familiar with the code involved, but am assuming it's something small and great for someone who wants to submit their first very helpful patch :D Obviously the issue is huge and can cause disaster if you're trying to set your objects to the right group before changing land options. http://jira.secondlife.com/browse/VWR-3598 This issue cites group ownership but the issue I'm looking at affects the "active group" of objects. Since issues whose description match what I'm thinking of were marked as a duplicate of this one, I think this is the right issue. Good day everyone :D Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/f71e432d/attachment.htm From aimee at ama-zing.co.uk Wed Apr 30 10:25:28 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Apr 30 10:26:25 2008 Subject: [sldev] SL Database purge References: Message-ID: Has anyone thought to sweep under the server racks recently? Personally I think that's where all the lost inventory is ending up, I have visions of a big pile of lost hair and shoes at the bottom of each rack. Might even have made it to the server rooms' air con filters by now. Maybe they need to recruit some HVAC engineers to recover it all? That's where they're going wrong ... Aimee. (This is what lack of sleep does to me) > From tateru.nino at gmail.com Wed Apr 30 10:51:09 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 30 10:56:43 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object In-Reply-To: References: Message-ID: <4818B18D.4000300@weblogsinc.com> I thought there was already a patch for this a few months ago. Brandon Lockaby wrote: > Hey everyone, I decided to look through the JIRA today for this > long-standing issue with the official Second Life viewers. > > 1. Have three objects: > - One with no group set > - One set to group A > - One set to group B > 2. Select the object set to group A > 3. Select the object with no group set. > - Observe the edit window saying the object is set to group A > 4. Select the object set to group B > 5. Select the object with no group set > - Observe the edit window saying the object is set to group B > > It appears this issue has been around for quite a while. I thought > since there was no patch attached I'd encourage someone to write a > patch. I'm not familiar with the code involved, but am assuming it's > something small and great for someone who wants to submit their first > very helpful patch :D > > Obviously the issue is huge and can cause disaster if you're trying to > set your objects to the right group before changing land options. > > http://jira.secondlife.com/browse/VWR-3598 > This issue cites group ownership but the issue I'm looking at affects > the "active group" of objects. Since issues whose description match > what I'm thinking of were marked as a duplicate of this one, I think > this is the right issue. > > Good day everyone :D > > Brandon > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://www.massively.com/ From gwardell at gwsystemsdns.net Wed Apr 30 11:06:52 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Wed Apr 30 11:06:57 2008 Subject: [sldev] SL Database purge In-Reply-To: Message-ID: <017001c8aaec$f85b0ea0$a400000a@gwsystems2.com> Hi, Maybe for hair and shoes, but for the really value stuff, like diamond bling, it's the cat burglar. They need to hire Inspector Clouseau! Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Aimee Walton > Sent: Wed, April 30, 2008 1:25 PM > To: Second Life Developer Mailing List > Subject: Re: [sldev] SL Database purge > > > Has anyone thought to sweep under the server racks recently? > Personally I think that's where all the lost inventory is ending up, > I have visions of a big pile of lost hair and shoes at the bottom of > each rack. Might even have made it to the server rooms' air con > filters by now. Maybe they need to recruit some HVAC engineers to > recover it all? That's where they're going wrong ... > > Aimee. (This is what lack of sleep does to me) > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From aimee at ama-zing.co.uk Wed Apr 30 11:24:11 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Apr 30 11:24:18 2008 Subject: [sldev] SL Database purge In-Reply-To: <017001c8aaec$f85b0ea0$a400000a@gwsystems2.com> References: <017001c8aaec$f85b0ea0$a400000a@gwsystems2.com> Message-ID: <3AD7AD55-CDF1-4392-A05B-7ED08FF27DF8@ama-zing.co.uk> Personally I reckon Linden Lab have a black market racket going selling it all, this is where we should be looking for our lost inventory http://www.buysellloan.com/ ... fell off the back of a server, honest guv. ... and shouldn't that be a neko burglar? A. On Apr 30, 2008, at 19:06, Gary Wardell wrote: > Hi, > > Maybe for hair and shoes, but for the really value stuff, like > diamond bling, it's the cat burglar. They need to hire Inspector > Clouseau! > > Gary From tom at streamsense.net Wed Apr 30 11:36:26 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Apr 30 11:37:17 2008 Subject: [sldev] SL Database purge In-Reply-To: <48177062.5060504@lindenlab.com> References: <48167279.4090204@streamsense.net> <48177062.5060504@lindenlab.com> Message-ID: <4818BC2A.4070601@streamsense.net> Sean Lynch wrote: > So there are no assets still missing because of this particular event. Well, it does seem that an event that occured recently has purged a LOT of old inventory items, for many old avatars. A bunch of the rezzable guys are going nuts... Tom From darien_caldwell at comcast.net Wed Apr 30 12:23:59 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Wed Apr 30 12:24:01 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object Message-ID: <043020081923.27911.4818C74F00096FB600006D07221652796604040A990B040E0CA1020A079D0E0B@comcast.net> Yes, i've been fighting with this bug for awhile now. Have a number of my tenants asking about it too. I was hoping someone would report it eventually. I would have, but if I reported every bug I found, i would be in JIRA 24/7, and LL simply isn't paying me enough for that. :) (I would consider any serious offer however. ) -------------- Original message ---------------------- From: Tateru Nino > I thought there was already a patch for this a few months ago. > > Brandon Lockaby wrote: > > Hey everyone, I decided to look through the JIRA today for this > > long-standing issue with the official Second Life viewers. > > > > 1. Have three objects: > > - One with no group set > > - One set to group A > > - One set to group B > > 2. Select the object set to group A > > 3. Select the object with no group set. > > - Observe the edit window saying the object is set to group A > > 4. Select the object set to group B > > 5. Select the object with no group set > > - Observe the edit window saying the object is set to group B > > > > It appears this issue has been around for quite a while. I thought > > since there was no patch attached I'd encourage someone to write a > > patch. I'm not familiar with the code involved, but am assuming it's > > something small and great for someone who wants to submit their first > > very helpful patch :D > > > > Obviously the issue is huge and can cause disaster if you're trying to > > set your objects to the right group before changing land options. > > > > http://jira.secondlife.com/browse/VWR-3598 > > This issue cites group ownership but the issue I'm looking at affects > > the "active group" of objects. Since issues whose description match > > what I'm thinking of were marked as a duplicate of this one, I think > > this is the right issue. > > > > Good day everyone :D > > > > Brandon > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://www.massively.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robin.cornelius at gmail.com Wed Apr 30 12:37:26 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 30 12:37:26 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object In-Reply-To: <043020081923.27911.4818C74F00096FB600006D07221652796604040A990B040E0CA1020A079D0E0B@comcast.net> References: <043020081923.27911.4818C74F00096FB600006D07221652796604040A990B040E0CA1020A079D0E0B@comcast.net> Message-ID: <4818CA76.4010702@gmail.com> darien_caldwell@comcast.net wrote: > Yes, i've been fighting with this bug for awhile now. Have a number of my tenants asking about it too. I was hoping someone would report it eventually. I would have, but if I reported every bug I found, i would be in JIRA 24/7, and LL simply isn't paying me enough for that. :) (I would consider any serious offer however. ) > Is this VWR3605 - Object_group_display_not_properly_set_for_no-group_objects With patch attached. Any luck? Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/d3089bdd/signature.pgp From robin.cornelius at gmail.com Wed Apr 30 12:56:44 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Apr 30 12:56:54 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object In-Reply-To: <4818CA76.4010702@gmail.com> References: <043020081923.27911.4818C74F00096FB600006D07221652796604040A990B040E0CA1020A079D0E0B@comcast.net> <4818CA76.4010702@gmail.com> Message-ID: <4818CEFC.4040408@gmail.com> Robin Cornelius wrote: > darien_caldwell@comcast.net wrote: >> Yes, i've been fighting with this bug for awhile now. Have a number of my tenants asking about it too. I was hoping someone would report it eventually. I would have, but if I reported every bug I found, i would be in JIRA 24/7, and LL simply isn't paying me enough for that. :) (I would consider any serious offer however. ) >> > Is this VWR3605 - Object_group_display_not_properly_set_for_no-group_objects > > With patch attached. > > Any luck? > In the best possible etiquette i'm replying to myself *again*;-) Just tested official 1.20 RC and the reported behaviour of the last object group selected being displayed on the next no group selected object is indeed present. In my build (with the patch from VWR3605) it displays "no group" on a groupless object no matter the edit/selection order so looks like this is indeed the correct solution. Vote +1 for 3605's patch Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/d254baa9/signature.pgp From gigstaggart at gmail.com Wed Apr 30 13:33:55 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 30 13:33:58 2008 Subject: [sldev] SL Database purge In-Reply-To: <48185C53.1040308@gmx.net> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> Message-ID: <4818D7B3.5020007@gmail.com> Felix Duesenburg wrote: > and is most likely stored in a flat structure, e.g. a database table > with the keys as index and the contents as blobs ('binary large objects' > in MySQL), or simply as files in a folder with the key as filename > (which is probably more efficient). > It's the latter. The opensim people I heard went the former way, which is incredibly short sighted and stupid. I'd like to see mySQL with hundreds of TB of binary blobs! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/2a26568e/smime.bin From gigstaggart at gmail.com Wed Apr 30 13:35:44 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Apr 30 13:35:46 2008 Subject: [sldev] SL Database purge In-Reply-To: <45675031-4918-457C-930D-BE46E0948006@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> Message-ID: <4818D820.4060504@gmail.com> Argent Stonecutter wrote: > In a tree-walking collector, that doesn't happen, but on the other > hand loops can hang the collector indefinitely. The operations on the > SL database should prevent explicit loops from happening, but they're > also inferring references from the contents of some assets, such as > scripts, and database corruption can create the damndest structures. > So what do you do? The tortoise and hare algorithm works extremely well for loop detection. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3253 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/adad6960/smime.bin From darien_caldwell at comcast.net Wed Apr 30 13:39:51 2008 From: darien_caldwell at comcast.net (darien_caldwell@comcast.net) Date: Wed Apr 30 13:40:00 2008 Subject: [sldev] Objects not set to group appear to be set to the group of the last selected object Message-ID: <043020082039.17677.4818D916000F1F5D0000450D221557547404040A990B040E0CA1020A079D0E0B@comcast.net> Yes, it looks like someone has linked your JIRA to VWR-3598, which was already open. Probably should indicate there that yours has a patch for the issue. -------------- Original message ---------------------- From: Robin Cornelius In the best possible etiquette i'm replying to myself *again*;-) Just tested official 1.20 RC and the reported behaviour of the last object group selected being displayed on the next no group selected object is indeed present. In my build (with the patch from VWR3605) it displays "no group" on a groupless object no matter the edit/selection order so looks like this is indeed the correct solution. -------------- next part -------------- An embedded message was scrubbed... From: Robin Cornelius Subject: Re: [sldev] Objects not set to group appear to be set to the group of the last selected object Date: Wed, 30 Apr 2008 19:57:01 +0000 Size: 2075 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/1c29a965/attachment-0001.eml From dahliatrimble at gmail.com Wed Apr 30 13:57:40 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Apr 30 13:57:44 2008 Subject: [sldev] SL Database purge In-Reply-To: <4818D820.4060504@gmail.com> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> Message-ID: >From what I've seen of Opensim, there are several optional asset storage mechanisms available that can be chosen in a configuration file. It's also open source so an interested party could define a new mechanism and plug it in if one wished. I don't have much faith in the "files in a folder" approach as from what I remember from my operating system class (quite a while ago), filename searches are linear searches. On Wed, Apr 30, 2008 at 1:35 PM, Jason Giglio wrote: > Argent Stonecutter wrote: > > In a tree-walking collector, that doesn't happen, but on the other > > hand loops can hang the collector indefinitely. The operations on the > > SL database should prevent explicit loops from happening, but they're > > also inferring references from the contents of some assets, such as > > scripts, and database corruption can create the damndest structures. > > So what do you do? > > The tortoise and hare algorithm works extremely well for loop detection. > > -Jason > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/86bb25c4/attachment.htm From gwardell at gwsystemsdns.net Wed Apr 30 14:16:34 2008 From: gwardell at gwsystemsdns.net (Gary Wardell) Date: Wed Apr 30 14:16:41 2008 Subject: [sldev] SL Database purge In-Reply-To: Message-ID: <01ae01c8ab07$78773c20$a400000a@gwsystems2.com> Hi, That all depends on the operating system. Some use a b-tree. There is also the theory that an OS should be very fast at finding and opening files since that's part of it's job. OTOH, storing a blob in a row can slow down a database if it has to retrieve a row with a blob in it even though the blob is not being used. Gary -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Dahlia Trimble Sent: Wed, April 30, 2008 4:58 PM To: Jason Giglio; sldev Subject: Re: [sldev] SL Database purge From what I've seen of Opensim, there are several optional asset storage mechanisms available that can be chosen in a configuration file. It's also open source so an interested party could define a new mechanism and plug it in if one wished. I don't have much faith in the "files in a folder" approach as from what I remember from my operating system class (quite a while ago), filename searches are linear searches. On Wed, Apr 30, 2008 at 1:35 PM, Jason Giglio wrote: Argent Stonecutter wrote: > In a tree-walking collector, that doesn't happen, but on the other > hand loops can hang the collector indefinitely. The operations on the > SL database should prevent explicit loops from happening, but they're > also inferring references from the contents of some assets, such as > scripts, and database corruption can create the damndest structures. > So what do you do? The tortoise and hare algorithm works extremely well for loop detection. -Jason _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/2ff2c1c5/attachment.htm From kfa at gmx.net Wed Apr 30 14:22:49 2008 From: kfa at gmx.net (Felix Duesenburg) Date: Wed Apr 30 14:22:56 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> Message-ID: <4818E329.3020903@gmx.net> Dahlia Trimble wrote: >> >From what I've seen of Opensim, there are several optional asset storage > mechanisms available that can be chosen in a configuration file. It's also > open source so an interested party could define a new mechanism and plug it > in if one wished. > > I don't have much faith in the "files in a folder" approach as from what I > remember from my operating system class (quite a while ago), filename > searches are linear searches. > File systems vary widely in their efficiency or suitability for any specific purpose. I'd like to think that we're living on Reiser4 here, which challenges the distinction between a database and a file system. Such a shame how it suffers from its creator's dire circumstances at the moment. From robla at lindenlab.com Wed Apr 30 15:39:34 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Apr 30 15:39:46 2008 Subject: [sldev] Google Summer of Code 2008 update Message-ID: <4818F526.8030704@lindenlab.com> Hi everyone, Google announced the accepted proposals last week for Google Summer of Code. As you might have seen, a couple of proposals for Second Life viewer applications were accepted: Alexander Yuan's proposal for screen-space ambient occlusion (VWR-6975) and Ravish Mehra's proposal for implementing a C++ library for per-pixel displacement mapping (VWR-6976). More information on these proposals can be found here: https://wiki.secondlife.com/wiki/Google_SoC_2008 Please join me in congratulating them, and welcoming their contribution to Second Life! Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/26c6f5dd/signature.pgp From carjay at gmx.net Wed Apr 30 16:06:26 2008 From: carjay at gmx.net (Carsten Juttner) Date: Wed Apr 30 16:06:39 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <4818F526.8030704@lindenlab.com> References: <4818F526.8030704@lindenlab.com> Message-ID: <4818FB72.7080306@gmx.net> Rob Lanphier wrote: > Please join me in congratulating them, and welcoming their > contribution to Second Life! *joins* *congrats* So, where are the refreshments? :) The proposals sound highly interesting, it will be interesting to see what SSAO may add to the viewer. Are the students reading the list? Regards, Carsten From steve at lindenlab.com Wed Apr 30 16:23:18 2008 From: steve at lindenlab.com (Steve) Date: Wed Apr 30 16:21:50 2008 Subject: [sldev] cygwin flex lscript_compile workaround Message-ID: <4818FF66.9040505@lindenlab.com> I'm not sure whether this has already been addressed here, but we discovered a problem with the latest version of Cygwin flex and lscript_compile and I thought I would share the workaround. We've committed the workaround to our release-candidate branche so it should be in an upcoming source drop as well. 1. Add "YY_NO_UNISTD_H" to the list of Preprocessor Definitions in the lscript_compile project file. 2. Apply the following patch it indra.l: Index: indra.l =================================================================== --- indra.l (revision 86342) +++ indra.l (revision 86343) @@ -12,6 +12,7 @@ #include "linden_common.h" // Deal with the fact that lex/yacc generates unreachable code #ifdef LL_WINDOWS +#pragma warning (disable : 4018) // warning C4018: signed/unsigned mismatch #pragma warning (disable : 4702) // warning C4702: unreachable code #endif // LL_WINDOWS #include "llmath.h" @@ -44,7 +45,10 @@ #define YYLMAX 16384 #define YY_NEVER_INTERACTIVE 1 /* stops flex from calling isatty() */ - +#ifdef LL_WINDOWS +#define isatty(x) 0 /* hack for bug in cygwin flex 2.5.35 */ +#endif + #ifdef ECHO #undef ECHO #endif From danteferret at gmail.com Wed Apr 30 16:49:42 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Apr 30 16:49:45 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <4818F526.8030704@lindenlab.com> References: <4818F526.8030704@lindenlab.com> Message-ID: <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> My understanding of SSAO is that it would fix the awful things windlight has done to indoor areas. Is this correct? On Wed, Apr 30, 2008 at 6:39 PM, Rob Lanphier wrote: > Hi everyone, > > Google announced the accepted proposals last week for Google Summer of > Code. As you might have seen, a couple of proposals for Second Life viewer > applications were accepted: Alexander Yuan's proposal for screen-space > ambient occlusion (VWR-6975) and Ravish Mehra's proposal for implementing a > C++ library for per-pixel displacement mapping (VWR-6976). > > More information on these proposals can be found here: > https://wiki.secondlife.com/wiki/Google_SoC_2008 > > Please join me in congratulating them, and welcoming their contribution to > Second Life! > > Rob > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/e38f2b96/attachment.htm From aimee at ama-zing.co.uk Wed Apr 30 17:25:45 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Wed Apr 30 17:25:51 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <4818F526.8030704@lindenlab.com> References: <4818F526.8030704@lindenlab.com> Message-ID: <8880E48E-8D0E-4BA9-9AEE-D00A5C45F758@ama-zing.co.uk> On Apr 30, 2008, at 23:39, Rob Lanphier wrote: > > Please join me in congratulating them, and welcoming their > contribution to Second Life! Definitely, congratulations and best wishes to those involved if they are reading here, look forward to seeing the results :) Aimee. From secret.argent at gmail.com Wed Apr 30 19:09:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 30 19:09:12 2008 Subject: [sldev] SL Database purge In-Reply-To: <4818E329.3020903@gmx.net> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> <4818E329.3020903@gmx.net> Message-ID: <9FEB0137-CB9E-498A-BE8B-7647900B8C2B@gmail.com> Gah, if you're worried about asset loss the last thing you want to do is put your assets in a Reiser4 file system. o_O From secret.argent at gmail.com Wed Apr 30 19:15:09 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Apr 30 19:14:37 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> Message-ID: On 2008-04-30, at 18:49, Dante Tucker wrote: > My understanding of SSAO is that it would fix the awful things > windlight has done to indoor areas. Is this correct? I don't think so. At least it's unrelated to my proposal to increase ambient illumination and reduce directional illumination for objects hidden from the *sun*. This proposal would reduce ambient illumination for objects hidden from the sky, making them darker. This may actually increase the effect of the Windlight lighting changes if they're not careful. From seg at haxxed.com Wed Apr 30 19:52:20 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed Apr 30 19:52:25 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> Message-ID: <1209610340.4950.92.camel@localhost> On Wed, 2008-04-30 at 13:57 -0700, Dahlia Trimble wrote: > I don't have much faith in the "files in a folder" approach as from > what I remember from my operating system class (quite a while ago), > filename searches are linear searches. Implementation dependent. ext3 has hashed directory lookups these days, among others. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080430/5b75f8ea/attachment.pgp From davep at lindenlab.com Wed Apr 30 21:25:24 2008 From: davep at lindenlab.com (Dave Parks) Date: Wed Apr 30 21:25:31 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> Message-ID: <48194634.6070207@lindenlab.com> You're mixing direct lighting and ambient occlusion. Ambient occlusion is the approximation of shadows that would be generated if light was coming from all directions. Direct shadowing (creating shadows from the sun) is done with hardware shadow maps, which complements SSAO very well but is a totally separate technique. That, too, is being researched internally with some good results, but it's too early to promise anything, so here's a picture you can take how you will: http://picasaweb.google.com/Runitai/DeferredRendering/photo#5192943343115923442 Argent Stonecutter wrote: > On 2008-04-30, at 18:49, Dante Tucker wrote: >> My understanding of SSAO is that it would fix the awful things >> windlight has done to indoor areas. Is this correct? > > I don't think so. At least it's unrelated to my proposal to increase > ambient illumination and reduce directional illumination for objects > hidden from the *sun*. This proposal would reduce ambient illumination > for objects hidden from the sky, making them darker. This may actually > increase the effect of the Windlight lighting changes if they're not > careful. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From poppy at lindenlab.com Wed Apr 30 21:41:04 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Wed Apr 30 21:40:53 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: <48194634.6070207@lindenlab.com> References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> <48194634.6070207@lindenlab.com> Message-ID: <481949E0.905@lindenlab.com> Dave Parks wrote: > http://picasaweb.google.com/Runitai/DeferredRendering/photo#5192943343115923442 i cannot emphasize enough how hot this is. + poppy From Celierra at gmail.com Wed Apr 30 22:47:49 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Apr 30 22:47:51 2008 Subject: [sldev] Google Summer of Code 2008 update In-Reply-To: References: <4818F526.8030704@lindenlab.com> <4d211a610804301649n293938b1p66d8fbc43ace822e@mail.gmail.com> Message-ID: Thanks for the congrats! ^^ On Wed, Apr 30, 2008 at 10:15 PM, Argent Stonecutter wrote: > On 2008-04-30, at 18:49, Dante Tucker wrote: > > > My understanding of SSAO is that it would fix the awful things windlight > has done to indoor areas. Is this correct? > > > > I don't think so. At least it's unrelated to my proposal to increase > ambient illumination and reduce directional illumination for objects hidden > from the *sun*. This proposal would reduce ambient illumination for objects > hidden from the sky, making them darker. This may actually increase the > effect of the Windlight lighting changes if they're not careful. > It depends on exactly what "awful things" are being referred to, but whatever-it-is probably is due to direct lighting from the sun/moon penetrating the walls (as Argent said). You'd need shadows to get rid of that. Those other e-mails show what's going on at LL with shadows, though. :) An exception, I think, is the ambient light turning red at sunset - red ambient light looks odd indoors. But plain SSAO wouldn't be smart enough to change the color of indoor ambient lighting vs. outdoor ambient lighting. The way I think of it, ambient occlusion brings out details on objects by darkening crowded areas of the object (i.e. creases, folds, nearby surfaces...anything which blocks the sky from the vantage point of the surface). One'd think this would help out with some Windlight overexposure or lack-of-detail problems, but that's only if it's due to too much ambient light - I've only really seen overexposure near sunset and on surfaces facing near the sun, and that is due to the intense sun at that time (i.e., direct lighting is the culprit). Ambient light is brightest mid-day, and that time seems to be okay. I'm not sure if this is the same pitfall as what Argent was referring to, but I noticed that bringing out creases could be bad in some cases if those creases aren't intended to be seen, like in some older furry avs made of ellipsoids. In particular, I recall the pictures at http://jira.secondlife.com/browse/VWR-3537 - though these creases appear due to direct lighting I think, and the contrast between some surfaces is huge because those surfaces are oriented very differently in relation to the sun. I haven't figured out or proposed any way of handling this sort of thing, but wei're personally leaning towards arguing to leave it behind, in favor of accurate lighting and to allow more-exact building going forward. (This opinion might change, of course...) Hope that helps? :) Sorry that it wasn't what was expected... -- ~Alex and Cel From tateru.nino at gmail.com Wed Apr 30 23:22:57 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Apr 30 23:28:27 2008 Subject: [sldev] SL Database purge In-Reply-To: <1209610340.4950.92.camel@localhost> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> <1209610340.4950.92.camel@localhost> Message-ID: <481961C1.7010800@weblogsinc.com> Callum Lerwick wrote: > On Wed, 2008-04-30 at 13:57 -0700, Dahlia Trimble wrote: > >> I don't have much faith in the "files in a folder" approach as from >> what I remember from my operating system class (quite a while ago), >> filename searches are linear searches. >> > > Implementation dependent. ext3 has hashed directory lookups these days, > among others. > All a filesystem is is a specialized form of database. There's nothing magical about databases. -- Tateru Nino http://www.massively.com/ From dahliatrimble at gmail.com Wed Apr 30 23:52:52 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Apr 30 23:52:54 2008 Subject: [sldev] SL Database purge In-Reply-To: <1209610340.4950.92.camel@localhost> References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> <1209610340.4950.92.camel@localhost> Message-ID: guess I'm showing my age :( A little web searching reveals that ext3 does appear to have some optional indexed directory capabilities. I've *heard* that the LL sims are running on 64 bit debian linux... perhaps the asset servers are too? On Wed, Apr 30, 2008 at 7:52 PM, Callum Lerwick wrote: > On Wed, 2008-04-30 at 13:57 -0700, Dahlia Trimble wrote: > > I don't have much faith in the "files in a folder" approach as from > > what I remember from my operating system class (quite a while ago), > > filename searches are linear searches. > > Implementation dependent. ext3 has hashed directory lookups these days, > among others. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080430/56964ad5/attachment.htm From tom at streamsense.net Wed Apr 30 23:53:42 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Apr 30 23:53:58 2008 Subject: [sldev] SL Database purge In-Reply-To: References: <48167279.4090204@streamsense.net> <4D5E2A05-C46E-4586-A745-745422AE0E61@secondlife.com> <7912990B-A416-46D1-9710-A4C8BA48C05C@gmail.com> <4817EA99.2070905@gmx.net> <7159E029-A41E-4CA3-9816-B7E0E90084C2@gmail.com> <48185C53.1040308@gmx.net> <45675031-4918-457C-930D-BE46E0948006@gmail.com> <4818D820.4060504@gmail.com> <1209610340.4950.92.camel@localhost> Message-ID: <481968F6.7020700@streamsense.net> Dahlia Trimble wrote: > guess I'm showing my age :( A little web searching reveals that ext3 > does appear to have some optional indexed directory capabilities. > I've *heard* that the LL sims are running on 64 bit debian linux... > perhaps the asset servers are too? > Nay, linden equipment is running Windows 3.11 for Workgroups