From darien.caldwell at gmail.com Fri Mar 1 08:54:00 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri, 1 Mar 2013 08:54:00 -0800 Subject: [opensource-dev] DirectX SDK update: should we use it ? In-Reply-To: <20130227200919.0f266ba1.sldev@free.fr> References: <20130227200919.0f266ba1.sldev@free.fr> Message-ID: This is being offered to all Windows 7 Users, not just developers. Reading deeper here: http://msdn.microsoft.com/library/windows/apps/jj863687.aspx It's mostly backporting new features from Windows 8 to Windows 7. That's why they say you'll need the newer SDK, to take advantage of those new features. There's a lot of Win 8 features that are unsupported on Win 7 of course. But I only see one specific case of breakage mentioned: "For developers currently working on applications in Microsoft Visual Studio 2010 or earlier using the *D3D11_CREATE_DEVICE_DEBUG*flag, be aware that calls to *D3D11CreateDevice*will fail. This is because the D3D11.1 runtime now requires D3D11_1SDKLayers.dll instead of D3D11SDKLayers.dll. To get this new DLL (D3D11_1SDKLayers.dll), install the Windows 8 SDK, or Visual Studio 2012 , or the Visual Studio 2012 remote debugging tools. See the Debug Layerdocumentation for more info. You can download Visual Studio 2012 remote debugging tools from either of these links:" Basically it's all centered around D3D11, which I really doubt LL's viewer is using. I'd say it's safe to upgrade, as long as you don't plan on writing D3D11 apps. Of course I'm not exactly sure what parts of D3D the viewer is using, I was always under the impression it used OpenGL. On Wed, Feb 27, 2013 at 11:09 AM, Henri Beauchamp wrote: > Greetings, > > Today, Windows Update proposed me this update: > http://support.microsoft.com/kb/2670838 > > I was well inspired to follow the "Find out more about this update" > link, because in the explanation page, they state: > > "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX > Software Development Kit (SDK), you will have to update your development > environments after you install this platform update." > > And the June 2010 DirectX SDK is precisely used by the viewer... > > Not being a Windows guru, I don't know whether applying the proposed > update and updating to the Windows 8 SDK (which is listed among the > possible solutions) is a good idea or not: will it break the viewer > builds ?... If not, will the viewer builds still work under Windows XP, > Vista and 7 ?... Couldn't we simply get entirely rid of the DirectX > calls in the Windows viewer builds ? > > Any thought about this ? > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/aa2ecb8e/attachment.htm From liny.odell at phoenixviewer.com Fri Mar 1 09:01:05 2013 From: liny.odell at phoenixviewer.com (Liny Odell) Date: Fri, 1 Mar 2013 09:01:05 -0800 Subject: [opensource-dev] DirectX SDK update: should we use it ? In-Reply-To: References: <20130227200919.0f266ba1.sldev@free.fr> Message-ID: On Fri, Mar 1, 2013 at 8:54 AM, Darien Caldwell wrote: > This is being offered to all Windows 7 Users, not just developers. Reading > deeper here: > > http://msdn.microsoft.com/library/windows/apps/jj863687.aspx > > It's mostly backporting new features from Windows 8 to Windows 7. That's why > they say you'll need the newer SDK, to take advantage of those new features. > There's a lot of Win 8 features that are unsupported on Win 7 of course. But > I only see one specific case of breakage mentioned: > > "For developers currently working on applications in Microsoft Visual Studio > 2010 or earlier using the D3D11_CREATE_DEVICE_DEBUG flag, be aware that > calls to D3D11CreateDevice will fail. This is because the D3D11.1 runtime > now requires D3D11_1SDKLayers.dll instead of D3D11SDKLayers.dll. To get this > new DLL (D3D11_1SDKLayers.dll), install the Windows 8 SDK, or Visual Studio > 2012, or the Visual Studio 2012 remote debugging tools. See the Debug Layer > documentation for more info. You can download Visual Studio 2012 remote > debugging tools from either of these links:" > > Basically it's all centered around D3D11, which I really doubt LL's viewer > is using. I'd say it's safe to upgrade, as long as you don't plan on writing > D3D11 apps. Of course I'm not exactly sure what parts of D3D the viewer is > using, I was always under the impression it used OpenGL. > > > > On Wed, Feb 27, 2013 at 11:09 AM, Henri Beauchamp wrote: >> >> Greetings, >> >> Today, Windows Update proposed me this update: >> http://support.microsoft.com/kb/2670838 >> >> I was well inspired to follow the "Find out more about this update" >> link, because in the explanation page, they state: >> >> "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX >> Software Development Kit (SDK), you will have to update your development >> environments after you install this platform update." >> >> And the June 2010 DirectX SDK is precisely used by the viewer... >> >> Not being a Windows guru, I don't know whether applying the proposed >> update and updating to the Windows 8 SDK (which is listed among the >> possible solutions) is a good idea or not: will it break the viewer >> builds ?... If not, will the viewer builds still work under Windows XP, >> Vista and 7 ?... Couldn't we simply get entirely rid of the DirectX >> calls in the Windows viewer builds ? >> >> Any thought about this ? >> >> Henri. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges You are correct on assuming the viewer uses openGL. The only parts of the viewer that use directx is for getting the GPU make and memory ammount. But, seeing as directx is windows only, for linux X's log file is instead scraped for the same info and mac, well, id have to dig through that code again to remember how its getting the info there. As for solaris (does the viewer even build on that anymore?) its probably the same as linux. From sldev at free.fr Fri Mar 1 10:11:51 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 1 Mar 2013 19:11:51 +0100 Subject: [opensource-dev] DirectX SDK update: should we use it ? In-Reply-To: References: <20130227200919.0f266ba1.sldev@free.fr> Message-ID: <20130301191151.7cb909fc.sldev@free.fr> On Fri, 1 Mar 2013 08:54:00 -0800, Darien Caldwell wrote: > This is being offered to all Windows 7 Users, not just developers. Reading > deeper here: > > http://msdn.microsoft.com/library/windows/apps/jj863687.aspx > > It's mostly backporting new features from Windows 8 to Windows 7. That's > why they say you'll need the newer SDK, to take advantage of those new > features. So can we safely apply this update and keep using the June 2010 DirectX SDK to build the viewer, and still get working builds on "all" (WinXP SP3 and newer) Windows versions ?... I doubt it, since they say: "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX Software Development Kit (SDK), you will have to update your development environments after you install this platform update. The following development .dll files that are associated with the DirectX SDK are incompatible with this platform update: D3D10SDKLayers.dll D3D11SDKLayers.dll D3D10ref.dll D2D1debug.dll You can use one of the following applications or tools to update these .dll files: - The Windows 8 SDK: This SDK updates the current development environment with new headers, libs, and tools. This includes the previously-listed development .dll files. This update does not update the C or C++ compilers or the IDE, but this update does enable developers to integrate the new features of the platform update into their applications. " So, this solution implies that we also update the "Windows SDK for Windows 7 and .NET Framework 4" that is used to build the viewer with VS2010, with the "Windows 8 SDK": won't it break the viewer builds ?... Does it at all got a single chance to keep working with the VC++ 2010 compiler ? Second propsed solution: " - Microsoft Visual Studio 2012: This application includes the Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers. .../... " Here, I bet the viewer won't compile under VS2012, and I heard that anything compiled with compilers newer than VS2010 is incompatible with Windows XP... Third propose solution: " - Remote Tools for Visual Studio 2012: These tools are the minimum requirement in order to continue using the Direct3D debug layer. These tools update only the previously-listed development .dll files. These tools do not enable developers to integrate the new features of the platform update into their applications. These tools are available in the "Remote Tools for Visual Studio 2012" section of the Visual Studio Download Center, or can be downloaded from the following links. These packages can be safely installed on development systems: " Is it the right thing to do ?... I don't know. Any clue ? > Basically it's all centered around D3D11, which I really doubt LL's > viewer is using. .../... Of course I'm not exactly sure what parts > of D3D the viewer is using, I was always under the impression it used > OpenGL. OpenGL is used for the rendering. D3D is only used for the graphics card detection at startup... So if someone could find a way to use another detection mechanism, we could get fully rid of the D3D calls in the viewer code. Henri. From desmoulins.uchi at googlemail.com Fri Mar 1 10:30:58 2013 From: desmoulins.uchi at googlemail.com (Niran) Date: Fri, 1 Mar 2013 19:30:58 +0100 Subject: [opensource-dev] DirectX SDK update: should we use it ? In-Reply-To: <20130301191151.7cb909fc.sldev@free.fr> References: <20130227200919.0f266ba1.sldev@free.fr> <20130301191151.7cb909fc.sldev@free.fr> Message-ID: "Here, I bet the viewer won't compile under VS2012" Singularity is compiled with VS2012 if i remember correct 2013/3/1 Henri Beauchamp > On Fri, 1 Mar 2013 08:54:00 -0800, Darien Caldwell wrote: > > > This is being offered to all Windows 7 Users, not just developers. > Reading > > deeper here: > > > > http://msdn.microsoft.com/library/windows/apps/jj863687.aspx > > > > It's mostly backporting new features from Windows 8 to Windows 7. That's > > why they say you'll need the newer SDK, to take advantage of those new > > features. > > So can we safely apply this update and keep using the June 2010 DirectX > SDK to build the viewer, and still get working builds on "all" (WinXP SP3 > and newer) Windows versions ?... I doubt it, since they say: > > "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX > Software Development Kit (SDK), you will have to update your development > environments after you install this platform update. The following > development .dll files that are associated with the DirectX SDK are > incompatible with this platform update: > > D3D10SDKLayers.dll > D3D11SDKLayers.dll > D3D10ref.dll > D2D1debug.dll > > You can use one of the following applications or tools to update these > .dll files: > > - The Windows 8 SDK: This SDK updates the current development > environment with new headers, libs, and tools. This includes the > previously-listed development .dll files. This update does not > update the C or C++ compilers or the IDE, but this update does > enable developers to integrate the new features of the platform > update into their applications. > " > > So, this solution implies that we also update the "Windows SDK for > Windows 7 and .NET Framework 4" that is used to build the viewer with > VS2010, with the "Windows 8 SDK": won't it break the viewer builds ?... > Does it at all got a single chance to keep working with the VC++ 2010 > compiler ? > > Second propsed solution: > > " > - Microsoft Visual Studio 2012: This application includes the > Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers. > .../... > " > > Here, I bet the viewer won't compile under VS2012, and I heard that > anything compiled with compilers newer than VS2010 is incompatible > with Windows XP... > > Third propose solution: > > " > - Remote Tools for Visual Studio 2012: These tools are the minimum > requirement in order to continue using the Direct3D debug layer. > These tools update only the previously-listed development .dll files. > These tools do not enable developers to integrate the new features of > the platform update into their applications. These tools are available > in the "Remote Tools for Visual Studio 2012" section of the Visual > Studio Download Center, or can be downloaded from the following > links. These packages can be safely installed on development systems: > " > > Is it the right thing to do ?... I don't know. Any clue ? > > > Basically it's all centered around D3D11, which I really doubt LL's > > viewer is using. .../... Of course I'm not exactly sure what parts > > of D3D the viewer is using, I was always under the impression it used > > OpenGL. > > OpenGL is used for the rendering. D3D is only used for the graphics > card detection at startup... So if someone could find a way to use > another detection mechanism, we could get fully rid of the D3D calls > in the viewer code. > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/54899bca/attachment.htm From latifer at streamgrid.net Fri Mar 1 12:21:36 2013 From: latifer at streamgrid.net (Latif Khalifa) Date: Fri, 1 Mar 2013 21:21:36 +0100 Subject: [opensource-dev] DirectX SDK update: should we use it ? In-Reply-To: References: <20130227200919.0f266ba1.sldev@free.fr> <20130301191151.7cb909fc.sldev@free.fr> Message-ID: No, Singularity is compiled with VS2010. Upgrading compiler version is PITA because it means that some (most?) prebuild libraries would need recompiling too. It's probably safe to ignore this warning as the viewer doesn't use D3D at all, and only functions used from DirectX are, as Liny pointed out, those used to get driver info. On Fri, Mar 1, 2013 at 7:30 PM, Niran wrote: > "Here, I bet the viewer won't compile under VS2012" > > Singularity is compiled with VS2012 if i remember correct > > 2013/3/1 Henri Beauchamp >> >> On Fri, 1 Mar 2013 08:54:00 -0800, Darien Caldwell wrote: >> >> > This is being offered to all Windows 7 Users, not just developers. >> > Reading >> > deeper here: >> > >> > http://msdn.microsoft.com/library/windows/apps/jj863687.aspx >> > >> > It's mostly backporting new features from Windows 8 to Windows 7. That's >> > why they say you'll need the newer SDK, to take advantage of those new >> > features. >> >> So can we safely apply this update and keep using the June 2010 DirectX >> SDK to build the viewer, and still get working builds on "all" (WinXP SP3 >> and newer) Windows versions ?... I doubt it, since they say: >> >> "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX >> Software Development Kit (SDK), you will have to update your development >> environments after you install this platform update. The following >> development .dll files that are associated with the DirectX SDK are >> incompatible with this platform update: >> >> D3D10SDKLayers.dll >> D3D11SDKLayers.dll >> D3D10ref.dll >> D2D1debug.dll >> >> You can use one of the following applications or tools to update these >> .dll files: >> >> - The Windows 8 SDK: This SDK updates the current development >> environment with new headers, libs, and tools. This includes the >> previously-listed development .dll files. This update does not >> update the C or C++ compilers or the IDE, but this update does >> enable developers to integrate the new features of the platform >> update into their applications. >> " >> >> So, this solution implies that we also update the "Windows SDK for >> Windows 7 and .NET Framework 4" that is used to build the viewer with >> VS2010, with the "Windows 8 SDK": won't it break the viewer builds ?... >> Does it at all got a single chance to keep working with the VC++ 2010 >> compiler ? >> >> Second propsed solution: >> >> " >> - Microsoft Visual Studio 2012: This application includes the >> Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers. >> .../... >> " >> >> Here, I bet the viewer won't compile under VS2012, and I heard that >> anything compiled with compilers newer than VS2010 is incompatible >> with Windows XP... >> >> Third propose solution: >> >> " >> - Remote Tools for Visual Studio 2012: These tools are the minimum >> requirement in order to continue using the Direct3D debug layer. >> These tools update only the previously-listed development .dll files. >> These tools do not enable developers to integrate the new features of >> the platform update into their applications. These tools are available >> in the "Remote Tools for Visual Studio 2012" section of the Visual >> Studio Download Center, or can be downloaded from the following >> links. These packages can be safely installed on development systems: >> " >> >> Is it the right thing to do ?... I don't know. Any clue ? >> >> > Basically it's all centered around D3D11, which I really doubt LL's >> > viewer is using. .../... Of course I'm not exactly sure what parts >> > of D3D the viewer is using, I was always under the impression it used >> > OpenGL. >> >> OpenGL is used for the rendering. D3D is only used for the graphics >> card detection at startup... So if someone could find a way to use >> another detection mechanism, we could get fully rid of the D3D calls >> in the viewer code. >> >> Henri. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges From nyx at lindenlab.com Fri Mar 1 13:20:10 2013 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 1 Mar 2013 16:20:10 -0500 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 Added a new parameter to shapes to replace the viewer-side height offset. Since it is stored in a wearable, the new back end can read and use the value. Will send an email to third party devs later today to let them know to pick up the patch. Marking SUN-38 as resolved. -Nyx On Sun, Feb 24, 2013 at 11:46 PM, Ricky wrote: > I know this thread has gotten completely OT, but I feel I should respond > to the feeling of dissatisfaction. > > I contribute to help me. I know that not everything I contribute will be > accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I > created that I suspect that LL will never swallow, but that is already in > Firestorm's LGPL codebase. What I've come to understand, and I accept as I > can see the logic behind it, is that open source is not the same as > open decision making, nor is it the same as allowing others to make the > decisions. It simply means the code is available under a permissive > license for others - including us - to review, comment on, modify, and > compile for ourselves. Let me re-iterate: open source is NOT community > maintenance. LL has never implied or pretended that they've set up > a community maintenance program - and I think they'd have major problems if > they tried. > > My L$2, and I will not continue in this topic on this thread. If you wish > to respond to me, please take it off-list. > > Ricky > Cron Stardust > > > On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: > >> On Sun, 24 Feb 2013 20:09:19 +0100 >> Henri Beauchamp wrote: >> >> > > I'm unable to comment on SUN issues (or even make them) >> > >> > Gotta love the new closed JIRA !... Way to go, LL... >> >> I was about to type "fuck you Linden Lab" in my previous post, >> but assumed they might be assholes enough to then kick me >> of this list... The phrase "way to go" is inventive. It would >> never have occurred to me to use that in this context. >> >> This whole "open source" HAHAHA project is a pathetic, lame, >> grrrrrrr - I want to SPIT on it. LL should be sued for fucking >> CALLING this "open" in ANY way. I hate you. >> >> A REAL Open Source coder, >> Carlo Wood >> >> PS I'd add a comment HERE regarding SUN-38, but I learned years >> ago already that LL doesn't listen to anyone. They are just >> going to give you the finger Henri (and everyone else in SL) >> but not going to fix this. I'm not even going to TRY add >> a (technical) comment. Seriously, why is ANYONE still HELPING >> them? Why doesn't everyone just leave this list, stop >> going to their meetings, and stop giving them patches? Are >> you all stupid or what? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/9dff019b/attachment.htm From darien.caldwell at gmail.com Fri Mar 1 13:43:12 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri, 1 Mar 2013 13:43:12 -0800 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: Well, This is an interesting development. I only understood SSB to be handling the baking of textures. But it's centralizing the avatar's shape too? Or why does a change in height need to be routed through the back-end? Adding a new slider to the Avatar appearance is kind of unprecedented. Will LL be revving the Shape XML export format? https://wiki.secondlife.com/wiki/Mesh/Avatar_Shape_XML_Format - Dari On Fri, Mar 1, 2013 at 1:20 PM, Nyx Linden wrote: > > https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 > > Added a new parameter to shapes to replace the viewer-side height offset. > Since it is stored in a wearable, the new back end can read and use the > value. Will send an email to third party devs later today to let them know > to pick up the patch. > > Marking SUN-38 as resolved. > > -Nyx > > > On Sun, Feb 24, 2013 at 11:46 PM, Ricky wrote: > >> I know this thread has gotten completely OT, but I feel I should respond >> to the feeling of dissatisfaction. >> >> I contribute to help me. I know that not everything I contribute will be >> accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I >> created that I suspect that LL will never swallow, but that is already in >> Firestorm's LGPL codebase. What I've come to understand, and I accept as I >> can see the logic behind it, is that open source is not the same as >> open decision making, nor is it the same as allowing others to make the >> decisions. It simply means the code is available under a permissive >> license for others - including us - to review, comment on, modify, and >> compile for ourselves. Let me re-iterate: open source is NOT community >> maintenance. LL has never implied or pretended that they've set up >> a community maintenance program - and I think they'd have major problems if >> they tried. >> >> My L$2, and I will not continue in this topic on this thread. If you >> wish to respond to me, please take it off-list. >> >> Ricky >> Cron Stardust >> >> >> On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: >> >>> On Sun, 24 Feb 2013 20:09:19 +0100 >>> Henri Beauchamp wrote: >>> >>> > > I'm unable to comment on SUN issues (or even make them) >>> > >>> > Gotta love the new closed JIRA !... Way to go, LL... >>> >>> I was about to type "fuck you Linden Lab" in my previous post, >>> but assumed they might be assholes enough to then kick me >>> of this list... The phrase "way to go" is inventive. It would >>> never have occurred to me to use that in this context. >>> >>> This whole "open source" HAHAHA project is a pathetic, lame, >>> grrrrrrr - I want to SPIT on it. LL should be sued for fucking >>> CALLING this "open" in ANY way. I hate you. >>> >>> A REAL Open Source coder, >>> Carlo Wood >>> >>> PS I'd add a comment HERE regarding SUN-38, but I learned years >>> ago already that LL doesn't listen to anyone. They are just >>> going to give you the finger Henri (and everyone else in SL) >>> but not going to fix this. I'm not even going to TRY add >>> a (technical) comment. Seriously, why is ANYONE still HELPING >>> them? Why doesn't everyone just leave this list, stop >>> going to their meetings, and stop giving them patches? Are >>> you all stupid or what? >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/597b4872/attachment-0001.htm From nyx at lindenlab.com Fri Mar 1 13:59:00 2013 From: nyx at lindenlab.com (Nyx Linden) Date: Fri, 1 Mar 2013 16:59:00 -0500 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: SSB does all appearance generation as a centralized service - meaning your avatar's visual parameters, height, and baked textures are served without needing the viewer to have downloaded and decoded the wearables. That's why I'm starting to refer to it as server side appearance, not server side baking. Height is determined when you calculate your agent's appearance message which is now generated on the back end. Adding new wearable parameters is not without precedent - we've done it before when we added alpha masks, tattoos, avatar physics, etc. The only change should be a new parameter (id=11001) in the shape's parameter block. This does not represent a major revision to the wearable or avatar format. -Nyx On Fri, Mar 1, 2013 at 4:43 PM, Darien Caldwell wrote: > Well, This is an interesting development. I only understood SSB to be > handling the baking of textures. But it's centralizing the avatar's shape > too? Or why does a change in height need to be routed through the back-end? > > Adding a new slider to the Avatar appearance is kind of unprecedented. > Will LL be revving the Shape XML export format? > > https://wiki.secondlife.com/wiki/Mesh/Avatar_Shape_XML_Format > > - Dari > > On Fri, Mar 1, 2013 at 1:20 PM, Nyx Linden wrote: > >> >> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 >> >> Added a new parameter to shapes to replace the viewer-side height offset. >> Since it is stored in a wearable, the new back end can read and use the >> value. Will send an email to third party devs later today to let them know >> to pick up the patch. >> >> Marking SUN-38 as resolved. >> >> -Nyx >> >> >> On Sun, Feb 24, 2013 at 11:46 PM, Ricky wrote: >> >>> I know this thread has gotten completely OT, but I feel I should respond >>> to the feeling of dissatisfaction. >>> >>> I contribute to help me. I know that not everything I contribute will >>> be accepted: see https://jira.secondlife.com/browse/VWR-25739 for one I >>> created that I suspect that LL will never swallow, but that is already in >>> Firestorm's LGPL codebase. What I've come to understand, and I accept as I >>> can see the logic behind it, is that open source is not the same as >>> open decision making, nor is it the same as allowing others to make the >>> decisions. It simply means the code is available under a permissive >>> license for others - including us - to review, comment on, modify, and >>> compile for ourselves. Let me re-iterate: open source is NOT community >>> maintenance. LL has never implied or pretended that they've set up >>> a community maintenance program - and I think they'd have major problems if >>> they tried. >>> >>> My L$2, and I will not continue in this topic on this thread. If you >>> wish to respond to me, please take it off-list. >>> >>> Ricky >>> Cron Stardust >>> >>> >>> On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: >>> >>>> On Sun, 24 Feb 2013 20:09:19 +0100 >>>> Henri Beauchamp wrote: >>>> >>>> > > I'm unable to comment on SUN issues (or even make them) >>>> > >>>> > Gotta love the new closed JIRA !... Way to go, LL... >>>> >>>> I was about to type "fuck you Linden Lab" in my previous post, >>>> but assumed they might be assholes enough to then kick me >>>> of this list... The phrase "way to go" is inventive. It would >>>> never have occurred to me to use that in this context. >>>> >>>> This whole "open source" HAHAHA project is a pathetic, lame, >>>> grrrrrrr - I want to SPIT on it. LL should be sued for fucking >>>> CALLING this "open" in ANY way. I hate you. >>>> >>>> A REAL Open Source coder, >>>> Carlo Wood >>>> >>>> PS I'd add a comment HERE regarding SUN-38, but I learned years >>>> ago already that LL doesn't listen to anyone. They are just >>>> going to give you the finger Henri (and everyone else in SL) >>>> but not going to fix this. I'm not even going to TRY add >>>> a (technical) comment. Seriously, why is ANYONE still HELPING >>>> them? Why doesn't everyone just leave this list, stop >>>> going to their meetings, and stop giving them patches? Are >>>> you all stupid or what? >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/e33f48d7/attachment.htm From darien.caldwell at gmail.com Fri Mar 1 14:07:09 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri, 1 Mar 2013 14:07:09 -0800 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: I see. This is a little different since it's a direct Avatar Shape Slider (unless I misunderstand), and isn't just a new type of Wearable, but I see the parallels. Thanks for the clarifications, they are much appreciated. - Dari On Fri, Mar 1, 2013 at 1:59 PM, Nyx Linden wrote: > SSB does all appearance generation as a centralized service - meaning > your avatar's visual parameters, height, and baked textures are served > without needing the viewer to have downloaded and decoded the wearables. > That's why I'm starting to refer to it as server side appearance, not > server side baking. Height is determined when you calculate your agent's > appearance message which is now generated on the back end. > > Adding new wearable parameters is not without precedent - we've done > it before when we added alpha masks, tattoos, avatar physics, etc. The only > change should be a new parameter (id=11001) in the shape's parameter block. > This does not represent a major revision to the wearable or avatar format. > > -Nyx > > > On Fri, Mar 1, 2013 at 4:43 PM, Darien Caldwell > wrote: > >> Well, This is an interesting development. I only understood SSB to be >> handling the baking of textures. But it's centralizing the avatar's shape >> too? Or why does a change in height need to be routed through the back-end? >> >> Adding a new slider to the Avatar appearance is kind of unprecedented. >> Will LL be revving the Shape XML export format? >> >> https://wiki.secondlife.com/wiki/Mesh/Avatar_Shape_XML_Format >> >> - Dari >> >> On Fri, Mar 1, 2013 at 1:20 PM, Nyx Linden wrote: >> >>> >>> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 >>> >>> Added a new parameter to shapes to replace the viewer-side height >>> offset. Since it is stored in a wearable, the new back end can read and use >>> the value. Will send an email to third party devs later today to let them >>> know to pick up the patch. >>> >>> Marking SUN-38 as resolved. >>> >>> -Nyx >>> >>> >>> On Sun, Feb 24, 2013 at 11:46 PM, Ricky wrote: >>> >>>> I know this thread has gotten completely OT, but I feel I should >>>> respond to the feeling of dissatisfaction. >>>> >>>> I contribute to help me. I know that not everything I contribute will >>>> be accepted: see https://jira.secondlife.com/browse/VWR-25739 for one >>>> I created that I suspect that LL will never swallow, but that is already in >>>> Firestorm's LGPL codebase. What I've come to understand, and I accept as I >>>> can see the logic behind it, is that open source is not the same as >>>> open decision making, nor is it the same as allowing others to make the >>>> decisions. It simply means the code is available under a permissive >>>> license for others - including us - to review, comment on, modify, and >>>> compile for ourselves. Let me re-iterate: open source is NOT community >>>> maintenance. LL has never implied or pretended that they've set up >>>> a community maintenance program - and I think they'd have major problems if >>>> they tried. >>>> >>>> My L$2, and I will not continue in this topic on this thread. If you >>>> wish to respond to me, please take it off-list. >>>> >>>> Ricky >>>> Cron Stardust >>>> >>>> >>>> On Sun, Feb 24, 2013 at 7:27 PM, Carlo Wood wrote: >>>> >>>>> On Sun, 24 Feb 2013 20:09:19 +0100 >>>>> Henri Beauchamp wrote: >>>>> >>>>> > > I'm unable to comment on SUN issues (or even make them) >>>>> > >>>>> > Gotta love the new closed JIRA !... Way to go, LL... >>>>> >>>>> I was about to type "fuck you Linden Lab" in my previous post, >>>>> but assumed they might be assholes enough to then kick me >>>>> of this list... The phrase "way to go" is inventive. It would >>>>> never have occurred to me to use that in this context. >>>>> >>>>> This whole "open source" HAHAHA project is a pathetic, lame, >>>>> grrrrrrr - I want to SPIT on it. LL should be sued for fucking >>>>> CALLING this "open" in ANY way. I hate you. >>>>> >>>>> A REAL Open Source coder, >>>>> Carlo Wood >>>>> >>>>> PS I'd add a comment HERE regarding SUN-38, but I learned years >>>>> ago already that LL doesn't listen to anyone. They are just >>>>> going to give you the finger Henri (and everyone else in SL) >>>>> but not going to fix this. I'm not even going to TRY add >>>>> a (technical) comment. Seriously, why is ANYONE still HELPING >>>>> them? Why doesn't everyone just leave this list, stop >>>>> going to their meetings, and stop giving them patches? Are >>>>> you all stupid or what? >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>>> Please read the policies before posting to keep unmoderated posting >>>>> privileges >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130301/befa66ee/attachment-0001.htm From sldev at free.fr Fri Mar 1 16:21:13 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 2 Mar 2013 01:21:13 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: <20130302012113.f87f73f2.sldev@free.fr> On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote: > https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 > > Added a new parameter to shapes to replace the viewer-side height offset. > Since it is stored in a wearable, the new back end can read and use the > value. Will send an email to third party devs later today to let them know > to pick up the patch. ARRRGHHHH ! Adding a new parameter to the shape is NOT a suitable way to achieve equivalent results as what we could get so far in non-SSB sims: each time a new (sit, lay, kneel, crouch, crawl...) animation is played, you need to adjust the Z-offset: this can't obviously be achieved by each time changing a shape parameter, saving the new shape, and then asking for a (full !) rebake: the Z-offset (and more exactly the avatar height as requested by the viewer depending on the currently worn shape and the Z-offset) needs to be accounted for in real time (like what LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the other visual parameters; the shape wearable itself should be left untouched when the height is adjusted via the Z offset. > Marking SUN-38 as resolved. Nope, I'm sorry, but it's far from resolved !!!! Henri. From stickman at gmail.com Fri Mar 1 23:53:24 2013 From: stickman at gmail.com (Stickman) Date: Fri, 1 Mar 2013 23:53:24 -0800 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: On Fri, Mar 1, 2013 at 1:20 PM, Nyx Linden wrote: > https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 > > Added a new parameter to shapes to replace the viewer-side height offset. > Since it is stored in a wearable, the new back end can read and use the > value. Will send an email to third party devs later today to let them know > to pick up the patch. > > Marking SUN-38 as resolved. On a slightly related note. A longstanding issue with deformation animations (eg, playing an animation that changes the positions of bones) is that when the height is recalculated (eg, shape is changed) the avatar will tend to float off the ground or sink into it. This can actually be triggered as a race condition when a new person teleports into the area where others are wearing an avatar that requires deformations, depending on whether they load the shape or deformation animations first. Would including the z-height offset in the shape resolve this problem, or is the offset simply applied on top of the calculations that cause the problem? From marinekelley at gmail.com Fri Mar 1 23:57:57 2013 From: marinekelley at gmail.com (Marine Kelley) Date: Sat, 2 Mar 2013 08:57:57 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130302012113.f87f73f2.sldev@free.fr> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> <20130302012113.f87f73f2.sldev@free.fr> Message-ID: What Henri said. Avatar height offset is a variable that currently changes OFTEN, that's even the reason why it was added as a RLV command, so that it could be changed automatically without annoying the user too much. If this is now a shape slider, and viewer devs like me have to deal with accordingly, this means this RLV command will trigger a shape rebake every time it is issued, which would happen, like I said, OFTEN. And like Lance mentioned, I'm not even sure this would work on no-mod shapes anyway. I'm not saying the old parameter was ideal. In fact it was a just acceptable solution since it didn't actually modify the altitude of the avatar but its height, its bounding box. It would have been better if it were an offset, and we could modify it in X, Y and Z independently, and beyond [ -0.5, +0.5 ]. I'm saying that this new parameter will make it even less ideal. The formula for calculating the correct value to send to the viewer via the RLV command is not trivial, the extrema of this new slider are [ -2.0, +2.0 ] if I'm not mistaken, and we will have to issue the command in two different ways according to whether we are in a SSB-enabled region or not. That's a lot of work and development time for us. Perhaps it is easy for you to add a slider, but this solution is far, far from ideal for us. It is currently a debug setting (which name varies from viewer to viewer). Can't we have a solution that involves a debug setting instead of a shape slider, so we don't have to rewrite everything ? Please ? Marine On 02/03/2013, Henri Beauchamp wrote: > On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote: > >> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 >> >> Added a new parameter to shapes to replace the viewer-side height offset. >> Since it is stored in a wearable, the new back end can read and use the >> value. Will send an email to third party devs later today to let them >> know >> to pick up the patch. > > ARRRGHHHH ! > > Adding a new parameter to the shape is NOT a suitable way to achieve > equivalent results as what we could get so far in non-SSB sims: each > time a new (sit, lay, kneel, crouch, crawl...) animation is played, > you need to adjust the Z-offset: this can't obviously be achieved by > each time changing a shape parameter, saving the new shape, and then > asking for a (full !) rebake: the Z-offset (and more exactly the avatar > height as requested by the viewer depending on the currently worn shape > and the Z-offset) needs to be accounted for in real time (like what > LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the > other visual parameters; the shape wearable itself should be left > untouched when the height is adjusted via the Z offset. > >> Marking SUN-38 as resolved. > > Nope, I'm sorry, but it's far from resolved !!!! > > Henri. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > From satomi.ahn at gmail.com Sun Mar 3 04:43:26 2013 From: satomi.ahn at gmail.com (Satomi Ahn) Date: Sun, 3 Mar 2013 13:43:26 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> <20130302012113.f87f73f2.sldev@free.fr> Message-ID: Hello, Since I cannot comment on SUN issues, may I make a suggestion here? If adding new parameters to existing stuff belongs to allowed actions to resolve this issue, then couldn't we consider adding new parameters to poses/animations, so that they can exactly know how to adjust in order for the avatar not to sink into or float over ground? The 3 parameters of current RLV command @adjustheight more or less achieve this result. These parameters need to be adjusted on a per-animation basis and do not depend on the avatar shape (this was not possible with a single Z-offset parameter, because the needed absolute offset depends on each avatar hip/height ratio... but I am sure that Henri Beauchamp can explain this better). I believe that what I propose would be the best solution for newly created poses. For already existing ones, since the animation system allows "layering" several animations, then this would become a possibility to create poses just for adjusting the Z-offset of existing ones. Of course, it would be even better if the viewer was also still able to send bounding box update messages to the sim, as existing height adjustment systems would continue to work. 2013/3/2 Marine Kelley : > What Henri said. Avatar height offset is a variable that currently > changes OFTEN, that's even the reason why it was added as a RLV > command, so that it could be changed automatically without annoying > the user too much. > > If this is now a shape slider, and viewer devs like me have to deal > with accordingly, this means this RLV command will trigger a shape > rebake every time it is issued, which would happen, like I said, > OFTEN. And like Lance mentioned, I'm not even sure this would work on > no-mod shapes anyway. > > I'm not saying the old parameter was ideal. In fact it was a just > acceptable solution since it didn't actually modify the altitude of > the avatar but its height, its bounding box. It would have been better > if it were an offset, and we could modify it in X, Y and Z > independently, and beyond [ -0.5, +0.5 ]. > > I'm saying that this new parameter will make it even less ideal. The > formula for calculating the correct value to send to the viewer via > the RLV command is not trivial, the extrema of this new slider are [ > -2.0, +2.0 ] if I'm not mistaken, and we will have to issue the > command in two different ways according to whether we are in a > SSB-enabled region or not. That's a lot of work and development time > for us. Perhaps it is easy for you to add a slider, but this solution > is far, far from ideal for us. > > It is currently a debug setting (which name varies from viewer to > viewer). Can't we have a solution that involves a debug setting > instead of a shape slider, so we don't have to rewrite everything ? > Please ? > > Marine > > On 02/03/2013, Henri Beauchamp wrote: >> On Fri, 1 Mar 2013 16:20:10 -0500, Nyx Linden wrote: >> >>> https://bitbucket.org/lindenlab/sunshine-external/commits/108ae1ed56ea38426df239ef3247f57fb63d0806 >>> >>> Added a new parameter to shapes to replace the viewer-side height offset. >>> Since it is stored in a wearable, the new back end can read and use the >>> value. Will send an email to third party devs later today to let them >>> know >>> to pick up the patch. >> >> ARRRGHHHH ! >> >> Adding a new parameter to the shape is NOT a suitable way to achieve >> equivalent results as what we could get so far in non-SSB sims: each >> time a new (sit, lay, kneel, crouch, crawl...) animation is played, >> you need to adjust the Z-offset: this can't obviously be achieved by >> each time changing a shape parameter, saving the new shape, and then >> asking for a (full !) rebake: the Z-offset (and more exactly the avatar >> height as requested by the viewer depending on the currently worn shape >> and the Z-offset) needs to be accounted for in real time (like what >> LLAgent::sendAgentSetAppearance() allowed to do), indenpendently of the >> other visual parameters; the shape wearable itself should be left >> untouched when the height is adjusted via the Z offset. >> >>> Marking SUN-38 as resolved. >> >> Nope, I'm sorry, but it's far from resolved !!!! >> >> Henri. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges From sldev at free.fr Sun Mar 3 07:37:33 2013 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 3 Mar 2013 16:37:33 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> <20130302012113.f87f73f2.sldev@free.fr> Message-ID: <20130303163733.5c16ac85.sldev@free.fr> On Sun, 3 Mar 2013 13:43:26 +0100, Satomi Ahn wrote: > Hello, > > Since I cannot comment on SUN issues, may I make a suggestion here? > > If adding new parameters to existing stuff belongs to allowed actions > to resolve this issue, then couldn't we consider adding new parameters > to poses/animations, so that they can exactly know how to adjust in > order for the avatar not to sink into or float over ground? > The 3 parameters of current RLV command @adjustheight more or less > achieve this result. These parameters need to be adjusted on a > per-animation basis and do not depend on the avatar shape (this was > not possible with a single Z-offset parameter, because the needed > absolute offset depends on each avatar hip/height ratio... but I am > sure that Henri Beauchamp can explain this better). It would be a good idea if it would not result in breaking all existing content... > I believe that what I propose would be the best solution for newly > created poses. For already existing ones, since the animation system > allows "layering" several animations, then this would become a > possibility to create poses just for adjusting the Z-offset of > existing ones. No, this is a VERY BAD idea: "layering" animations most often doesn't work as expected, because of their priority and how pretty much all anims have been uploaded with the maximum priority, not to mention the problem with having to create (and upload) one "correction" anim for each existing animation (and the number of possible (reference_height, scalar) couples is almost infinite !). > Of course, it would be even better if the viewer was also still able > to send bounding box update messages to the sim, as existing height > adjustment systems would continue to work. It won't be "better", for any "advanced user" (read: anyone caring about not having their avatar floating above or sinking into the ground when playing anims, or wanting to be able to adjust themselves the pose on poseballs not providing scripted sit target adjustement) it is a MANDATORY feature that MUST be implemented in SSB sims to match what we have been doing for years in non-SSB ones (@adjustheight is relatively new, but the Avatar-Z offset manual adjustment has been around for years). Henri. From satomi.ahn at gmail.com Sun Mar 3 11:39:17 2013 From: satomi.ahn at gmail.com (Satomi Ahn) Date: Sun, 3 Mar 2013 20:39:17 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <20130303182706.528eb9fa@hikaru.localdomain> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> <20130302012113.f87f73f2.sldev@free.fr> <20130303182706.528eb9fa@hikaru.localdomain> Message-ID: Carlo Wood wrote: > The problem is not to find a good technical solution; the problem is > that no discussion with Linden Lab is possible. Well, the new shape parameter was an actual attempt at fixing SUN-38, even though it did address only the least of the concerns. So maybe I am still allowed to hope? Henri Beauchamp wrote: > It would be a good idea if it would not result in breaking all existing content... I was just suggesting a perennial solution for *new* content only. For old poses, we definitely need something else... > it is a MANDATORY feature that MUST be implemented in SSB sims to > match what we have been doing for years in non-SSB ones (@adjustheight > is relatively new, but the Avatar-Z offset manual adjustment has > been around for years). ... and the best candidate for "something else" is of course to preserve the existing crutch. Granted. From thomas.shikami at online.de Thu Mar 7 06:53:03 2013 From: thomas.shikami at online.de (Thomas Shikami) Date: Thu, 07 Mar 2013 15:53:03 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> Message-ID: <5138A9CF.9090308@online.de> Is there even a requirement zo have Z-offset be in the avatar appearance message? To me it looks more like that hip-offset would be better suited to be in some animation parameter, which makes it incompatible with older viewers, but a SSB-enabled simulator might translate that animation parameter into an avatar appearance message for viewers not supporting that idea of animation parameter. Am 01.03.2013 22:59, schrieb Nyx Linden: > SSB does all appearance generation as a centralized service - > meaning your avatar's visual parameters, height, and baked textures > are served without needing the viewer to have downloaded and decoded > the wearables. That's why I'm starting to refer to it as server side > appearance, not server side baking. Height is determined when you > calculate your agent's appearance message which is now generated on > the back end. > > Adding new wearable parameters is not without precedent - we've > done it before when we added alpha masks, tattoos, avatar physics, > etc. The only change should be a new parameter (id=11001) in the > shape's parameter block. This does not represent a major revision to > the wearable or avatar format. > > -Nyx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130307/6f70006d/attachment.htm From sldev at free.fr Thu Mar 7 08:27:51 2013 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 7 Mar 2013 17:27:51 +0100 Subject: [opensource-dev] Serious regression in SSB-enabled regions In-Reply-To: <5138A9CF.9090308@online.de> References: <20130224131400.31856185.sldev@free.fr> <20130224200919.826f88ba.sldev@free.fr> <20130225042720.04ccef21@hikaru.localdomain> <5138A9CF.9090308@online.de> Message-ID: <20130307172751.429cbd79.sldev@free.fr> On Thu, 07 Mar 2013 15:53:03 +0100, Thomas Shikami wrote: > Is there even a requirement zo have Z-offset be in the avatar > appearance message? The Z-offset is not transmitted to the server by the viewers implementing it: what is transmitted is the sum of the Z-offset (which can also be negative) and the avatar height as calculated from the shoes and shape visual parameters. This causes the server to think that the avatar is either taller or smaller while its shape and shoes didn't change, but which also causes the animations to be played at a higher or lower level above the floor (the server can auto-correct properly standing animations for any worn shape or shoes, but of course this auto-correction algorithm fails for sitting, kneeling, laying, crouching, crawling anims since in those the feet to hip length doesn't count for the same fraction as in standing anims). In short, the viewer transmits to the server what it computed to be the proper "avatar height" for the animation to be correctly leveled with the floor; the server then adopts this new height, applies its own auto-correction (the one that was designed for standing anims) and relays the info to all viewers, making the avatar appear at the proper level for everyone around. > To me it looks more like that hip-offset would be better suited > to be in some animation parameter, which makes it incompatible with > older viewers, but a SSB-enabled simulator might translate that > animation parameter into an avatar appearance message for viewers not > supporting that idea of animation parameter. I already replied to this suggestion to Satomi Ahn in this list, explaining why it won't work properly and won't allow to perform the equivalent operations as what non-SSB servers have been allowing since day one of SL (and OpenSim). Ideally, yes, the animations should have allowed to enter the "reference height" (the height of the avatar for which the anim is properly leveled with the floor) and "scalar" (the scalar to apply to the difference between the reference height and the current height of the avatar playing the anim so to find the Z-offset to add to this latter height so to allow a proper leveling with the floor). However, all existing anims would still fail to play properly if LL was to add these parameters now without supporting the Z-offset feature. This is not the solution we need, even if adding such parameters to the anims could be a future improvement (but you will always need Z-offet support for all the existing anims, as well as for correcting manually the sit target of pose-balls/furniture not having a scripted anim height adjustment). Henri. From sitearm at gmail.com Fri Mar 8 16:49:02 2013 From: sitearm at gmail.com (Sitearm) Date: Fri, 8 Mar 2013 18:49:02 -0600 Subject: [opensource-dev] =?utf-8?q?MOSES_Office_Hours_Screenshot_08-Mar-2?= =?utf-8?q?013=3B_Intel_STTC_User_Scalability_Experiment_=28100?= =?utf-8?q?=E2=80=B2s_of_users_online_at_once_in_the_same_region_wi?= =?utf-8?q?th_no_lag=29?= In-Reply-To: References: Message-ID: fyi; ps rumour has it MOSES is talking to LL to backshare MOSES Office Hours Screenshot 08-Mar-2013 March 9, 2013 ? sitearm *[image: moses office hours 08-mar-2013] **3-D Web* is the set of internet technologies that put user browsers in an online, interactive 3D environment. *Distributed Scene Graph (DSG)* is a technology developed by Intel Corporation to enable 3D web experiences to extend to massive numbers of OpenSim users (*100?s of users online at once in the same region with no lag *). *Hot Topic* at today?s MOSES Office Hours was the upcoming *Intel STTC User Scalability Experiment *on March 22nd, *open to the public as well as the MOSES Community*. This will be "The first in a series of experiments designed to see if full spectrum operations during mission rehearsal exercise can be achieved in a virtual environment." (Douglas Maxwell) *Date & Time *. Friday, March 22nd, 6pm-8pm EST. *Reference* . The link to the experiment design is here. . STTC is self-security-credentialed: ignore the browser warning and click through to the wiki. Posted in 3D Web , MOSES, News . Leave a Comment ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130308/105d323a/attachment.htm From c at yotes.com Sun Mar 10 09:30:31 2013 From: c at yotes.com (Adam Moss) Date: Sun, 10 Mar 2013 16:30:31 +0000 Subject: [opensource-dev] 'justabouteverything' (STORM-1921, STORM-1928, STORM-1927) Message-ID: I've put ALL of my finished rendering fixes and speedups on this one branch: https://bitbucket.org/tofu_linden/justabouteverything It's all been reviewed. I've put it in one place based on third-hand information that merging the fixes together with viewer-development was hard (it was truly trivial - hmm!) It's based on the latest viewer-development. I'd appreciate if it could be taken upstream or whatever. Cheers, --Adam 'Tofu Buzzard' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130310/df009e4f/attachment.htm From sitearm at gmail.com Sun Mar 10 13:04:29 2013 From: sitearm at gmail.com (Sitearm) Date: Sun, 10 Mar 2013 15:04:29 -0500 Subject: [opensource-dev] speaking of "Storm" a kind of beatnik riff about... logic and philosophy... animated : ) Message-ID: speaking of "Storm" a kind of beatnik riff about... logic and philosophy... animated : ) http://www.youtube.com/watch?v=HhGuXCuDb1U -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130310/0571e275/attachment.htm From desmoulins.uchi at googlemail.com Sun Mar 10 20:47:47 2013 From: desmoulins.uchi at googlemail.com (Niran) Date: Mon, 11 Mar 2013 04:47:47 +0100 Subject: [opensource-dev] 'justabouteverything' (STORM-1921, STORM-1928, STORM-1927) In-Reply-To: References: Message-ID: i highly doubt that it was ever "hard" to merge, i mean it seems to be "hard" to merge as soon as something very very tiny doesnt work automatically for LL... like uhhh it didnt write one line... its soooo hard to do that manually... at least thats what it looks like... 2013/3/10 Adam Moss > I've put ALL of my finished rendering fixes and speedups on this one > branch: > https://bitbucket.org/tofu_linden/justabouteverything > > It's all been reviewed. I've put it in one place based on third-hand > information that merging the fixes together with viewer-development was > hard (it was truly trivial - hmm!) > > It's based on the latest viewer-development. > > I'd appreciate if it could be taken upstream or whatever. > > Cheers, > --Adam > 'Tofu Buzzard' > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130311/ce393e50/attachment.htm From sitearm at gmail.com Mon Mar 11 10:27:04 2013 From: sitearm at gmail.com (Sitearm) Date: Mon, 11 Mar 2013 12:27:04 -0500 Subject: [opensource-dev] Fwd: MOSES Scalability Experiment Call for Participation (UNCLASSIFIED) In-Reply-To: <7470f98195f9.513dbdb9@us.army.mil> References: <7540a937db80.513deb7a@us.army.mil> <74f08642c413.513deca7@us.army.mil> <75b082f4ffd8.513dedd5@us.army.mil> <757082e7f0e5.513def04@us.army.mil> <75f0ffa9cc83.513df033@us.army.mil> <75f0d9e6e5aa.513df163@us.army.mil> <7650f7b980fa.513df294@us.army.mil> <75d0eab1b32f.513df3c5@us.army.mil> <7680cb14a73c.513df4f6@us.army.mil> <7470f98195f9.513dbdb9@us.army.mil> Message-ID: fyi - role playing experiment using enhanced Open Simulator tech; ll is in the loop ---------- Forwarded message ---------- From: ARL STTC Open Simulator Date: Mon, Mar 11, 2013 at 10:19 AM Subject: MOSES Scalability Experiment Call for Participation (UNCLASSIFIED) To: MOSES LIST UNCLASSIFIED Good Morning Everyone, the much anticipated MOSES Scalability experiment ready to accept volunteers to particpate. The experiment is designed to monitor and test performance of the Dynamic Scene Graph (DSG) technology developed in part by Intel Corp. The participants will be allowed to select a role to play a scenario set in the fictional town of Brentville, Atropia. 100 roles have been designed, however if we get more than 100 volunteers more roles may be created. We know the the DSG can handle much more than 100 connections, however we wish to use this experiment to establish baseline behaviors and server loads. There will be more events like this one throughout the year, gradually increasing in scale. The scenario has a company of 40 soldiers who have been ordered to patrol the town of Brentville and interract with the residents. The company's mission is to attempt to map the political structure of the town, learn who is really in charge, and figure out the social networks. The soldiers are also tasked to be on the lookout for weapons caches and signs of explosives manufacturing activities. The 50 townspeople are arranged into 4 families, each with an agenda and secrets. When you sign up, a dosier of your role is provided as well as your allegiences and activities. The attached screenshots show a few of the hangouts and meeting places in the sim. Participation is anonymous, however you must enter a valid email address so that we can verify you are not a bot and send you the role dosier. This link provides more detailed background information on the experiment, the scenario, and the roles: https://107.7.21.233/redmine/projects/moses/wiki/IntelSTTC_User_Scalability_Experiment_1 SIGN UP HERE >>> https://107.7.21.233/form.php Good Luck and I hope to see you there! PS: If you want to get a preview of the town in the screenshots, log into MOSES and go to the sim: OAR_022 Douglas Maxwell, MSME Science and Technology Manager Virtual World Strategic Applications U.S. Army Simulation & Training Technology Center (STTC) (407) 208-5097 DSN 970-5097 twitter: @vrdeity UNCLASSIFIED -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130311/783eaeb3/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: Brentville School.png Type: image/x-png Size: 1963250 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130311/783eaeb3/attachment-0003.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Brentville Market.png Type: image/x-png Size: 2395205 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130311/783eaeb3/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Brentville Clothing Store.png Type: image/x-png Size: 2510516 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130311/783eaeb3/attachment-0005.bin From monty at lindenlab.com Thu Mar 14 17:13:19 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 14 Mar 2013 20:13:19 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <51350A28.7040100@lindenlab.com> References: <51350A28.7040100@lindenlab.com> Message-ID: <5142679F.8070406@lindenlab.com> We now have three channels and a number of regions available for testing: * DRTSIM-203. Normal release intended to go to Agni supporting keepalive connections and other changes. Regions: o TextureTest2. High texture count, no meshes, low residency limit to prevent interference when doing benchmark testing. o (Coming soon) MeshTest2. High mesh count (many distinct mesh assets which all look the same), few textures. Low residency limit to prevent interference when doing benchmark testing. * DRTSIM-203H. Our 'Happy' channel with more generous limits and optimistic service controls. o TextureTest2H. Identical to TextureTest. o (Coming soon) MeshTest2H. Identical to MeshTest2 * DRTSIM-203A. Our 'Angry' channel with stricter and preemptive enforcement of limits (generates many 503 errors). o TextureTest2A. Identical to TextureTest. o (Coming soon) MeshTest2A. Identical to MeshTest2 Test regions share object and texture references so if you are trying to measure download rates or really exercise the network, you'll need to defeat caching. Typically with a restart and manual cache clear or your own preferred method. Aditi is also hosting some of the server-side baking work and you may not get a reliable avatar appearance unless you use a Sunshine project viewer. What we're looking for on these channels: DRTSIM-203. HTTP issues generally. HTTP texture download reliability and throughput. Script writers using *llRequestURL* and *llRequestSecureURL* should try to get an A/B comparison going between a normal 'Second Life Server' region on Aditi and DRTSIM-203. Particularly with competing traffic like large texture or mesh downloads. Scripts aren't getting a boost with this work but they shouldn't be adversely impacted. Mesh also isn't getting a boost this time but, again, negative impact should be avoided. Third-party viewer developers should test for overall compatibility with all HTTP services. We're interested in reports of regressions in any areas. We *are* expecting more 503 errors (0x01f70001) in log files as it will be possible to push requests faster than before and certain throttles will be hit. As long as these are recoverable, they're not a regression, they're an indicator of better utilization. DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other limits are generally raised. This may increase the tendency to get 503 and 502 (0x01f60001) errors in some areas. Again, these aren't regressions as long as they're recoverable. Subjective and objective comments on Mesh and scripting behavior are sought here. DRTSIM-203A (Angry). This channel deliberately restricts resources and uses a punitive enforcement policy that should result in a storm of 503 errors. Viewers are expected to recover from these. Scripters can use this to test against a (reliably unreliable?) grid to see if they're handling recovery well. A higher error rate and lower throughput and availability are expected here. What is being tested is viewer and script robustness in the face of constraints. A more rigid enforcement policy, if tolerated by external software, might actually allow us to set higher limits if we can pull back when required. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/827257c9/attachment.htm From darien.caldwell at gmail.com Thu Mar 14 18:46:01 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu, 14 Mar 2013 18:46:01 -0700 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <5142679F.8070406@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: I'm curious how a script would be expected to recover from a 'flurry of 502/503' errors? If my HTTP enabled object is expecting to communicate with my external-to-SL server, and instead receives an 503 error, all I could see doing is to retry. So is hammering the server with retries really going to improve sim conditions? Would this be expected when communicating with external-to-SL services, or is this more likely to occur when a scripted service is trying to communicate with another scripted service within the Grid? As well I am not sure why scripts are being included in this at all. The HTTP issues as I understood were the number of http connections a viewer had to handle, with another factor in that mix being the particular router the resident uses and how well/badly it handled multiple HTTP connections. Service to service communcations such as a script to an external server or a script to another script shouldn't be a contributing factor in these viewer connection problems. The connections should never be hitting any viewer. - Dari On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg wrote: > > We now have three channels and a number of regions available for testing: > > > - DRTSIM-203. Normal release intended to go to Agni supporting > keepalive connections and other changes. Regions: > - TextureTest2. High texture count, no meshes, low residency limit > to prevent interference when doing benchmark testing. > - (Coming soon) MeshTest2. High mesh count (many distinct mesh > assets which all look the same), few textures. Low residency limit to > prevent interference when doing benchmark testing. > - DRTSIM-203H. Our 'Happy' channel with more generous limits and > optimistic service controls. > - TextureTest2H. Identical to TextureTest. > - (Coming soon) MeshTest2H. Identical to MeshTest2 > - DRTSIM-203A. Our 'Angry' channel with stricter and preemptive > enforcement of limits (generates many 503 errors). > - TextureTest2A. Identical to TextureTest. > - (Coming soon) MeshTest2A. Identical to MeshTest2 > > > Test regions share object and texture references so if you are trying to > measure download rates or really exercise the network, you'll need to > defeat caching. Typically with a restart and manual cache clear or your > own preferred method. Aditi is also hosting some of the server-side baking > work and you may not get a reliable avatar appearance unless you use a > Sunshine project viewer. > > What we're looking for on these channels: > > DRTSIM-203. HTTP issues generally. HTTP texture download reliability and > throughput. Script writers using *llRequestURL* and *llRequestSecureURL*should try to get an A/B comparison going between a normal 'Second Life > Server' region on Aditi and DRTSIM-203. Particularly with competing > traffic like large texture or mesh downloads. Scripts aren't getting a > boost with this work but they shouldn't be adversely impacted. Mesh also > isn't getting a boost this time but, again, negative impact should be > avoided. Third-party viewer developers should test for overall > compatibility with all HTTP services. > > We're interested in reports of regressions in any areas. We *are* > expecting more 503 errors (0x01f70001) in log files as it will be possible > to push requests faster than before and certain throttles will be hit. As > long as these are recoverable, they're not a regression, they're an > indicator of better utilization. > > DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other > limits are generally raised. This may increase the tendency to get 503 and > 502 (0x01f60001) errors in some areas. Again, these aren't regressions as > long as they're recoverable. Subjective and objective comments on Mesh and > scripting behavior are sought here. > > DRTSIM-203A (Angry). This channel deliberately restricts resources and > uses a punitive enforcement policy that should result in a storm of 503 > errors. Viewers are expected to recover from these. Scripters can use > this to test against a (reliably unreliable?) grid to see if they're > handling recovery well. A higher error rate and lower throughput and > availability are expected here. What is being tested is viewer and script > robustness in the face of constraints. A more rigid enforcement policy, if > tolerated by external software, might actually allow us to set higher > limits if we can pull back when required. > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/a6ce5a2b/attachment.htm From kf6kjg at gmail.com Thu Mar 14 19:33:31 2013 From: kf6kjg at gmail.com (Ricky) Date: Thu, 14 Mar 2013 19:33:31 -0700 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: AFAIK Script -> External HTTP Server, Script -> HTTP Script Server (llRequest*URL), and external client -> HTTP Script Server (llRequest*URL) all use HTTP traffic in and out of the region server. Also, again AFAIK, many objects/textures/&c. are now being sent across HTTP to the connected viewers. The common thread here: the region handling HTTP connections. If those get throttled, anything using HTTP-based communication (viewers, scripts, &c.) all get impacted. Ricky Cron Stardust On Thu, Mar 14, 2013 at 6:46 PM, Darien Caldwell wrote: > I'm curious how a script would be expected to recover from a 'flurry of > 502/503' errors? If my HTTP enabled object is expecting to communicate with > my external-to-SL server, and instead receives an 503 error, all I could > see doing is to retry. So is hammering the server with retries really going > to improve sim conditions? > > Would this be expected when communicating with external-to-SL services, or > is this more likely to occur when a scripted service is trying to > communicate with another scripted service within the Grid? > > As well I am not sure why scripts are being included in this at all. The > HTTP issues as I understood were the number of http connections a viewer > had to handle, with another factor in that mix being the particular router > the resident uses and how well/badly it handled multiple HTTP connections. > Service to service communcations such as a script to an external server or > a script to another script shouldn't be a contributing factor in these > viewer connection problems. The connections should never be hitting any > viewer. > > - Dari > > > On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg wrote: > >> >> We now have three channels and a number of regions available for testing: >> >> >> - DRTSIM-203. Normal release intended to go to Agni supporting >> keepalive connections and other changes. Regions: >> - TextureTest2. High texture count, no meshes, low residency >> limit to prevent interference when doing benchmark testing. >> - (Coming soon) MeshTest2. High mesh count (many distinct mesh >> assets which all look the same), few textures. Low residency limit to >> prevent interference when doing benchmark testing. >> - DRTSIM-203H. Our 'Happy' channel with more generous limits and >> optimistic service controls. >> - TextureTest2H. Identical to TextureTest. >> - (Coming soon) MeshTest2H. Identical to MeshTest2 >> - DRTSIM-203A. Our 'Angry' channel with stricter and preemptive >> enforcement of limits (generates many 503 errors). >> - TextureTest2A. Identical to TextureTest. >> - (Coming soon) MeshTest2A. Identical to MeshTest2 >> >> >> Test regions share object and texture references so if you are trying to >> measure download rates or really exercise the network, you'll need to >> defeat caching. Typically with a restart and manual cache clear or your >> own preferred method. Aditi is also hosting some of the server-side baking >> work and you may not get a reliable avatar appearance unless you use a >> Sunshine project viewer. >> >> What we're looking for on these channels: >> >> DRTSIM-203. HTTP issues generally. HTTP texture download reliability >> and throughput. Script writers using *llRequestURL* and * >> llRequestSecureURL* should try to get an A/B comparison going between a >> normal 'Second Life Server' region on Aditi and DRTSIM-203. Particularly >> with competing traffic like large texture or mesh downloads. Scripts >> aren't getting a boost with this work but they shouldn't be adversely >> impacted. Mesh also isn't getting a boost this time but, again, negative >> impact should be avoided. Third-party viewer developers should test for >> overall compatibility with all HTTP services. >> >> We're interested in reports of regressions in any areas. We *are* >> expecting more 503 errors (0x01f70001) in log files as it will be possible >> to push requests faster than before and certain throttles will be hit. As >> long as these are recoverable, they're not a regression, they're an >> indicator of better utilization. >> >> DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other >> limits are generally raised. This may increase the tendency to get 503 and >> 502 (0x01f60001) errors in some areas. Again, these aren't regressions as >> long as they're recoverable. Subjective and objective comments on Mesh and >> scripting behavior are sought here. >> >> DRTSIM-203A (Angry). This channel deliberately restricts resources and >> uses a punitive enforcement policy that should result in a storm of 503 >> errors. Viewers are expected to recover from these. Scripters can use >> this to test against a (reliably unreliable?) grid to see if they're >> handling recovery well. A higher error rate and lower throughput and >> availability are expected here. What is being tested is viewer and script >> robustness in the face of constraints. A more rigid enforcement policy, if >> tolerated by external software, might actually allow us to set higher >> limits if we can pull back when required. >> >> >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/a0438a9e/attachment-0001.htm From monty at lindenlab.com Thu Mar 14 20:54:52 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 14 Mar 2013 23:54:52 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: <51429B8C.5030902@lindenlab.com> On 3/14/2013 9:46 PM, Darien Caldwell wrote: > As well I am not sure why scripts are being included in this at all. The > HTTP issues as I understood were the number of http connections a viewer > had to handle, with another factor in that mix being the particular > router the resident uses and how well/badly it handled multiple HTTP > connections. That only scratches the surface of the issues involved. Even for viewer-to-grid, there are a dozen or more independent variables. > Service to service communcations such as a script to an > external server or a script to another script shouldn't be a > contributing factor in these viewer connection problems. The connections > should never be hitting any viewer. It's a different communication path. llRequestURL and llRequestSecureURL are part of the service also called 'HTTP-In'. The HTTP server is in the script, the client is a non-viewer entity running out on the net. This path transits the gateways and so may be impacted indirectly (DRTSIM-203 channel) and directly (DRTSIM-203H channel) and is worth testing for those who've built services on them. From darien.caldwell at gmail.com Thu Mar 14 20:55:13 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu, 14 Mar 2013 20:55:13 -0700 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: Sure, it's all HTTP. But the issue as LL has been representing it, is not that the region can't handle the traffic, it's that the clients (the residents on their viewers) can't. I could see a blanket throttle if Regions were the problem, maybe. But The whole point of what LL has been doing is to limit the # of connections the clients require. That should in fact free up even more overhead for things that don't face the user at all, such as scripts. Not that they need more, from what I see they do quite fine as they are. (though there are more Squid failures than I like to see. :P ) So I'm a little confused. On Thu, Mar 14, 2013 at 7:33 PM, Ricky wrote: > AFAIK Script -> External HTTP Server, Script -> HTTP Script Server > (llRequest*URL), and external client -> HTTP Script Server (llRequest*URL) > all use HTTP traffic in and out of the region server. Also, again AFAIK, > many objects/textures/&c. are now being sent across HTTP to the connected > viewers. The common thread here: the region handling HTTP connections. If > those get throttled, anything using HTTP-based communication (viewers, > scripts, &c.) all get impacted. > > Ricky > Cron Stardust > > > On Thu, Mar 14, 2013 at 6:46 PM, Darien Caldwell < > darien.caldwell at gmail.com> wrote: > >> I'm curious how a script would be expected to recover from a 'flurry of >> 502/503' errors? If my HTTP enabled object is expecting to communicate with >> my external-to-SL server, and instead receives an 503 error, all I could >> see doing is to retry. So is hammering the server with retries really going >> to improve sim conditions? >> >> Would this be expected when communicating with external-to-SL services, >> or is this more likely to occur when a scripted service is trying to >> communicate with another scripted service within the Grid? >> >> As well I am not sure why scripts are being included in this at all. The >> HTTP issues as I understood were the number of http connections a viewer >> had to handle, with another factor in that mix being the particular router >> the resident uses and how well/badly it handled multiple HTTP connections. >> Service to service communcations such as a script to an external server or >> a script to another script shouldn't be a contributing factor in these >> viewer connection problems. The connections should never be hitting any >> viewer. >> >> - Dari >> >> >> On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg wrote: >> >>> >>> We now have three channels and a number of regions available for testing: >>> >>> >>> - DRTSIM-203. Normal release intended to go to Agni supporting >>> keepalive connections and other changes. Regions: >>> - TextureTest2. High texture count, no meshes, low residency >>> limit to prevent interference when doing benchmark testing. >>> - (Coming soon) MeshTest2. High mesh count (many distinct mesh >>> assets which all look the same), few textures. Low residency limit to >>> prevent interference when doing benchmark testing. >>> - DRTSIM-203H. Our 'Happy' channel with more generous limits >>> and optimistic service controls. >>> - TextureTest2H. Identical to TextureTest. >>> - (Coming soon) MeshTest2H. Identical to MeshTest2 >>> - DRTSIM-203A. Our 'Angry' channel with stricter and preemptive >>> enforcement of limits (generates many 503 errors). >>> - TextureTest2A. Identical to TextureTest. >>> - (Coming soon) MeshTest2A. Identical to MeshTest2 >>> >>> >>> Test regions share object and texture references so if you are trying to >>> measure download rates or really exercise the network, you'll need to >>> defeat caching. Typically with a restart and manual cache clear or your >>> own preferred method. Aditi is also hosting some of the server-side baking >>> work and you may not get a reliable avatar appearance unless you use a >>> Sunshine project viewer. >>> >>> What we're looking for on these channels: >>> >>> DRTSIM-203. HTTP issues generally. HTTP texture download reliability >>> and throughput. Script writers using *llRequestURL* and * >>> llRequestSecureURL* should try to get an A/B comparison going between a >>> normal 'Second Life Server' region on Aditi and DRTSIM-203. Particularly >>> with competing traffic like large texture or mesh downloads. Scripts >>> aren't getting a boost with this work but they shouldn't be adversely >>> impacted. Mesh also isn't getting a boost this time but, again, negative >>> impact should be avoided. Third-party viewer developers should test for >>> overall compatibility with all HTTP services. >>> >>> We're interested in reports of regressions in any areas. We *are* >>> expecting more 503 errors (0x01f70001) in log files as it will be possible >>> to push requests faster than before and certain throttles will be hit. As >>> long as these are recoverable, they're not a regression, they're an >>> indicator of better utilization. >>> >>> DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other >>> limits are generally raised. This may increase the tendency to get 503 and >>> 502 (0x01f60001) errors in some areas. Again, these aren't regressions as >>> long as they're recoverable. Subjective and objective comments on Mesh and >>> scripting behavior are sought here. >>> >>> DRTSIM-203A (Angry). This channel deliberately restricts resources and >>> uses a punitive enforcement policy that should result in a storm of 503 >>> errors. Viewers are expected to recover from these. Scripters can use >>> this to test against a (reliably unreliable?) grid to see if they're >>> handling recovery well. A higher error rate and lower throughput and >>> availability are expected here. What is being tested is viewer and script >>> robustness in the face of constraints. A more rigid enforcement policy, if >>> tolerated by external software, might actually allow us to set higher >>> limits if we can pull back when required. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/OpenSource-Dev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/bda9aec3/attachment.htm From darien.caldwell at gmail.com Thu Mar 14 22:06:02 2013 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu, 14 Mar 2013 22:06:02 -0700 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <5142679F.8070406@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: Are these regions on the Main grid or Beta grid? I can find MeshTest2 on both grids, but the server version is 13.03.04.271238, so I'm not clear that this is the correct server version. Also TextureTest2 on beta seems to be closed off. On Thu, Mar 14, 2013 at 5:13 PM, Monty Brandenberg wrote: > > We now have three channels and a number of regions available for testing: > > > - DRTSIM-203. Normal release intended to go to Agni supporting > keepalive connections and other changes. Regions: > - TextureTest2. High texture count, no meshes, low residency limit > to prevent interference when doing benchmark testing. > - (Coming soon) MeshTest2. High mesh count (many distinct mesh > assets which all look the same), few textures. Low residency limit to > prevent interference when doing benchmark testing. > - DRTSIM-203H. Our 'Happy' channel with more generous limits and > optimistic service controls. > - TextureTest2H. Identical to TextureTest. > - (Coming soon) MeshTest2H. Identical to MeshTest2 > - DRTSIM-203A. Our 'Angry' channel with stricter and preemptive > enforcement of limits (generates many 503 errors). > - TextureTest2A. Identical to TextureTest. > - (Coming soon) MeshTest2A. Identical to MeshTest2 > > > Test regions share object and texture references so if you are trying to > measure download rates or really exercise the network, you'll need to > defeat caching. Typically with a restart and manual cache clear or your > own preferred method. Aditi is also hosting some of the server-side baking > work and you may not get a reliable avatar appearance unless you use a > Sunshine project viewer. > > What we're looking for on these channels: > > DRTSIM-203. HTTP issues generally. HTTP texture download reliability and > throughput. Script writers using *llRequestURL* and *llRequestSecureURL*should try to get an A/B comparison going between a normal 'Second Life > Server' region on Aditi and DRTSIM-203. Particularly with competing > traffic like large texture or mesh downloads. Scripts aren't getting a > boost with this work but they shouldn't be adversely impacted. Mesh also > isn't getting a boost this time but, again, negative impact should be > avoided. Third-party viewer developers should test for overall > compatibility with all HTTP services. > > We're interested in reports of regressions in any areas. We *are* > expecting more 503 errors (0x01f70001) in log files as it will be possible > to push requests faster than before and certain throttles will be hit. As > long as these are recoverable, they're not a regression, they're an > indicator of better utilization. > > DRTSIM-203H (Happy). Scripts and mesh do get a boost here and other > limits are generally raised. This may increase the tendency to get 503 and > 502 (0x01f60001) errors in some areas. Again, these aren't regressions as > long as they're recoverable. Subjective and objective comments on Mesh and > scripting behavior are sought here. > > DRTSIM-203A (Angry). This channel deliberately restricts resources and > uses a punitive enforcement policy that should result in a storm of 503 > errors. Viewers are expected to recover from these. Scripters can use > this to test against a (reliably unreliable?) grid to see if they're > handling recovery well. A higher error rate and lower throughput and > availability are expected here. What is being tested is viewer and script > robustness in the face of constraints. A more rigid enforcement policy, if > tolerated by external software, might actually allow us to set higher > limits if we can pull back when required. > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130314/b45c0929/attachment-0001.htm From sldev at free.fr Fri Mar 15 06:35:06 2013 From: sldev at free.fr (Henri Beauchamp) Date: Fri, 15 Mar 2013 14:35:06 +0100 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <5142679F.8070406@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: <20130315143506.d40573a0.sldev@free.fr> On Thu, 14 Mar 2013 20:13:19 -0400, Monty Brandenberg wrote: > We now have three channels and a number of regions available for testing: > > .../... > o TextureTest2. High texture count, no meshes, low residency > limit to prevent interference when doing benchmark testing. > .../... > o TextureTest2H. Identical to TextureTest. > .../... > o TextureTest2A. Identical to TextureTest. "Sorry, you do not have access to this teleport destination"... Care to open access ?... Henri. From monty at lindenlab.com Fri Mar 15 07:37:14 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Fri, 15 Mar 2013 10:37:14 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <20130315143506.d40573a0.sldev@free.fr> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> <20130315143506.d40573a0.sldev@free.fr> Message-ID: <5143321A.8000604@lindenlab.com> On 3/15/2013 9:35 AM, Henri Beauchamp wrote: > On Thu, 14 Mar 2013 20:13:19 -0400, Monty Brandenberg wrote: > >> We now have three channels and a number of regions available for testing: >> >> .../... >> o TextureTest2. High texture count, no meshes, low residency >> limit to prevent interference when doing benchmark testing. >> .../... >> o TextureTest2H. Identical to TextureTest. >> .../... >> o TextureTest2A. Identical to TextureTest. > > "Sorry, you do not have access to this teleport destination"... > > Care to open access ?... That would help, wouldn't it? They should now be open for access. m From monty at lindenlab.com Fri Mar 15 07:41:14 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Fri, 15 Mar 2013 10:41:14 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: <5143330A.1000504@lindenlab.com> On 3/15/2013 1:06 AM, Darien Caldwell wrote: > Are these regions on the Main grid or Beta grid? I can find MeshTest2 > on both grids, but the server version is 13.03.04.271238, so I'm not > clear that this is the correct server version. Also TextureTest2 on beta > seems to be closed off. All on Aditi (and now open). MeshTest2 regions aren't set up yet. Working on them now, there will be a followup post when they're ready. The Server announcement for this is here: http://wiki.secondlife.com/wiki/Server_Beta_User_Group#Upcoming_Stuff Earlier announcement with diagram here: http://wiki.secondlife.com/w/index.php?title=Server_Beta_User_Group&oldid=1177159 From monty at lindenlab.com Fri Mar 15 17:56:49 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Fri, 15 Mar 2013 20:56:49 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <5142679F.8070406@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> Message-ID: <5143C351.2020007@lindenlab.com> On 3/14/2013 8:13 PM, Monty Brandenberg wrote: > > We now have three channels and a number of regions available for testing: > > * DRTSIM-203. Normal release intended to go to Agni supporting > keepalive connections and other changes. Regions: > o TextureTest2. High texture count, no meshes, low residency > limit to prevent interference when doing benchmark testing. > o (Coming soon) MeshTest2. High mesh count (many distinct mesh > assets which all look the same), few textures. Low residency > limit to prevent interference when doing benchmark testing. > * DRTSIM-203H. Our 'Happy' channel with more generous limits and > optimistic service controls. > o TextureTest2H. Identical to TextureTest. > o (Coming soon) MeshTest2H. Identical to MeshTest2 > * DRTSIM-203A. Our 'Angry' channel with stricter and preemptive > enforcement of limits (generates many 503 errors). > o TextureTest2A. Identical to TextureTest. > o (Coming soon) MeshTest2A. Identical to MeshTest2 Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are now up as well on Aditi. As with textures, these regions share meshes so you may want to clear cache as appropriate when switching between channels. From monty at lindenlab.com Mon Mar 18 09:06:24 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Mon, 18 Mar 2013 12:06:24 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <5143C351.2020007@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> <5143C351.2020007@lindenlab.com> Message-ID: <51473B80.8010200@lindenlab.com> On 3/15/2013 8:56 PM, Monty Brandenberg wrote: > Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are > now up as well on Aditi. As with textures, these regions share > meshes so you may want to clear cache as appropriate when switching > between channels. And now there are three sandbox regions on Aditi as well: Sandbox HTTP, Sandbox HTTP A, Sandbox HTTP H If there are any problems with these regions (and I can imagine I messed something up), let me know. From sitearm at gmail.com Wed Mar 20 13:31:00 2013 From: sitearm at gmail.com (Sitearm) Date: Wed, 20 Mar 2013 15:31:00 -0500 Subject: [opensource-dev] DSG Experiment needs a few more Participants; Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) In-Reply-To: References: Message-ID: *conducted on custom OpenSim servers using custom Firestorm Viewer (ll is in the loop)* Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) *Background Info and Signup Link* https://107.7.21.233/redmine/projects/moses/wiki/IntelSTTC_User_Scalability_Experiment_1 *Role Play Town (Brentville, Atropia) Screen Shot* *attached* ---------- Forwarded message ---------- From: ARL STTC Open Simulator Date: Wed, Mar 20, 2013 at 11:38 AM Subject: DSG Experiment needs a few more Participants (UNCLASSIFIED) To: MOSES LIST MOSES-LIST at lists.mitre.org UNCLASSIFIED We are currently at over 75% fill in the participants! This is not bad since the call for participants went out less than two weeks ago. We need to get a handful more blue force roles filled. If you have a colleague or other interested party that may be interested in this experiment, please feel free to pass along the signup information. I would like to reach a goal of 100 committed users by Friday morning. Upcoming Events: Thursday (Tomorrow) 21 March - walk through and tech support sessions from 1pm to 5pm EDT in the MOSES DSG Grid. Friday 22 March - Brief scrum at office hours (3PM at the Pentagon seating area in regular MOSES grid); scalability experiment at 6PM to 8PM EST in the MOSES DSG grid. The MOSES DSG grid is currently online and available for use. Thank you very much to the early explorers who have already been in to check it out. Have a great day everyone. -douglas Useful URLs: *Background:* https://107.7.21.233/redmine/projects/moses/wiki/IntelSTTC_User_Scalability_Experiment_1 *Signup: * http://107.7.21.233/form.php -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130320/e019dfea/attachment-0001.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: MOSES DSG Brentville_Atropia 2013 March18_001.png Type: image/png Size: 1708686 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130320/e019dfea/attachment-0001.png From nickyperian at yahoo.com Thu Mar 21 07:03:21 2013 From: nickyperian at yahoo.com (Nicky Perian) Date: Thu, 21 Mar 2013 07:03:21 -0700 (PDT) Subject: [opensource-dev] DSG Experiment needs a few more Participants; Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) In-Reply-To: References: Message-ID: <1363874601.22187.YahooMailNeo@web126106.mail.ne1.yahoo.com> I am getting security warnings from my browser when going to these links.? >________________________________ > From: Sitearm >To: opensource-dev at lists.secondlife.com >Sent: Wednesday, March 20, 2013 3:31 PM >Subject: [opensource-dev] DSG Experiment needs a few more Participants; Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) > > >conducted on custom OpenSim servers using custom Firestorm Viewer (ll is in the loop) > >Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) >? >Background Info and Signup Link >https://107.7.21.233/redmine/projects/moses/wiki/IntelSTTC_User_Scalability_Experiment_1 >? >Role Play Town (Brentville, Atropia) Screen Shot >attached > >---------- Forwarded message ---------- >From: ARL STTC Open Simulator >Date: Wed, Mar 20, 2013 at 11:38 AM >Subject: DSG Experiment needs a few more Participants (UNCLASSIFIED) >To: MOSES LIST MOSES-LIST at lists.mitre.org > >UNCLASSIFIED >We are currently at over 75% fill in the participants! This is not bad since the call for participants went out less than two weeks ago. We need to get a handful more blue force roles filled. If you have a colleague or other interested party that may be interested in this experiment, please feel free to pass along the signup information. I would like to reach a goal of 100 committed users by Friday morning. > >Upcoming Events: > >Thursday (Tomorrow) 21 March - walk through and tech support sessions from 1pm to 5pm EDT in the MOSES DSG Grid. >Friday 22 March - Brief scrum at office hours (3PM at the Pentagon seating area in regular MOSES grid); scalability experiment at 6PM to 8PM EST in the MOSES DSG grid. > >The MOSES DSG grid is currently online and available for use. Thank you very much to the early explorers who have already been in to check it out. Have a great day everyone. -douglas > >Useful URLs: >Background: >https://107.7.21.233/redmine/projects/moses/wiki/IntelSTTC_User_Scalability_Experiment_1 >Signup: >http://107.7.21.233/form.php > >? > > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/OpenSource-Dev >Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130321/0c2dbfbd/attachment.htm From sitearm at gmail.com Thu Mar 21 12:30:25 2013 From: sitearm at gmail.com (Sitearm) Date: Thu, 21 Mar 2013 14:30:25 -0500 Subject: [opensource-dev] Fwd: MOSES DSG Experiment Questions Received In-Reply-To: <22D1F4F95DAA4444AC49475D62D3C8888B7E201D@BY2PRD0310MB378.namprd03.prod.outlook.com> References: <22D1F4F95DAA4444AC49475D62D3C8888B7E201D@BY2PRD0310MB378.namprd03.prod.outlook.com> Message-ID: *this addresses Nickys question about getting a website warning notice - Moses is US Govt. not Commercially certified. It is OK to click Continue to Web.* ---------- Forwarded message ---------- From: McLennan, Kay L Date: Thu, Mar 21, 2013 at 6:13 AM Subject: MOSES DSG Experiment Questions Received To: ARL STTC Open Simulator , MOSES LIST I posted two "Uncle Sam and Aunt Intel Need You" calls for participation in the upcoming MOSES DSG experiment [on the Virtual Pedagogy and OSgrid.org G+ groups] and received a number of questions. In turn, I answered the questions "to the best of my knowledge" but thought I would pass on both the questions and my replies (in case either is of interest to future calls for participation in MOSES DSG experiments and/or merits immediate clarification). -- Question received: "I went to the sign-up link, but encountered a big red warning screen stating the site security certificate cannot be trusted...?" Answer given: "If the warning was on the federal site, the federal government self-certifies so the warning just means none of the commercial entities that certify sites are involved in certifying this federal government site. Alternatively, if the warning was on a viewer download site, the Phoenix Firestorm Project site (with the needed OpenSim version) is at http://wiki.phoenixviewer.com/downloads." Note: While my McAfee SiteAdvisor software allows me to access the http://wiki.phoenixviewer.com/downloads site, I get the same "Dangerous Site" warning when I try to access the http://www.firestormviewer.org site. -- Question received: "Do you know whether I can still participate with the old SL client circa 2009, or must I download whatever the newest one is?" Answer given: "You will need to download a Firestorm viewer (read: the OpenSim version) and further, input the MOSES DSG grid coordinates into the viewer. In other words, the test is NOT taking place in Second Life (and accordingly, cannot be accessed using the Second Life viewer)." -- Question received: [From someone that cannot participate in the experiment tomorrow...] "Will there be any future [MOSES DSG] experiments?" Answer given: "I will re-post any future calls for participants. [As an aside, like you, I hope there will be another call for participants since I have schedule conflict tomorrow too!]" Again, in case any of the above merits immediate revision (or just FYI), I wanted to forward the questions I have received to date. "Break a leg tomorrow!" Best, Kay Kay L. McLennan, Ph.D. Professor of Practice School of Continuing Studies Tulane University kmclenna at tulane.edu e-Teaching in Virtual Worlds @ https://sites.google.com/site/fvwc12mclennan/ e-Course Teaching Schedule & Syllabi @ http://www.tulane.edu/~kmclenna/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20130321/95f094fc/attachment.htm From sldev at free.fr Thu Mar 21 12:58:11 2013 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 21 Mar 2013 20:58:11 +0100 Subject: [opensource-dev] DSG Experiment needs a few more Participants; Distributed Scene Graph Experiment (100's of Virtual World Simultaneous Users Online) In-Reply-To: <1363874601.22187.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <1363874601.22187.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <20130321205811.3ab0a1f2.sldev@free.fr> On Thu, 21 Mar 2013 07:03:21 -0700 (PDT), Nicky Perian wrote: > I am getting security warnings from my browser when going to these > links.? Probably an invalid certificate (self-certifed site). Plus, the URL contains an IP (107.7.21.233) instead of a domain name, and there is no reverse-DNS entry for this IP ('nslookup 107.7.21.233' returns: ** server can't find 233.21.7.107.in-addr.arpa.: NXDOMAIN). If I were you, I would simply not try to follow such a link... I am also quite surprised by these emails we get in this list: I don't see any interest in them (I don't even see what they are supposed to deal with: in what aspect are they at all related to viewers development ?). They also got huge attachments (pictures), which makes them a pain to retrieve when your connection is slow. Not sure what is the list moderator's stance on this... Henri. From monty at lindenlab.com Sat Mar 23 12:05:37 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Sat, 23 Mar 2013 15:05:37 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <51473B80.8010200@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> <5143C351.2020007@lindenlab.com> <51473B80.8010200@lindenlab.com> Message-ID: <514DFD01.8070807@lindenlab.com> The three DRTSIM-203 channels on Aditi have been updated with a new build with a fix for SH-4026. This involves expired/revoked caps returning 502 on access rather than the traditional 404. 404 should be the norm once again. m From monty at lindenlab.com Wed Mar 27 09:16:28 2013 From: monty at lindenlab.com (Monty Brandenberg) Date: Wed, 27 Mar 2013 12:16:28 -0400 Subject: [opensource-dev] HTTP connection changes heading to Aditi in the near future In-Reply-To: <51473B80.8010200@lindenlab.com> References: <51350A28.7040100@lindenlab.com> <5142679F.8070406@lindenlab.com> <5143C351.2020007@lindenlab.com> <51473B80.8010200@lindenlab.com> Message-ID: <51531B5C.8030106@lindenlab.com> On 3/18/2013 12:06 PM, Monty Brandenberg wrote: > On 3/15/2013 8:56 PM, Monty Brandenberg wrote: > >> Three Mesh testing regions (MeshTest2, MeshTest2A, MeshTest2H) are >> now up as well on Aditi. As with textures, these regions share >> meshes so you may want to clear cache as appropriate when switching >> between channels. > > And now there are three sandbox regions on Aditi as well: > Sandbox HTTP, Sandbox HTTP A, Sandbox HTTP H > > If there are any problems with these regions (and I can > imagine I messed something up), let me know. It looks like Beta will be wrapped up shortly. If you've wanted to try these out but haven't yet, now would be a good time to jump in there. m