From thordain at thordain.com Fri Aug 1 00:53:03 2008 From: thordain at thordain.com (Thordain Curtis) Date: Fri Aug 1 00:53:05 2008 Subject: [sldev] Physical Object Prim Limitation In-Reply-To: <48924ED3.2040705@signpostmarv.name> References: <7F67ABB0-46B2-431C-B29E-ADFCE5326490@gmail.com> <48924ED3.2040705@signpostmarv.name> Message-ID: This has generated quite a bit more discussion than I had originally anticipated ;-). I've taken Soft's advice and created a JIRA issue describing the possible new feature. I've included both the llSetObjectColllisionPrimCount() implementation as well as the "Phantom" idea. Argent's STATUS_PHYSICAL_SIMPLE solution can be acheived by both of these implementations without additional changes to the server. SignpostMarv's sculpty solution is interesting, however the physics engine currently represents sculpted prims using a 3d ellipsoid and it is my experience that for complex shapes said ellipsoid is ... very approximated ;-). If the simulator allowed portrayal of sculpted prims using their actual mesh in the future, once again, both the llSOCPC and Phantom implementations would allow for this. The JIRA issue can be found at: http://jira.secondlife.com/browse/SVC-2726 Thanks for all the feedback! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080801/a65f76c5/attachment.htm From thordain at thordain.com Fri Aug 1 01:23:10 2008 From: thordain at thordain.com (Thordain Curtis) Date: Fri Aug 1 01:23:12 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: References: Message-ID: While the ability to edit linksets from the inventory pane would certainly be an interesting way to do things, the assertion that such functionality is a requirement of what I have suggested is incorrect. If you dabble in the world of complex scripted objects, inevitably you will end up with objects that require a certain link order (of some type) to perform the task they are scripted to do. Some times it easy enough to name said child-prims and have your scripts "scan" for the correct link numbers, some times it's not. In either case, properly linking the object in question is a task for the developer of said product. I think it's fairly safe to assume that anyone who can't figure out how to link an object in the order they want it to be in does not posess the skills requisit to creating complex, dynamic physical objects. In any event, while what you recommended would without question ease the development of complicated objects, it would also without question require _massive_ changes on both the client and server. This is especially true considering that neither hierarchical linksets nor hierarchical task inventory currently exist. Both of those changes would require massive refactoring on their own. My proposal for large physical linksets is certainly not the first solution I've come up with to enable it (and certainly not my favorite), but I've taken the time to put this one to the list (and on JIRA now) because I feel it can be implemented with few changes to server code, because it affords 100% backwards compatibility to existing objects, and because in addition to allowing for new features it can also fall under the category of "increasing simulator performance." That being said, I'll gladly donate my first born to the Linden(s) who implement hierarchical link sets ;-) On Thu, Jul 31, 2008 at 7:42 PM, Dale Mahalko wrote: > On Wed, Jul 30, 2008 at 10:57 PM, Thordain Curtis > wrote: > > An interesting solution would be to allow all linksets to become > physical, > > but only use the first 32 prims as the actual collision model. > > > To do what you want, the inventory window must be redesigned to allow > editing the link list without first rezzing the object in-world. This > would be done by putting little [+] and [-] boxes in front of the > object/linkset name in the inventory window. This would allow you to > expand a linkset directly in the inventory window, and drag and drop > objects in the link list to change object ordering, to easily set > which ones primitives are the first 32 physical objects. > > With the current totally inadequate inventory system, to reorder the > primitives in a linkset you have to: rez the object in-world, unlink > the entire linkset, deselect everything, hold down shift and carefully > reselect each part in order, relink, and take it back into your > inventory. (This is assuming you don't screw up halfway through > reselecting your 200 prims and have to unlink it all and start over > again.) > > > On an related topic, it is a major annoyance that we cannot edit the > inventory inside an object without first rezzing the parent object > in-world. It is even more aggravating trying to edit a single > inventory object that is several levels down inside the inventories of > other objects. Why can't we just expand a second little [+] in the > inventory window next to an object and directly view or edit the > inventory items inside that object, all from within the Inventory > window? > > > Since a fully functional object/linkset hierarchy user interface does > not currently exist in the viewer, I've created a JIRA for this, with > an example image of how this user interface might work.. :-) > > JIRA: Need a full Inventory Hierarchy, to simplify linkset management > and inventories inside objects > http://jira.secondlife.com/browse/VWR-8444 > > My image example of a fully hierarchical inventory/linkset user interface: > > http://jira.secondlife.com/secure/attachment/17920/Full+Hierarchical+Inventory+Model+2.PNG > > I am not suggesting implementing skeletal linksets, joints, or > changing the physics engine.. just merely making the viewer inventory > window support functionality that already exists in a halfway, kludgy > manner via rezzing objects inworld and editing them that way.. > > > - Scalar Tardis / Dale Mahalko > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080801/e8bf79ed/attachment-0001.htm From mpilat at ubicore.ro Fri Aug 1 04:55:27 2008 From: mpilat at ubicore.ro (Mircea Pilat) Date: Fri Aug 1 04:56:09 2008 Subject: [sldev] SL viewer chrash while login to OpenSim server Message-ID: <200808011455.28643.mpilat@ubicore.ro> Hi, Trying to connect with : Second Life viewer, version 1.20.15 (July 23rd 2008) at OpenSim server - version 0.5.8 - (official build) - first it starts OK, showing the Login WEB page. - after I complete the login form and press the "Connect" button - SL client crash. The server console show Authenticated user. Command line used to connect: c:\> SecondLife.exe -loginuri http://opemsimServer:9000/ -loginpage http://opensimServer:9000/?method=login Mircea, This email has been ClamScanned ! From robin.cornelius at gmail.com Fri Aug 1 05:36:22 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 1 05:36:24 2008 Subject: [sldev] SL viewer chrash while login to OpenSim server In-Reply-To: <200808011455.28643.mpilat@ubicore.ro> References: <200808011455.28643.mpilat@ubicore.ro> Message-ID: On Fri, Aug 1, 2008 at 12:55 PM, Mircea Pilat wrote: > Hi, > > Trying to connect with : > Second Life viewer, version 1.20.15 (July 23rd 2008) > at OpenSim server - version 0.5.8 - (official build) > > - first it starts OK, showing the Login WEB page. > - after I complete the login form and press the "Connect" button - SL client crash. > The server console show Authenticated user. > > Command line used to connect: > c:\> SecondLife.exe -loginuri http://opemsimServer:9000/ -loginpage http://opensimServer:9000/?method=login > Have you tried looking at the log for any more detailed info on why it crashed? When playing with opensim I've only ever used the -loginuri might be worth testing without the -loginpage. What about the opensim log, anything strange there too? If that fails you may need to compile your own viewer so you can run it under debug to see what is wrong. Robin From secret.argent at gmail.com Fri Aug 1 06:12:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 1 06:11:53 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: References: Message-ID: On 2008-07-31, at 18:42, Dale Mahalko wrote: > With the current totally inadequate inventory system, to reorder the > primitives in a linkset you have to: rez the object in-world, unlink > the entire linkset, deselect everything, hold down shift and carefully > reselect each part in order, relink, and take it back into your > inventory. (This is assuming you don't screw up halfway through > reselecting your 200 prims and have to unlink it all and start over > again.) You shouldn't need to unlink the whole thing for this case, just unlink the first N prims, link them together, then link the rest of the prims because you don't care about the order... I suspect that you'd need fairly deep changes in the asset system to implement this change in the user interface, by the way. Not that I don't like it, I'm just sayin'... From robin.cornelius at gmail.com Fri Aug 1 06:55:19 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 1 06:55:24 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: References: Message-ID: On Fri, Aug 1, 2008 at 2:12 PM, Argent Stonecutter wrote: > On 2008-07-31, at 18:42, Dale Mahalko wrote: >> >> With the current totally inadequate inventory system, to reorder the >> primitives in a linkset you have to: rez the object in-world, unlink >> the entire linkset, deselect everything, hold down shift and carefully >> reselect each part in order, relink, and take it back into your >> inventory. (This is assuming you don't screw up halfway through >> reselecting your 200 prims and have to unlink it all and start over >> again.) > > You shouldn't need to unlink the whole thing for this case, just unlink the > first N prims, link them together, then link the rest of the prims because > you don't care about the order... > > I suspect that you'd need fairly deep changes in the asset system to > implement this change in the user interface, by the way. Its all handled by the selection manager, and looks like this is a server side thing. The objects in the link set are pushed to the server in order with a ObjectLink message so the server handles the actual "linking" as it is based on the order it receives data on the objects to be linked. This would make changing the link order difficult unless the client side implemented the "smartness" as it knows the link order so it could let you reorder as you please then just push the new list as a whole to the server, the question is when to push the list as you would not want to do this every change as you may want to renumber a whole bunch (and this would generate loads of pointless messages), and it would have to manage the list order. Almost need a floater to show the link order and allow reordering with an OK when done to push the list. Actually that does not sound that difficult. Robin From mpilat at ubicore.ro Fri Aug 1 07:30:29 2008 From: mpilat at ubicore.ro (Mircea Pilat) Date: Fri Aug 1 07:31:12 2008 Subject: [sldev] SL viewer chrash while login to OpenSim server In-Reply-To: References: <200808011455.28643.mpilat@ubicore.ro> Message-ID: <200808011730.29496.mpilat@ubicore.ro> Got- it. I had use for debug an older SL viewer (that I can compile & run: 1.19.10). The client is trying use (instead one I write in the WEB page fields): First Name: "" Last Name: "" and fails after: LLDir:setLindenUserDir() exit with error..and crash later on. (doh!) So, indeed: do not try to use the '-loginpage' cmd line parameter. Login using SL input fields works fine ...got myself an island :). Mircea, On Friday 01 August 2008 15:36, Robin Cornelius wrote: > On Fri, Aug 1, 2008 at 12:55 PM, Mircea Pilat wrote: > > Hi, > > > > Trying to connect with : > > Second Life viewer, version 1.20.15 (July 23rd 2008) > > at OpenSim server - version 0.5.8 - (official build) > > > > - first it starts OK, showing the Login WEB page. > > - after I complete the login form and press the "Connect" button - SL client crash. > > The server console show Authenticated user. > > > > Command line used to connect: > > c:\> SecondLife.exe -loginuri http://opemsimServer:9000/ -loginpage http://opensimServer:9000/?method=login > > > > Have you tried looking at the log for any more detailed info on why it > crashed? When playing with opensim I've only ever used the -loginuri > might be worth testing without the -loginpage. What about the opensim > log, anything strange there too? > > If that fails you may need to compile your own viewer so you can run > it under debug to see what is wrong. > > Robin > This email has been ClamScanned ! > This email has been ClamScanned ! From bill.hoffman at kitware.com Fri Aug 1 10:14:19 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Aug 1 10:15:22 2008 Subject: [sldev] CMake 2.6.1 available for download Message-ID: <4893446B.5070901@kitware.com> On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.6.1 is available for download at: http://www.cmake.org/HTML/Download.html If you have any problems or find any bugs, please report them at www.cmake.org/Bug. A list of changes for the 2.6 release tree is included below. Thanks Bill Changes in CMake 2.6.1 RC 16 - Fix for bug 7427, preinstall target name hard coded - Fix issue #7088 - do not emit error messages when attempts to run Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line. - Fix InstallRequiredSystemLibraries.cmake to work with win64 Changes in CMake 2.6.1 RC 15 - Fix bug 7426 FindJPEG module causes error when setting JPEG_LIBRARY to blank - Fix bug 7414 PackageMaker generator crashes when given components with circular dependencies - Fix source files to not add extra /, and look for extensions for all enabled languages. - Change link line to preserve input given to target_link_libraries even if a shared library is repeated. - Fix for bug 7421, fortran did not get arch flags on the mac - For CMP0008 do not depend on the files that are not there, which makes the Xcode generator delete executables after they are built. - Work around Boost 1.36.0 bug fix on Darwin by setting the mangled compiler name to -xgccVERSION - Updated FindImageMagick to: - Find newer additions such as animate, compare, etc. - Find development api: Magick++, MagickCore, MagickWand - Use FindPackageHandleStandardArgs to output standard messages. Changes in CMake 2.6.1 RC 14 - Change dashboard submission to go directly to CDash. - Add policy CMP0008- Full-path libraries must be a valid library file name Changes in CMake 2.6.1 RC 12 - More find locations for FindJNI. - Fix bug with source files ending in .l and .l.cpp, causing cmake to think they were the same file in some cases. - Fix issue with .lib being seen as .obj with VS due to a full path to a library given without the file extension. This only worked with the VS generator, but some projects had worked around it with if statements. It now issues a warning, but should link. - Update cpack stuff for beta OSX bundle generator for CPack - CheckFortranFunctionExists.cmake now calls the function. - FindBLAS.cmake, FindLAPACK.cmake modules were redesigned so now you have three new variables BLA_VENDOR (you can specify the VENDOR), BLA_STATIC (gets the static version of libs), BLA_F95 (gets the fortran 95 interface). BLA_VENDOR can be specified as an environment variable. Intel mkls libs need FindThreads to be found correctly so you will need to enable the C/CXX - FindMPI: Use the HINTS feature of find_library to find the right libraries for MPI, and act a bit more intelligently when MPI cannot be found. - Improved support for finding wxWidgets in MinGW environment. - CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables moved CMAKE_CROSSCOMPILING from "Variables that modify behaviour" to "variables that Provide Information" - handle HTML documentation for single items better: no warning about ComputeSectionLinkPrefix, don't create an index for only one item. - Better error messages in CPackBundleGenerator Changes in CMake 2.6.1 RC 11 - Fix curl build issue with Xcode 3.1 Changes in CMake 2.6.1 RC 10 - Add a fix for bug # 7340, CMAKE_USER_MAKE_RULES_OVERRIDE was not able to support a try-compile in cmake 2.6 - Remove bad test for bug # 7316 Changes in CMake 2.6.1 RC 9 - Fix bug # 7316 Xcode double escaped define strings - FindBoost can now find the upcoming Boost 1.36 Changes in CMake 2.6.1 RC 8 - Fix build problem with missing cpack file Changes in CMake 2.6.1 RC 7 - More fixes for CPack components functionality - Fixes for Xcode generater #7277 #7044, do not compile foo.txt. Rebuild application bundles when a library changes. Set the project location for Xcode 3.1 - Do not automatically add EXECUTABLE_OUTPUT_PATH to cache. - New tree view in cmake-gui - FindBoost.cmake, find boost as installed by the BoostPro/Boost Consulting installers on Windows. And cleanup FindBoost module, fixing several small bugs and providing better diagnostic information when things go wrong. - Fix FindwxWidgets.cmake to find richtext library - Fix FindQt4.cmake with empty qconfig.pri files. Fixes #7287. - Fix add/remove program version string again... - Fix column width in cmake-gui Changes in CMake 2.6.1 RC 6 - Fix DEFINITIONS property to be compatible with 2.4 - Fix escaping of $ for visual studio - FindGettext.cmake fix bug #7230: don't ignore first parameter if it's not ALL Changes in CMake 2.6.1 RC 5 - Add support for component based packages in cpack. - Fix FindBLAS.cmake if no fortran compiler is found - Fix FindFLTK.cmake to pass new module test - Fix FindKDE3.cmake to not add flags if kde3 is not found - Fix FindMatlab.cmake, FindOpenSSL.cmake, FindQt3.cmake, FindSWIG.cmake, to only error if it is required - Fix FindwxWidgets.cmake to work on msys - Add a beta OSX bundle generator for CPack - Fix bug in cmake --build-and-test where cmake output was lost - Fix ctest handling of CDash dart measurement support - Add a group view to cmake-gui - Fix nmake/make with visual studio compiler to handle long link lines - Fix FLTK_WRAP_UI to better notice when mistakes are made with the target name - Fix spelling error EnableFiberSafeOptimizations Changes in CMake 2.6.1 RC 4 - Change to find_*, a new HINTS keyword was added to avoid the need for NO_DEFAULT_PATH, and a repeated call to find_* - Update all NO_DEFAULT_PATH usage in Modules/Find* - Fix for cpack self extracting .sh files to work with more shells - FindQt4 now finds dependencies for some qt modules - ctest cpu information fixes for cygwin and linux - Recognize more color terminals for color output - Remove SKIP_RULE_DEPENDS from custom command because CMake now can detect when a cutom command actually changes and only re-run the rule then. This fixes the problem of custom commands re-running every time a file is added to a target. - Fix for very slow find_path on OSX because of framework searchs - Fix for bug 6364, extra help targets when there are subdirectories of the top level. - Fix for Xcode generator to not eat some flags by mistake. - Add end of file checking for close if, foreach, macro, functions etc enabled. Changes in CMake 2.6.1 RC 3 - FindQt4 - Find qt debug libraries on windows with d postfix. - Find 64 bit windows registry stuff with 32 bit cmake - Give a message if rpath is changed during install - rpath changer during install understands symlinks now - If a source file is not found and is a full path cmake complains. Changes in CMake 2.6.1 RC 2 - FindQt4 - report an error when trying to use MSVC with Qt built by mingw. - FindQt4 - make Qt not found if the QtCore library can't be found. - UseQt4 - only add flags for modles that are used - Log file and LC_ALL fix for FindSubversion - Make MacOSXBundleInfo.plist.in a configured file again - Fix makefile generator targets to depend on full path link libraries - Allow CMakeImportBuildSettings to not match tools if CMAKE_OVERRIDE_COMPILER_MISMATCH is set - Fix incorrect extension extraction in gcc cross compiler check - Add support for Portand Fortran - Fix list command with empty list values - Add support for setting compiler and toolchain in qt cmake-gui - Fix Bug 7011, FindQt4 was slow on a mac, find_path should not glob in / - Fix install directories for cygwin package of CMake Changes in CMake 2.6.1 RC 1 - Add a way to modify depend scanning with the property: IMPLICIT_DEPENDS_INCLUDE_TRANSFORM - Add a way for custom commands to skip depending on the rule.make file - Fix ENABLE_LANGUAGE(ASM-ATT OPTIONAL) to work - Fix gcov in ctest in French or other non-English runs - Fix help for ctest commands to be lower case - Find QtCLucene on Qt/Mac binary - Fix for build on ARM - Fix for docbook to add newlines - Fix -Wno-dev to not eat path to source tree - Fix bug in NSIS CPack where CPACK_NSIS_MODIFY_PATH did modify the path - Fix FindBoost version variable names to correct bug in Boost version - Fix Add/Remove program name for CMake install on windows - Fix bug 0006988 coverage not reported on dashboards - Fix bug 0006990 CMake crashes with bad input to set_source_files_properties - Fix bug in FindCurses where you could not run cmake twice - Fix 64 bit cmake creation of Xcode projects - Add --help-policy to --help Changes in CMake 2.6.0 - Fix links in generated documentation - Fix for FindQt and some mac frameworks - Fix for ctest to report more than 2 gigs system memory on windows - Fix CTest build name for vs 9, and fix memory size on windows Changes in CMake 2.6.0 RC 10 - Do not duplicate .so libraries on the link line - Add more system library paths to sun builds - Add BETA support for Intel Fortran IDE files in visual studio - Fix FindCurses to work if ncurses is the only option - Fix shell escapes on some systems - Remove check for file write as input to cmake, as it is no longer needed - Make check_type_size automatically check for headers that it uses - Remove minimum required from FindBoost.cmake - Fix FindSDL so that it can be run more than once - Fix find required for VTK package - Allow for CMAKE_OSX_SYSROOT to work with single architecture - Add context information when a source file cannot be found. - Report the directory-level context even if no list file is currently being processed. Changes in CMake 2.6.0 RC 9 - Fix for fortran mod:: support - Fix bug in install command with BUNDLE DESTINATION - Make mac install symlinks check for errors - Fix for CMP0007, to not warn about empty lists - Preserve static libraries when linked multiple times - Use c compiler path to find asm compiler - Allow RC compiler to not get all COMPILE_FLAGS - Complete overhaul for FindBoost.cmake - Minor fixes for FindMPI.cmake - Fix for list command and empty list elements CMP0007 - Fix for VS6 and sub-groups - Fix bug 6440, and make sure _INIT flags do not overright cache values - Do not report CMP0003 for anything other than -l - Fix crash in fortran depend scanning, bug 6855 - Fix timeout values for cmake's own tests - Better message in compiler ABI detect - Fixes for cpack x11 packages on leopard - Changes to cpack options names - Fixes for FindMPI on 64 bit MS MPI - Fix for -isystem for wxWidgets - Some fixes for chrpath during installation - Fix compatibility with CMake 2.4 for installation of MACOSX_BUNDLE (CMP0006) - Do not use debug postfix when building frameworks on the Mac - Fix exception handling off/on issue with visual studio IDE generators - Fix to be native path style - Fix leak in cpack - Some Qt GUI style changes Changes in CMake 2.6.0 RC 8 - Fix sun make very poor performance - Fix includes for automoc in FindQt4 Changes in CMake 2.6.0 RC 7 - Fix for chrpath on sun with gcc - Fix FindJNI on unix with HKEY issue bug 6688 - Change install location on mac for cmake-gui - Fix for bugs 6730 and 6720 in FindQt4 configured headers in binary dir - Add VS9 support to InstallRequiredSystemLibraries.cmake - Fix some bugs in framework support - Have make edit_cache work with cmake-gui and eclipse generator - Fix find_* to not mistakenly construct network paths on windows - Several bug fixes in cmake-gui Qt program. Changes in CMake 2.6.0 RC 6 - Added ChangeLog.manual - Allow CMakeImportBuildSettings force compiler to be optional - Change cpack deb packager to detect the architecture - Fix FindCurses to be backwards compatible with cache variable CURSES_LIBRARY - Add version variables to FindQt4.cmake - Fix CPack Deb generator to not hard code /usr - Better default size for cmake-gui help dialog - Fix problem where incorrect path was used for cmake.exe when used to do incremental linking on windows nmake or make - Fix build with system libraries on - Add color output in kdevelop - Create non-verbose makefiles in kdevelop - Fix some missing flags for vs IDE flag map - Fix MacOSX install symlink crash problem - Fix turning of Dev warnings with gui's - Fix backwards compatibility issue with FindMPI.cmake - Fix for bug 6605, add -L path for optimized in debug sometimes for backwards compatibility - Allow for CMP0000 to be set before any warnings happen - Do not use FAT32 hack in VS 2005 and 2008 unless on a FAT32 disk, causes try-compiles to be 3 times slower if FAT hack is present. - Fixes to debian cpack - Can now check if a proprty is SET or not - Fix for generate with vs 2005 and vista not being able to create stamp file - set_property with an empty value unsets that property now - Fix FindQt4 on windows with some \ style paths Changes in CMake 2.6.0 - Documentation for all variables - Automatic reload of projects in visual stuido 7 and greater when cmake is re-run. - Direct CDash submit support - Bullseye coverage support - Use full paths for linking to libraries on all platforms. No longer separate into -L and -l. - Enhance the install command - export command and ability to have imported targets - CPack support for rpm and deb - Cross compile support - New Qt GUI - Introduction of the cmake_policy command - Much better Fortran support - Mac OSX Framework creation support - Project generators for Eclipse and CodeBlocks - Beta support for asm in makefiles - Enhanced find_package() command with support for project-installed FooConfig.cmake files - New CMAKE_PREFIX_PATH environment variable to specify user search dirs for find_xxx() - Lots of bug fixes From secret.argent at gmail.com Fri Aug 1 11:09:54 2008 From: secret.argent at gmail.com (Argent) Date: Fri Aug 1 11:09:56 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: References: Message-ID: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> On Fri, Aug 1, 2008 at 8:55 AM, Robin Cornelius wrote: [a bunch of stuff that's confusing me a little... which I suspect is my fault for confusing you] When I wrote: > > I suspect that you'd need fairly deep changes in the asset system to > > implement this change in the user interface, by the way. > I was referring to implementing things like relinking objects without rezzing them into the world, through the Inventory interface. It sounds like you're mixing this up with the previous paragraph... my comment about using the existing user interface to link a few prims at the beginning of the link set without unlinking the whole thing. Or do you mean that my suggested process doesn't work? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080801/91737101/attachment.htm From robin.cornelius at gmail.com Sat Aug 2 00:53:55 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 2 00:53:59 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> Message-ID: <48941293.1050906@gmail.com> Argent wrote: > On Fri, Aug 1, 2008 at 8:55 AM, Robin Cornelius > > wrote: > [a bunch of stuff that's confusing me a little... which I suspect is my > fault for confusing you] > > When I wrote: > > > I suspect that you'd need fairly deep changes in the asset system to > > implement this change in the user interface, by the way. > > > I was referring to implementing things like relinking objects without > rezzing them into the world, through the Inventory interface. > > It sounds like you're mixing this up with the previous paragraph... my > comment about using the existing user interface to link a few prims at > the beginning of the link set without unlinking the whole thing. Or do > you mean that my suggested process doesn't work? > > Looks like it ;-) Yea changing the link order without rezing in world would appear to require server side changes as its all handled by the simulator. So with out a simulator presence the things are only assets and not objects. But a general tool for advanced fiddling with the link order of rezed objects, could be useful and only a viewer side change. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080802/db340fe2/signature.pgp From secret.argent at gmail.com Sat Aug 2 12:18:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 2 12:18:23 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: <48941293.1050906@gmail.com> References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> <48941293.1050906@gmail.com> Message-ID: <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> On 2008-08-02, at 02:53, Robin Cornelius wrote: > But a general tool for advanced fiddling with the link order of rezed > objects, could be useful and only a viewer side change. OK, but in the meantime, if you only need to put a small number of prims at the head of the list, that can be done without unlinking a whole 200 prim linkset, yes no? From robin.cornelius at gmail.com Sat Aug 2 13:02:19 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 2 12:53:40 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> <48941293.1050906@gmail.com> <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> Message-ID: <4894BD4B.3000509@gmail.com> Argent Stonecutter wrote: > On 2008-08-02, at 02:53, Robin Cornelius wrote: >> But a general tool for advanced fiddling with the link order of rezed >> objects, could be useful and only a viewer side change. > > OK, but in the meantime, if you only need to put a small number of > prims at the head of the list, that can be done without unlinking a > whole 200 prim linkset, yes no? Yes, you can unlink specific prims from a 200 link set leaving the rest linked. Then it would be trivial to relink selecting the linkset first and the prims to go at the head 2nd. You can using edit linked parts select all prims to unlink and do this in one operation, its not possible to keep the selection on all (just) the newley unlinked prims so you still need to reselect these for the relink individually. What you can do to relink is select the remaining linked prims first, use the drag selector to select the rest and then just unselected and reselect the required root prim. WHat this will give you is the original linked prims, the newly selected prims in *some*order + one that you have set as the root. Of cause this becomes less trivial the more prims you need to remove and of cause how easy it is to access the prims you wish to change a if they are very small prims they could be hidden and difficult to click on to select. Regards Robin From dmahalko at gmail.com Sat Aug 2 14:01:46 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Aug 2 14:01:48 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> <48941293.1050906@gmail.com> <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> Message-ID: On Sat, Aug 2, 2008 at 2:18 PM, Argent Stonecutter wrote: > OK, but in the meantime, if you only need to put a small number of prims at > the head of the list, that can be done without unlinking a whole 200 prim > linkset, yes no? You're making an assumption that the person doing this manually obtuse edit process will: - always have perfect dexterity manipulating this fragile selection state - won't get bumped or disturbed by someone when the linkset is in the fragile selection state - doesn't have pets or children or any other local distraction that might cause the fragile selection state to accidently become fully deselected. Just because you can do something the ridiculously delicate and ultra-geekish without handholding via a proper user interface, doesn't mean that the rest of us should have to suffer right along with you doing things this way. - Scalar Tardis / Dale Mahalko From dazz_anvil at hotmail.com Sat Aug 2 15:23:41 2008 From: dazz_anvil at hotmail.com (Dazz Anvil) Date: Sat Aug 2 15:23:43 2008 Subject: [sldev] CMake build fails in windows VC2003 llkdu.dll missing Message-ID: Following the instructions outlined at http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake the build process with Visual Studio 2003 fails during the following step: ------ Build started: Project: copy_win_libs, Configuration: RelWithDebInfo Win32 ------ Copying llkdu.dll C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo Error copying file (if different) from "C:/secondlife/release/indra/../libraries/i686-win32/lib/release/llkdu.dll" to "C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo/llkdu.dll". Project : error PRJ0019: A tool returned an error code from "Copying llkdu.dll C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo" � Build log was saved at "file://c:\secondlife\release\indra\build-vc71\newview\copy_win_libs.dir\RelWithDebInfo\BuildLog.htm"� copy_win_libs - 1 error(s), 0 warning(s)� A search of the directories under "c:\secondlife" reveals that the file llkdu.dll is not present. The asset_urls.txt file is asking for: http://secondlife.com/developers/opensource/downloads/2008/07/slviewer-win32-libs-release-r93138.zip. I'm assuming this is the zip file that is supposed to contain the precompiled libraries. There are, however, only a few fonts in that zip file. This particular zip file is only 96KBytes long compared to slviewer-win32-libs-Branch_1-20-Viewer-2-r92456.zip, available from the wiki source download page, which does contain llkdu.dll and is 53MBytes long. Should I attempt to build with the libraries from the RC viewer, or is there another set of libraries I should be getting from SVN? Any ideas? Thanks, Dazz _________________________________________________________________ Get Windows Live and get whatever you need, wherever you are. Start here. http://www.windowslive.com/default.html?ocid=TXT_TAGLM_WL_Home_082008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080802/bee9ba95/attachment.htm From robin.cornelius at gmail.com Sat Aug 2 15:47:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 2 15:38:59 2008 Subject: [sldev] CMake build fails in windows VC2003 llkdu.dll missing In-Reply-To: References: Message-ID: <4894E40E.5030907@gmail.com> Dazz Anvil wrote: > > A search of the directories under "c:\secondlife" reveals that the > file llkdu.dll is not present. > > The asset_urls.txt file is asking for: > http://secondlife.com/developers/opensource/downloads/2008/07/slviewer-win32-libs-release-r93138.zip. > I'm assuming this is the zip file that is supposed to contain the > precompiled libraries. There are, however, only a few fonts in that > zip file. This particular zip file is only 96KBytes long compared to > slviewer-win32-libs-Branch_1-20-Viewer-2-r92456.zip, available from > the wiki source download page, which does contain llkdu.dll and is > 53MBytes long. No the libs tarball no longer contains all the libs (not for source code building anyway), they are automatically downloaded at the start of the cmake process. It does look indeed like the llkdu is not in the current download list, i ment to mention this but forgot. > > Should I attempt to build with the libraries from the RC viewer, or is > there another set of libraries I should be getting from SVN? Any ideas? > You could steal llkdu.dll from the RC or remove llkdu.dll from the copy_win_libs file (thats what i did). Robin From robin.cornelius at gmail.com Sat Aug 2 15:48:00 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 2 15:39:18 2008 Subject: [sldev] CMake build fails in windows VC2003 llkdu.dll missing In-Reply-To: References: Message-ID: <4894E420.8090901@gmail.com> Dazz Anvil wrote: > > A search of the directories under "c:\secondlife" reveals that the > file llkdu.dll is not present. > > The asset_urls.txt file is asking for: > http://secondlife.com/developers/opensource/downloads/2008/07/slviewer-win32-libs-release-r93138.zip. > I'm assuming this is the zip file that is supposed to contain the > precompiled libraries. There are, however, only a few fonts in that > zip file. This particular zip file is only 96KBytes long compared to > slviewer-win32-libs-Branch_1-20-Viewer-2-r92456.zip, available from > the wiki source download page, which does contain llkdu.dll and is > 53MBytes long. No the libs tarball no longer contains all the libs (not for source code building anyway), they are automatically downloaded at the start of the cmake process. It does look indeed like the llkdu is not in the current download list, i ment to mention this but forgot. > > Should I attempt to build with the libraries from the RC viewer, or is > there another set of libraries I should be getting from SVN? Any ideas? > You could steal llkdu.dll from the RC or remove llkdu.dll from the copy_win_libs file (thats what i did). Robin From suzhanna.rossini at balsaestates.com Sun Aug 3 01:06:41 2008 From: suzhanna.rossini at balsaestates.com (Suzhanna Rossini) Date: Sun Aug 3 01:06:54 2008 Subject: SV: [sldev] CMake build fails in windows VC2003 llkdu.dll missing In-Reply-To: References: Message-ID: <018501c8f53f$de06ee00$9a14ca00$@rossini@balsaestates.com> Following the instructions outlined at http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake?the build process with Visual Studio 2003 fails during the following step: ? ------ Build started: Project: copy_win_libs, Configuration: RelWithDebInfo Win32 ------ Copying llkdu.dll C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo Error copying file (if different) from "C:/secondlife/release/indra/../libraries/i686-win32/lib/release/llkdu.dll" to "C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo/llkdu.dll". Project : error PRJ0019: A tool returned an error code from "Copying llkdu.dll C:/secondlife/release/indra/build-vc71/newview/RelWithDebInfo" � Build log was saved at "file://c:\secondlife\release\indra\build-vc71\newview\copy_win_libs.dir\Rel WithDebInfo\BuildLog.htm"� copy_win_libs - 1 error(s), 0 warning(s)� ? A search of the directories under "c:\secondlife" reveals that the file llkdu.dll is not present. ? The asset_urls.txt file is asking for: http://secondlife.com/developers/opensource/downloads/2008/07/slviewer-win32 -libs-release-r93138.zip. I'm assuming this is the zip file that is supposed to contain the precompiled libraries. There are, however, only a few fonts in that zip file. This particular zip file is only 96KBytes long compared to slviewer-win32-libs-Branch_1-20-Viewer-2-r92456.zip, available from the wiki source download page, which does contain llkdu.dll and is 53MBytes long. ? Should I attempt to build with the libraries from the RC viewer, or is there another set of libraries I should be getting from SVN? Any ideas? ? Thanks, Dazz ________________________________________ According to Soft Linden, llkdu.dll is not needed and can be removed from the lib copy ruleset, that's what I did and the build runs just fine. Alexandra. From robin.cornelius at gmail.com Sun Aug 3 01:15:53 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Aug 3 01:16:00 2008 Subject: SV: [sldev] CMake build fails in windows VC2003 llkdu.dll missing In-Reply-To: <018501c8f53f$de06ee00$9a14ca00$@rossini@balsaestates.com> References: <018501c8f53f$de06ee00$9a14ca00$@rossini@balsaestates.com> Message-ID: <48956939.1030900@gmail.com> Suzhanna Rossini wrote: > Following the instructions outlined at > http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake the build > process with Visual Studio 2003 fails during the following step: > According to Soft Linden, llkdu.dll is not needed and can be removed from > the lib copy ruleset, that's what I did and the build runs just fine. > I've added this to the note at the bottom of the page in the problems section. So that could cover all the bases now for a windows build. I'm still struggling with my linux builds and still having link errors w.r.t libgl.so and llrender and newview. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080803/740e6d4f/signature-0001.pgp From secret.argent at gmail.com Sun Aug 3 09:37:19 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 3 09:36:51 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: <4894BD4B.3000509@gmail.com> References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> <48941293.1050906@gmail.com> <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> <4894BD4B.3000509@gmail.com> Message-ID: On 2008-08-02, at 15:02, Robin Cornelius wrote: > Yes, you can unlink specific prims from a 200 link set leaving the > rest linked. Then it would be trivial to relink selecting the > linkset first and the prims to go at the head 2nd. You can using > edit linked parts select all prims to unlink and do this in one > operation, its not possible to keep the selection on all (just) the > newley unlinked prims Sure it is. Shift-click the still-linked portion of the object and it will be deselected, leaving only the newly-unlinked prims left. :) From secret.argent at gmail.com Sun Aug 3 09:40:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 3 09:40:22 2008 Subject: [sldev] Inventory user interface needs improvement (Re: Physical Object Prim Limitation) In-Reply-To: References: <16309a040808011109k3e876a4eg796dcc350cd439e3@mail.gmail.com> <48941293.1050906@gmail.com> <4D25346A-E20D-44A3-9A9D-2DF11E25FB52@gmail.com> Message-ID: <8FD17F8B-4B8D-4850-AA17-D08F692F9FE5@gmail.com> On 2008-08-02, at 16:01, Dale Mahalko wrote: > You're making an assumption that the person The person who is building a vehicle, presumably capable of scripting and assembling the vehicle to begin with. > doing this manually obtuse edit process A process that they will have performed many times in the process of building the vehicle. > will: > - always have perfect dexterity manipulating this fragile > selection state The selection state is not fragile. You can deselect the whole object, sweep select it, then shift-select the still-linked part to deselect it. From seg at haxxed.com Sun Aug 3 23:50:39 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun Aug 3 23:48:28 2008 Subject: [sldev] [VWR] Heap checkers In-Reply-To: References: Message-ID: <1217832640.5425.33.camel@localhost> On Thu, 2008-07-31 at 11:55 +0100, Robin Cornelius wrote: > So the questions remain, any other good utilities that people know of, > even platform dependent ones?, as 98% of the code is common anyway so > an error caught somewhere is probably effecting more that one system. gcc has 'mudflap' these days: http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging I played with it with OpenJPEG a bit, seems to do much the same thing as valgrind, though IIRC it ran a bit faster. Still comes with a big performance hit. I managed to get slviewer to build with mudflap, but just ended up with an immense amount of bogus spew since mudflap initially didn't work right with C++. Gcc bug #19319 claims to be fixed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319 But I don't think it was in the Fedora gcc build I was using at the time. Mudflap may or may not work with C++ now, since that was ~4 months ago. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080804/9ec6594b/attachment.pgp From dmahalko at gmail.com Mon Aug 4 14:22:25 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Aug 4 14:22:28 2008 Subject: [sldev] VS2003 compile errors: missing EZ LCD, unneeded test project Message-ID: This is an FYI, not an actual problem since I know how to deal with it. It seems most of the debug builds in the RCs and the latest 1-20-15 all have a bad reference to an EZ-LCD library, and they include an enabled project called "test" that isn't needed to compile the viewer. If I allow the viewer to build "debug" with the test project enabled, it always fails because it cannot find "llphysics.lib" --- hmm, would you mind giving me the Havok physics source project files so I can compile this??? :-) ---------------------------------------------------- ------ Build started: Project: test, Configuration: Debug Win32 ------ Compiling... [. . . .] common.cpp(500) : warning C4307: '+' : integral constant overflow common.cpp(563) : warning C4307: '+' : integral constant overflow common.cpp(607) : warning C4307: '+' : integral constant overflow Generating Code... Linking... LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/FORCE' specification LINK : fatal error LNK1181: cannot open input file 'llphysics.lib' Build log was saved at "file://c:\SL_Viewer_Builds\1_20_15\linden\indra\test\Debug\BuildLog.htm" test - 1 error(s), 4 warning(s) ---------------------------------------------------- Usually I go in and disable "test" in the Build Configuration Manager and it can be skipped without a problem. Next up, I usually cannot build the viewer "out of the box", because it cannot find the file "EZ_LCD_Wrapper_d.lib": ---------------------------------------------------- Build started: Project: newview, Configuration: Debug Win32 [. . . .] Linking... LINK : fatal error LNK1104: cannot open file 'EZ_LCD_Wrapper_d.lib' ---------------------------------------------------- Doing some searching I see there is a single library with EZ_LCD in the name, and it is called "EZ_LCD_Wrapper.lib" located in C:\SL_Viewer_Builds\1_20_15\linden\libraries\i686-win32\lib_release - Copy this to have name of "EZ_LCD_Wrapper_d.lib" in same directory - Build project again: - Still fails with same error. I put another copy of this "EZ_LCD_Wrapper_d.lib" into C:\SL_Viewer_Builds\1_20_15\linden\libraries\i686-win32\lib_debug - Build again. - Build Succeeds I do not know if making this copy of the "EZ_LCD_Wrapper.lib" is really the proper fix for the problem. All I do know is that the compile completes, but if this isn't the correct way to fix the problem then it might cause me unknown viewer problems later. - Scalar Tardis / Dale Mahalko From dmahalko at gmail.com Mon Aug 4 14:40:00 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon Aug 4 14:40:04 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: <48892EEE.4080106@lindenlab.com> References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> Message-ID: I have some more Mercurial n00b questions. I'm not really sure how to be creating the repository. I am using the entire \indra\* directory path, since that is where all the *.cpp and *.h are located, but should it really include all of \linden instead? And how to deal with the compiler's data files which dump into the \indra directories? I am assuming I don't want compiler files in the repository because they are unnecessary and I won't care about changes to compiler *.obj files. Here's what I am seeing with my experimental repository config: 1. Initialize new repository using \linden\* 2. Compile the viewer in "debug" mode. 3. hg status M indra_complete\indra_complete.sln ? compilechange ? indra_complete\indra_complete.ncb ? indra_complete\indra_complete.suo ? lib\python\indra\__init__.pyc ? lib\python\indra\ipc\__init__.pyc ? lib\python\indra\ipc\compatibility.pyc ? lib\python\indra\ipc\llmessage.pyc ? lib\python\indra\ipc\tokenstream.pyc ? lib_debug\i686-win32\llaudio.lib ? lib_debug\i686-win32\llcharacter.lib ? lib_debug\i686-win32\llcommon.lib ? lib_debug\i686-win32\llimage.lib ? lib_debug\i686-win32\llimagej2coj.lib ? lib_debug\i686-win32\llinventory.lib ? lib_debug\i686-win32\llmath.lib [. . . .] newview\debugview.pdb ? newview\libeay32.dll ? newview\ortp.dll ? newview\srtp.dll ? newview\ssleay32.dll ? newview\tntk.dll ? newview\vivoxsdk.dll ? newview\wrap_oal.dll ? win_crash_logger\Debug\BuildLog.htm ? win_crash_logger\Debug\StdAfx.obj ? win_crash_logger\Debug\llcrashlogger.obj ? win_crash_logger\Debug\llcrashloggerwindows.obj ? win_crash_logger\Debug\vc70.idb ? win_crash_logger\Debug\vc70.pdb ? win_crash_logger\Debug\win_crash_logger.obj ? win_crash_logger\Debug\win_crash_logger.pdb ? win_crash_logger\Debug\win_crash_logger.res ? win_crash_logger\win_crash_logger.exe ? win_updater\Debug\BuildLog.htm ? win_updater\Debug\updater.obj ? win_updater\Debug\vc70.idb ? win_updater\Debug\vc70.pdb ? win_updater\Debug\win_updater.pdb ? win_updater\updater.exe ? win_updater\updater.ilk After each compile, do I need to be issuing a command to Mercurial that says, "don't record changes to any of those files" ? Should I be configuring the compiler to store its temporary *.obj files, etc, somewhere else outside indra\* ? ..... or do I need to be much finer-grained about what goes into the repository, such as only including the *.cpp and *.h files rather than entire source directory trees, so it won't notice those added compiler files? - Scalar Tardis / Dale Mahalko From robin.cornelius at gmail.com Tue Aug 5 01:02:34 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Aug 5 01:02:37 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: <4891CFC1.9030305@kitware.com> References: <4891CFC1.9030305@kitware.com> Message-ID: On Thu, Jul 31, 2008 at 3:44 PM, Bill Hoffman wrote: > Robin Cornelius wrote: >> Been testing with cmake-2.6.1-RC15 but i still get a link error >> related to libGL and libGLU, the error is coming from the fact that >> ${OPENGL_LIBRARIES} is providing the linker lines -lGL and -lGLU which >> is of cause picking up my system installed libraries in /usr/lib in >> preference to any others. In fact cmake gave a warning to that effect >> that the libraries in ../i686-linux/lib-release and lib_release_client >> may not be found as default system search paths will override. > > If you give CMake a full path to the GL and GLU libraries that are not the > system libraries, then it will use those. Looks like the STANDALONE logic > is not quite right for GL. However, if you edit the CMakeCache.txt or give > a -D option and set the following cache variables to the full path to the > libraries in ../i686-linux/lib-release (with extension): > > OPENGL_gl_LIBRARY > OPENGL_glu_LIBRARY > > Then it should work. > Hi Bill sorry for the late reply but i've been fiddling with this since. It seems that the issue i am seeing is related to if the linden supplied libGL.a is present in the linden library dirs. My testing indicated that in a clean chroot with no mesa libs etc i could not link with out errors relating to gl functions being already defined. Having the mesa libs present is /usr/lib/ did not solve the issue until i also deleted the libGL.a from the linden library dirs. In fairness cmake warned me that there was a library name conflict and that two conflicting libraries existed in two search locations but it then looks like ld chokes on the results and i can't see why this bit is cmakes fault in anyway. I have hit an additional 2.6.1 issue post linking (now i can get that far). The package commands for linux are not running on 2.6.1, things package up correctly on cmake 2.4. It seems that the targets that are set as custom commands in newview/CMakeList.txt ar not making it to the actual makefile so there is no secondlife-stripped rule no secondlife-bin-globalsym rule and no SecondLife-1.20.15.tar.bz rule :- make[2]: *** No rule to make target `../newview/SecondLife-x86_64-1.20.15.0.tar.bz2', needed by `newview/CMakeFiles/package. The same issue hits me on i386 or amd64 and it does not matter if i use standalone or normal build. So its something to do with the way the custom commands are added to produce make targets. The unix install targets do seem to be working, although there may be some small issues, i need to do further testing on this bit. Regards Robin From tofu.linden at lindenlab.com Tue Aug 5 01:36:08 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Aug 5 01:36:12 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: References: <4891CFC1.9030305@kitware.com> Message-ID: <489810F8.8060408@lindenlab.com> Robin Cornelius wrote: > It seems that the issue i am seeing is related to if the linden > supplied libGL.a is present in the linden library dirs. We're supplying a libGL.a? I can't really imagine why - this seems like a mistake. From robin.cornelius at gmail.com Tue Aug 5 01:45:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Aug 5 01:45:24 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: <489810F8.8060408@lindenlab.com> References: <4891CFC1.9030305@kitware.com> <489810F8.8060408@lindenlab.com> Message-ID: On Tue, Aug 5, 2008 at 9:36 AM, Tofu Linden wrote: > Robin Cornelius wrote: >> It seems that the issue i am seeing is related to if the linden >> supplied libGL.a is present in the linden library dirs. > > We're supplying a libGL.a? I can't really imagine why - this > seems like a mistake. from install install.xml is :- http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/GL-linux-20080613.tar.bz2 libGL.a is present in release and debug Is it there from headless builds or something ? but yea it probably should not be supplied. Robin From bill.hoffman at kitware.com Tue Aug 5 07:03:23 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Aug 5 07:04:27 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: References: <4891CFC1.9030305@kitware.com> Message-ID: <48985DAB.3020803@kitware.com> Robin Cornelius wrote: > On Thu, Jul 31, 2008 at 3:44 PM, Bill Hoffman wrote: >> Robin Cornelius wrote: > >>> Been testing with cmake-2.6.1-RC15 but i still get a link error >>> related to libGL and libGLU, the error is coming from the fact that >>> ${OPENGL_LIBRARIES} is providing the linker lines -lGL and -lGLU which >>> is of cause picking up my system installed libraries in /usr/lib in >>> preference to any others. In fact cmake gave a warning to that effect >>> that the libraries in ../i686-linux/lib-release and lib_release_client >>> may not be found as default system search paths will override. >> If you give CMake a full path to the GL and GLU libraries that are not the >> system libraries, then it will use those. Looks like the STANDALONE logic >> is not quite right for GL. However, if you edit the CMakeCache.txt or give >> a -D option and set the following cache variables to the full path to the >> libraries in ../i686-linux/lib-release (with extension): >> >> OPENGL_gl_LIBRARY >> OPENGL_glu_LIBRARY >> >> Then it should work. >> > > Hi Bill sorry for the late reply but i've been fiddling with this since. > > It seems that the issue i am seeing is related to if the linden > supplied libGL.a is present in the linden library dirs. My testing > indicated that in a clean chroot with no mesa libs etc i could not > link with out errors relating to gl functions being already defined. > Having the mesa libs present is /usr/lib/ did not solve the issue > until i also deleted the libGL.a from the linden library dirs. > > In fairness cmake warned me that there was a library name conflict and > that two conflicting libraries existed in two search locations but it > then looks like ld chokes on the results and i can't see why this bit > is cmakes fault in anyway. > If you put the mesa libs in any directory other than /usr/lib, it would work. With /usr/lib CMake does not use full path libraries. This is because some linkers play tricks with this directory. So, it should work if you put mesa in some other directory. > > I have hit an additional 2.6.1 issue post linking (now i can get that > far). The package commands for linux are not running on 2.6.1, things > package up correctly on cmake 2.4. It seems that the targets that are > set as custom commands in newview/CMakeList.txt ar not making it to > the actual makefile so there is no secondlife-stripped rule no > secondlife-bin-globalsym rule and no SecondLife-1.20.15.tar.bz rule :- > > make[2]: *** No rule to make target > `../newview/SecondLife-x86_64-1.20.15.0.tar.bz2', needed by > `newview/CMakeFiles/package. > > The same issue hits me on i386 or amd64 and it does not matter if i > use standalone or normal build. So its something to do with the way > the custom commands are added to produce make targets. > Bummer on this one.... Looks like a cmake 2.6.1 bug... If you change the code to this: OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2 ... add_custom_target(package ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2) It will work. However, cmake should have done the right thing. I will work on a fix. > The unix install targets do seem to be working, although there may be > some small issues, i need to do further testing on this bit. -Bill From rdw at lindenlab.com Tue Aug 5 10:47:08 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Aug 5 10:47:11 2008 Subject: [sldev] Setting up source version control, for beginners? In-Reply-To: References: <48892C5E.5000601@gmail.com> <48892EEE.4080106@lindenlab.com> Message-ID: <4898921C.8000500@lindenlab.com> Dale Mahalko wrote: > I have some more Mercurial n00b questions. > > I'm not really sure how to be creating the repository. I am using the > entire \indra\* directory path, since that is where all the *.cpp and > *.h are located, but should it really include all of \linden instead? > > And how to deal with the compiler's data files which dump into the > \indra directories? I am assuming I don't want compiler files in the > repository because they are unnecessary and I won't care about changes > to compiler *.obj files. Here's what I am seeing with my experimental > repository config: > > 1. Initialize new repository using \linden\* > 2. Compile the viewer in "debug" mode. > 3. hg status > > M indra_complete\indra_complete.sln > ? compilechange > ? indra_complete\indra_complete.ncb > ? indra_complete\indra_complete.suo > ? lib\python\indra\__init__.pyc > ? lib\python\indra\ipc\__init__.pyc > ? lib\python\indra\ipc\compatibility.pyc > ? lib\python\indra\ipc\llmessage.pyc > ? lib\python\indra\ipc\tokenstream.pyc > ? lib_debug\i686-win32\llaudio.lib > ? lib_debug\i686-win32\llcharacter.lib > ? lib_debug\i686-win32\llcommon.lib > ? lib_debug\i686-win32\llimage.lib > ? lib_debug\i686-win32\llimagej2coj.lib > ? lib_debug\i686-win32\llinventory.lib > ? lib_debug\i686-win32\llmath.lib > [. . . .] > newview\debugview.pdb > ? newview\libeay32.dll > ? newview\ortp.dll > ? newview\srtp.dll > ? newview\ssleay32.dll > ? newview\tntk.dll > ? newview\vivoxsdk.dll > ? newview\wrap_oal.dll > ? win_crash_logger\Debug\BuildLog.htm > ? win_crash_logger\Debug\StdAfx.obj > ? win_crash_logger\Debug\llcrashlogger.obj > ? win_crash_logger\Debug\llcrashloggerwindows.obj > ? win_crash_logger\Debug\vc70.idb > ? win_crash_logger\Debug\vc70.pdb > ? win_crash_logger\Debug\win_crash_logger.obj > ? win_crash_logger\Debug\win_crash_logger.pdb > ? win_crash_logger\Debug\win_crash_logger.res > ? win_crash_logger\win_crash_logger.exe > ? win_updater\Debug\BuildLog.htm > ? win_updater\Debug\updater.obj > ? win_updater\Debug\vc70.idb > ? win_updater\Debug\vc70.pdb > ? win_updater\Debug\win_updater.pdb > ? win_updater\updater.exe > ? win_updater\updater.ilk > > > After each compile, do I need to be issuing a command to Mercurial > that says, "don't record changes to any of those files" ? > > Should I be configuring the compiler to store its temporary *.obj > files, etc, somewhere else outside indra\* ? > > ..... or do I need to be much finer-grained about what goes into the > repository, such as only including the *.cpp and *.h files rather than > entire source directory trees, so it won't notice those added compiler > files? > > The .hgignore file will help you here: http://www.selenic.com/mercurial/hgignore.5.html I believe you will want to also un-add any files that are purely build artifacts (the .sln is one of those since it's generated by cmake). -RYaN From dmahalko at gmail.com Wed Aug 6 07:29:36 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Aug 6 07:29:39 2008 Subject: [sldev] mystery compiler output (Re: setting up version control) Message-ID: On Tue, Aug 5, 2008 at 12:47 PM, Ryan Williams (Which) wrote: > > The .hgignore file will help you here: > > http://www.selenic.com/mercurial/hgignore.5.html > > I believe you will want to also un-add any files that are purely build > artifacts (the .sln is one of those since it's generated by cmake). Okay, .hgignore created: --------------------------------------- # use glob syntax. syntax: glob # Ignore compiler project/solution files *.vcproj *.sln # Ignore Visual Studio 2003 compiler temporary files *.ilk *.res *.pyn *.pyc *.ncb *.suo *.pch *.obj *.pdb *.idb *.lib BuildLog.* # Ignore compiled binaries *.dll *.exe # Ignore this ignore file .hgignore --------------------------------------- This leaves six files which did not exist when the repository was created, before the debug compile: --------------------------------------- C:\SL_Viewer_Builds\1_20_15\linden\indra>hg status ? lscript\lscript_compile\lex_yy.cpp ? lscript\lscript_compile\ytab.cpp ? lscript\lscript_compile\ytab.h ? lscript\lscript_compile\ytab.output ? newview\app_settings\message.xml ? newview\app_settings\message_template.msg --------------------------------------- I assume these files are compiled output, and that I should be adding this list to the .hgignore file. But if so, where did the lex_yy.cpp / ytab.* come from? Also the new XML preferences system is not yet well-documented on the wiki. I presume that this is the original that can be safely edited: - \linden\etc\message.xml And this is compiler output which get overwritten with each new compile and so should not ever be touched: - \linden\indra\newview\app_settings\message.xml Likewise for the protocol template, this is the original: - \linden\scripts\messages\message_template.msg And this is compiler output: - \linden\indra\newview\app_settings\message_template.msg - Scalar Tardis / Dale Mahalko From nik at terminaldischarge.net Wed Aug 6 07:57:47 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Wed Aug 6 07:57:48 2008 Subject: [sldev] mystery compiler output (Re: setting up version control) In-Reply-To: References: Message-ID: <64193.213.106.235.26.1218034667.squirrel@webmail.terminaldischarge.net> > But if so, where did the lex_yy.cpp / ytab.* come from? Generated by LEX and possibly YACC, which are programs for creating lexical anaylisis and compilers for source code. I assume these are generated as part of the build process. From olli_aro at yahoo.co.uk Wed Aug 6 08:03:30 2008 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Wed Aug 6 08:03:31 2008 Subject: [sldev] SVN or CVS for the source code Message-ID: Hi all, Is there somewhere SVN or CSV repository for Second Life viewer source code? I have been looking everywhere but cannot seem to find it. Thanks, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080806/74decbc6/attachment.htm From tom at streamsense.net Wed Aug 6 08:04:32 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Aug 6 08:04:38 2008 Subject: [sldev] SVN or CVS for the source code In-Reply-To: References: Message-ID: <4899BD80.9020508@streamsense.net> Check under: http://svn.secondlife.com/trac/linden/browser/branches/ Tom. Olli Aro wrote: > Hi all, > > > > Is there somewhere SVN or CSV repository for Second Life viewer source code? > I have been looking everywhere but cannot seem to find it. > > > > Thanks, > > > > Olli > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From nyx at lindenlab.com Wed Aug 6 08:13:31 2008 From: nyx at lindenlab.com (Neal) Date: Wed Aug 6 08:13:32 2008 Subject: [sldev] SVN or CVS for the source code In-Reply-To: References: Message-ID: <4899BF9B.9000301@lindenlab.com> Greetings Olli, We use SVN for our source code repositories. You can find the locations of the different repositories (release, maintenance, etc) detailed on this wiki page: http://wiki.secondlife.com/wiki/Version_control_repository . Feel free to let us know if you have difficulty accessing or building the code. Thanks! -Nyx Olli Aro wrote: > > Hi all, > > > > Is there somewhere SVN or CSV repository for Second Life viewer source > code? I have been looking everywhere but cannot seem to find it. > > > > Thanks, > > > > Olli > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From olli_aro at yahoo.co.uk Wed Aug 6 08:23:49 2008 From: olli_aro at yahoo.co.uk (Olli Aro) Date: Wed Aug 6 08:23:51 2008 Subject: [sldev] SVN or CVS for the source code In-Reply-To: <4899BF9B.9000301@lindenlab.com> Message-ID: Thanks Neal and Thomas for such a quick response!! I did browse the Wiki, but somehow managed to miss that article. Sorry for such a trivial posting on this list. Regards, Olli -----Original Message----- From: Neal [mailto:nyx@lindenlab.com] Sent: 06 August 2008 16:14 To: olli_aro@yahoo.co.uk Cc: 'SL-Dev' Subject: Re: [sldev] SVN or CVS for the source code Greetings Olli, We use SVN for our source code repositories. You can find the locations of the different repositories (release, maintenance, etc) detailed on this wiki page: http://wiki.secondlife.com/wiki/Version_control_repository . Feel free to let us know if you have difficulty accessing or building the code. Thanks! -Nyx Olli Aro wrote: > > Hi all, > > > > Is there somewhere SVN or CSV repository for Second Life viewer source > code? I have been looking everywhere but cannot seem to find it. > > > > Thanks, > > > > Olli > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From robin.cornelius at gmail.com Wed Aug 6 08:31:19 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Aug 6 08:31:23 2008 Subject: [sldev] SVN or CVS for the source code In-Reply-To: References: <4899BF9B.9000301@lindenlab.com> Message-ID: On Wed, Aug 6, 2008 at 4:23 PM, Olli Aro wrote: > Thanks Neal and Thomas for such a quick response!! > > I did browse the Wiki, but somehow managed to miss that article. > > Sorry for such a trivial posting on this list. > if your new to the code watch the branching and also the change in build system. The 1.20.X branches are based on the SCons build system (or a direct project for Visual studio/XCode) The newer release branches and friends are based on cmake which the build documentation is not official for yet. So the get the source and compile pages will talk about mostly the older build system with possibly a mix of the newer, not ideal but its a transitional period and this list can help you muddle through ;-) Robin From robla at lindenlab.com Wed Aug 6 11:39:41 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Aug 6 11:39:47 2008 Subject: [sldev] JIRA tweaks Message-ID: <4899EFED.8040202@lindenlab.com> Hi all, There's a number of tweaks that Sue Linden is planning to make to jira.secondlife.com, documented here: http://jira.secondlife.com/browse/WEB-753 In particular, she's planning on moving the "Inventory", "Missing Content" and "Permissions" components from VWR to SVC project. Please direct any comments to WEB-753. Thanks! Rob From rdw at lindenlab.com Wed Aug 6 11:44:16 2008 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Aug 6 11:44:18 2008 Subject: [sldev] mystery compiler output (Re: setting up version control) In-Reply-To: References: Message-ID: <4899F100.9090108@lindenlab.com> Dale Mahalko wrote: > Also the new XML preferences system is not yet well-documented on the wiki. > > I presume that this is the original that can be safely edited: > - \linden\etc\message.xml > > And this is compiler output which get overwritten with each new > compile and so should not ever be touched: > - \linden\indra\newview\app_settings\message.xml > > > Likewise for the protocol template, this is the original: > - \linden\scripts\messages\message_template.msg > > And this is compiler output: > - \linden\indra\newview\app_settings\message_template.msg > > Yes to both of these. -RYaN From soft at lindenlab.com Wed Aug 6 13:51:35 2008 From: soft at lindenlab.com (Soft) Date: Wed Aug 6 13:51:38 2008 Subject: [sldev] release/ to be renamed trunk/ Message-ID: I just sent one of my quarterly gripes to an internal list about the abiguity of our "release/" branch name. It occurs to me that I don't need to keep the name the same internally and externally, however. So: ** This is a heads up that the branch will change names with the Friday source drop. If you do an svn update on your release/ branch and it fails, simply do an svn relocate with the old and new full URLs. Help in placing all the wiki changes would be very much appreciated. From blindwanderer at gmail.com Wed Aug 6 14:33:30 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Wed Aug 6 14:33:34 2008 Subject: [sldev] release/ to be renamed trunk/ In-Reply-To: References: Message-ID: <89ca6da00808061433v7f4482e0w28c21f45ff2a3ea1@mail.gmail.com> This sounds like a good thing. In the LSL documentation there is a History section and I have been putting links to the applicable SVN changes and tagging things with the branch name... which looks weird with the "Release branch" when there isn't a corresponding release. The "Trunk" rename will clear that up nicely. On Wed, Aug 6, 2008 at 3:51 PM, Soft wrote: > I just sent one of my quarterly gripes to an internal list about the > abiguity of our "release/" branch name. It occurs to me that I don't > need to keep the name the same internally and externally, however. So: > > ** This is a heads up that the branch will change names with the > Friday source drop. > > If you do an svn update on your release/ branch and it fails, simply > do an svn relocate with the old and new full URLs. Help in placing all > the wiki changes would be very much appreciated. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080806/b29ae976/attachment.htm From robin.cornelius at gmail.com Thu Aug 7 05:51:08 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 7 05:51:13 2008 Subject: [sldev] Fwd: Open source meeting - Thursday, 2pm PT, call for items In-Reply-To: References: Message-ID: Hi everyone, The usual Thursday routine, Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Please if you have got anything add it, i'm up to my neck in my paid work so i don't have very much so currently the adjenda is bare ;-( See you in Hippotropolis later. Robin From bill.hoffman at kitware.com Thu Aug 7 09:29:54 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu Aug 7 09:30:13 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: <48985DAB.3020803@kitware.com> References: <4891CFC1.9030305@kitware.com> <48985DAB.3020803@kitware.com> Message-ID: <489B2302.3000009@kitware.com> Bill Hoffman wrote: > Bummer on this one.... Looks like a cmake 2.6.1 bug... > > If you change the code to this: > OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2 > ... > add_custom_target(package ALL DEPENDS > ${CMAKE_CURRENT_BINARY_DIR}/${product}.tar.bz2) > > It will work. However, cmake should have done the right thing. I will > work on a fix. > >> The unix install targets do seem to be working, although there may be >> some small issues, i need to do further testing on this bit. > OK, I have a new version for you to try: http://www.cmake.org/files/v2.6/cmake-2.6.2-RC-1-Linux-i386.tar.gz Should fix the problem. -Bill From carjay at gmx.net Thu Aug 7 13:00:28 2008 From: carjay at gmx.net (Carsten Juttner) Date: Thu Aug 7 13:00:40 2008 Subject: [sldev] [VWR] cmake issues with libGL and friends In-Reply-To: <489B2302.3000009@kitware.com> References: <4891CFC1.9030305@kitware.com> <48985DAB.3020803@kitware.com> <489B2302.3000009@kitware.com> Message-ID: <489B545C.8050500@gmx.net> Bill Hoffman wrote: > OK, I have a new version for you to try: > > http://www.cmake.org/files/v2.6/cmake-2.6.2-RC-1-Linux-i386.tar.gz > > Should fix the problem. Hi Bill, 2.6.2RC1 works for me. I still have a missing "client-readme-voice.txt" but this also misses on cmake 2.4.8 so it's an issue when building STANDALONE and not related to cmake. If I touch that file "make" runs through to the end. Thanks! Carsten From richardm at norco.com Fri Aug 8 08:10:25 2008 From: richardm at norco.com (RIchard Moss) Date: Fri Aug 8 08:08:53 2008 Subject: [sldev] clarity Message-ID: <489C61E1.8010900@norco.com> good morning. I'm new to your list, but not new to Linux, hope I can help. couple quick ones.. 1. does anyone have the "compile the viewer from source" wiki project under hand ? I'd like to help there in anyway I can. 2. best people to discuss sse with, or in anyone working on this ? thank you From robin.cornelius at gmail.com Fri Aug 8 11:10:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 8 11:10:27 2008 Subject: [sldev] clarity In-Reply-To: <489C61E1.8010900@norco.com> References: <489C61E1.8010900@norco.com> Message-ID: <489C8C0D.8030706@gmail.com> RIchard Moss wrote: > good morning. > 1. does anyone have the "compile the viewer from source" wiki > project under hand ? I'd like to help there in anyway I can. I would point you towards :- https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake thats about the best build instructions *IMHO* (no self interest at all!) for the new style of building the viewer. Its not really worth devoting much time to the old pages. Not sure how long you have been lurking on the list but check the archives there was a discussion about possible ways forward once the cmake branch goes live on a release candidate. Actually that was pretty recently. Also things were mentioned at last nights open source (Rob's Hours) Transcript at :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/2008-08-07 In particular robs page :- https://wiki.secondlife.com/wiki/User:Rob_Linden/Build_Tool_Improvement_Spec_-_2008 ... Heh, lots done since yesterday ;-) Rob is trying to streamline the instructions into more offical notes via his page above. > > 2. best people to discuss sse with, or in anyone working on this ? > Rob Lanphier (Rob Linden) is the chief herder of the open source effort from the Labs side of the fence (but there are quite a few others involved too), and there are quite a few lurkers on this list involved with both the testing and debugging of the new build system from out side linden labs and quite a few lindens who are involved with the creation and implementation from the inside. Also various lurkers on EFNet #opensl Probably best communicate through this list and also attend Rob's Hours Thursday 2pm SL TIme if you can. Where many of the "open source" lindens also attend. Regards Robin Michelle2 Zenovka -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080808/45b4b61f/signature.pgp From shornik at yahoo.com Fri Aug 8 12:14:38 2008 From: shornik at yahoo.com (Steven Hornik) Date: Fri Aug 8 12:14:41 2008 Subject: [sldev] Scalable Sim Question Message-ID: <851890.86488.qm@web53801.mail.re2.yahoo.com> I want to preface that I'm not a developer but lurk on this list to see what's happening. I'm sure this isn't the best place to post this question but thought some here might be able to provide an answer or at least a pointer in the right direction. Here is the dilemma: finite limit to how many avatars can be on one sim. Solution (well I don't know if this can be done and that's why I'm asking here): Mirrored sims, a bit of explanation, please ignore my use of incorrect terminology. Let's say I have an island with objects, scripts etc. That sim can "hold" roughly 60 AV's, what if I had 500 AV's that needed to access that sim. What is to prevent SL from using a mirror image of one server that holds my island/objects/scripts and scaling it (as needed) depending on how many av's were trying to access that one location. So I might be on the sim and interacting with 59 other AV's. When someone else tries to access the sim, instead of a sim full message they would be sent to a mirrored sim - objects/scripts would be the same and you would be with a different set of 59 AV's, and so on. Is this pie-in-the-sky? Thanks, Steven ________________________ Dr. Steven Hornik University of Central Florida Dixon School of Accounting 407-823-5739 Second Life: Robins Hermano http://mydebitcredit.com yahoo ID: shornik twitter: shornik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080808/9824e624/attachment.htm From kaleajinkya at gmail.com Fri Aug 8 12:23:38 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Aug 8 12:23:41 2008 Subject: [sldev] [HELP]Compilation error Message-ID: This is the error messages i get after a build in VC2005 1>------ Build started: Project: test, Configuration: ReleaseNoOpt Win32 ------ 1>Compiling... 1>xform_tut.cpp 1>v4math_tut.cpp 1>v4coloru_tut.cpp 1>v4color_tut.cpp 1>v3math_tut.cpp 1>v3dmath_tut.cpp 1>.\v3dmath_tut.cpp(223) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(223) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(231) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(231) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(236) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(236) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(241) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(241) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(248) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(248) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(253) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(253) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(258) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(258) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(264) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(264) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(269) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(269) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(274) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(274) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(291) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(291) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(292) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(292) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(293) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(293) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(307) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(307) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(312) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(312) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(317) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(317) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(327) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(327) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(332) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(332) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(337) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(337) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(343) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(343) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(348) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(348) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(353) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(353) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(426) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(426) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(431) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(431) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(436) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(436) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(445) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(445) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(450) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(450) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(455) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>.\v3dmath_tut.cpp(455) : warning C4244: 'argument' : conversion from 'F64' to 'F32', possible loss of data 1>v3color_tut.cpp 1>v2math_tut.cpp 1>test.cpp 1>reflection_tut.cpp 1>math.cpp 1>lluuidhashmap_tut.cpp 1>lluserrelations_tut.cpp 1>lluri_tut.cpp 1>lltut.cpp 1>lltiming_tut.cpp 1>lltemplatemessagebuilder_tut.cpp 1>llstreamtools_tut.cpp 1>llservicebuilder_tut.cpp 1>llsdutil_tut.cpp 1>Generating Code... 1>Compiling... 1>llsdserialize_tut.cpp 1>llsdmessagereader_tut.cpp 1>llsdmessagebuilder_tut.cpp 1>llsd_new_tut.cpp 1>llsaleinfo_tut.cpp 1>llrandom_tut.cpp 1>llquaternion_tut.cpp 1>llpipeutil.cpp 1>llpermissions_tut.cpp 1>llnamevalue_tut.cpp 1>llmime_tut.cpp 1>lljoint_tut.cpp 1>llhttpclient_tut.cpp 1>llhost_tut.cpp 1>llerror_tut.cpp 1>lldate_tut.cpp 1>llbuffer_tut.cpp 1>llbase64_tut.cpp 1>llapp_tut.cpp 1>io.cpp 1>.\io.cpp(1151) : warning C4305: 'argument' : truncation from 'double' to 'F32' 1>Generating Code... 1>Compiling... 1>inventory.cpp 1>.\inventory.cpp(61) : warning C4244: 'initializing' : conversion from 'time_t' to 'S32', possible loss of data 1>.\inventory.cpp(193) : warning C4244: 'initializing' : conversion from 'time_t' to 'S32', possible loss of data 1>.\inventory.cpp(264) : warning C4244: 'initializing' : conversion from 'time_t' to 'S32', possible loss of data 1>common.cpp 1>.\common.cpp(491) : warning C4307: '+' : integral constant overflow 1>.\common.cpp(554) : warning C4307: '+' : integral constant overflow 1>.\common.cpp(598) : warning C4307: '+' : integral constant overflow 1>Generating Code... 1>Compiling manifest to resources... 1>Linking... 1>io.obj : error LNK2019: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::beginSegment(void)" (?beginSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@XZ) referenced in function "public: void __thiscall tut::test_object::test<1>(void)" (??$test@$00@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::beginSegment(void)" (?beginSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@XZ) 1>io.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLBufferArray::eraseSegment(class std::list >::_Iterator<1> const &)" (?eraseSegment@LLBufferArray@@QAE_NABV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@@Z) referenced in function "public: void __thiscall tut::test_object::test<9>(void)" (??$test@$08@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: bool __thiscall LLBufferArray::eraseSegment(class std::list >::_Iterator<1> const &)" (?eraseSegment@LLBufferArray@@QAE_NABV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@@Z) 1>io.obj : error LNK2019: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::endSegment(void)" (?endSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@XZ) referenced in function "public: void __thiscall tut::test_object::test<9>(void)" (??$test@$08@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::endSegment(void)" (?endSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@XZ) 1>io.obj : error LNK2019: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::splitAfter(unsigned char *)" (?splitAfter@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@PAE@Z) referenced in function "public: void __thiscall tut::test_object::test<4>(void)" (??$test@$03@ ?$test_object@Ubuffer_and_stream_data@tut@@@tut@@QAEXXZ) 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::splitAfter(unsigned char *)" (?splitAfter@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@PAE@Z) 1>llbuffer_tut.obj : error LNK2019: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::makeSegment(int,int)" (?makeSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment @@V?$allocator@VLLSegment@@@std@@@std@@HH@Z) referenced in function "public: void __thiscall tut::test_object::test<12>(void)" (??$test@$0M@@?$test_object@Ubuffer@tut@@@tut@@QAEXXZ) 1>llbuffer_tut.obj : error LNK2019: unresolved external symbol "public: class std::list >::_Iterator<1> __thiscall LLBufferArray::constructSegmentAfter(unsigned char *,class LLSegment &)" (?constructSegmentAfter@LLBufferArray @@QAE?AV?$_Iterator@$00@?$list@VLLSegment@@V?$allocator@VLLSegment@@@std@ @@std@@PAEAAVLLSegment@@@Z) referenced in function "public: void __thiscall tut::test_object::test<13>(void)" (??$test@$0N@ @?$test_object@Ubuffer@tut@@@tut@@QAEXXZ) 1>llcommon.lib(llfile.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced in function "public: struct _Ctypevec __thiscall std::_Locinfo::_Getctype(void)const " (?_Getctype@_Locinfo@std @@QBE?AU_Ctypevec@@XZ) 1>llcommon.lib(llstring.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llsdserialize_xml.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llxml.lib(llxmlnode.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(lldate.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(lluri.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llsdutil.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llstreamtools.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llsd.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llmemorystream.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llsdserialize.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llcommon.lib(llerror.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(lldatapacker.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llinventory.lib(llinventory.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llinventory.lib(llsaleinfo.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llinventory.lib(llpermissions.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llcircuit.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llassetstorage.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llhttpclient.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llhttpsender.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llmime.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llservicebuilder.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(message.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llmessageconfig.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llpumpio.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llsdrpcclient.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llfiltersd2xmlrpc.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llsdrpcserver.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmath.lib(lluuid.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmath.lib(v4color.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmath.lib(llmd5.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>llmessage.lib(llbufferstream.obj) : error LNK2001: unresolved external symbol __invalid_parameter_noinfo 1>ReleaseNoOpt/test.exe : fatal error LNK1120: 7 unresolved externals 1>Build log was saved at "file://h:\SL Open source codes\slviewer-src-Branch_1-19-0-Viewer\linden\indra\test\ReleaseNoOpt\BuildLog.htm" 1>test - 43 error(s), 63 warning(s) ========== Build: 0 succeeded, 1 failed, 22 up-to-date, 0 skipped ========== -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080808/f85bfafa/attachment-0001.htm From richardm at norco.com Fri Aug 8 13:56:25 2008 From: richardm at norco.com (RIchard Moss) Date: Fri Aug 8 13:54:50 2008 Subject: [sldev] re: Scalable Sim Question Message-ID: <489CB2F9.9030506@norco.com> Message: 1 Date: Fri, 8 Aug 2008 12:14:38 -0700 (PDT) From: Steven Hornik Subject: [sldev] Scalable Sim Question To: sldev@lists.secondlife.com Message-ID: <851890.86488.qm@web53801.mail.re2.yahoo.com> Content-Type: text/plain; charset="us-ascii" I want to preface that I'm not a developer but lurk on this list to see what's happening. I'm sure this isn't the best place to post this question but thought some here might be able to provide an answer or at least a pointer in the right direction. Here is the dilemma: finite limit to how many avatars can be on one sim. Solution (well I don't know if this can be done and that's why I'm asking here): Mirrored sims, a bit of explanation, please ignore my use of incorrect terminology. Let's say I have an island with objects, scripts etc. That sim can "hold" roughly 60 AV's, what if I had 500 AV's that needed to access that sim. What is to prevent SL from using a mirror image of one server that holds my island/objects/scripts and scaling it (as needed) depending on how many av's were trying to access that one location. So I might be on the sim and interacting with 59 other AV's. When someone else tries to access the sim, instead of a sim full message they would be sent to a mirrored sim - objects/scripts would be the same and you would be with a different set of 59 AV's, and so on. Is this pie-in-the-sky? Thanks, Steven I'm a bit new to put thoughts forth on this, but answers will help in my explorations, I'm interested in the things that DO limit this from being plausible. I know on the base level that scrips are sim bound, and there are limits to the number of channels f.i. Are hard limit(s) of sim(s), interaction and interprocess communication defined by havok or in can these be manipulated by indra_constants (to start) From zha.ewry at gmail.com Fri Aug 8 15:58:57 2008 From: zha.ewry at gmail.com (Zha Ewry) Date: Fri Aug 8 15:58:59 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <851890.86488.qm@web53801.mail.re2.yahoo.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: <920d7d850808081558p1e4b33e5if7272e6622788f67@mail.gmail.com> This is classic sharding. Take a look at how all the MMOGs work. The problem, of course is if the 59 people you end up sitting with don't include some of the people you want to interact with. Sharding is managable in gaming, as long as all your friends share your shard. Its much less useful for a peer to peer social space, where the desire is to interact with the full set of people in the space. You can put a speaker,or a performer into a set of shared (so they share the performance) but that only helps a little bit. ~ Zha On Fri, Aug 8, 2008 at 3:14 PM, Steven Hornik wrote: > I want to preface that I'm not a developer but lurk on this list to see > what's happening. I'm sure this isn't the best place to post this question > but thought some here might be able to provide an answer or at least a > pointer in the right direction. > > Here is the dilemma: finite limit to how many avatars can be on one sim. > Solution (well I don't know if this can be done and that's why I'm asking > here): Mirrored sims, a bit of explanation, please ignore my use of > incorrect terminology. Let's say I have an island with objects, scripts > etc. That sim can "hold" roughly 60 AV's, what if I had 500 AV's that > needed to access that sim. What is to prevent SL from using a mirror image > of one server that holds my island/objects/scripts and scaling it (as > needed) depending on how many av's were trying to access that one location. > So I might be on the sim and interacting with 59 other AV's. When someone > else tries to access the sim, instead of a sim full message they would be > sent to a mirrored sim - objects/scripts would be the same and you would be > with a different set of 59 AV's, and so on. > > Is this pie-in-the-sky? > > Thanks, > Steven > > ________________________ > Dr. Steven Hornik > University of Central Florida > Dixon School of Accounting > 407-823-5739 > Second Life: Robins Hermano > http://mydebitcredit.com > yahoo ID: shornik > twitter: shornik > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robla at lindenlab.com Fri Aug 8 17:02:09 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Aug 8 17:02:21 2008 Subject: [sldev] Spec for build tool improvements In-Reply-To: <489C8C0D.8030706@gmail.com> References: <489C61E1.8010900@norco.com> <489C8C0D.8030706@gmail.com> Message-ID: <489CDE81.3040404@lindenlab.com> Hi all, Robin sorta beat me to the punch, but I should still highlight this. Here's a very rough spec for improving the current build toolchain: https://wiki.secondlife.com/wiki/User:Rob_Linden/Build_Tool_Improvement_Spec_-_2008 It hasn't gotten much vetting anywhere yet (including within Linden Lab). I'd like to come up with a list of improvements to the build process that are sensible to batch up in one pass, and build them into a development plan that we can either take on as a project within Linden Lab, or farm out if it makes sense. We really want to make the process for new developers much better, and while getting good documentation in place would also help, it seems like right now the best investment would be in making a lot of the quirks that need documentation go away. If editing or commenting on the wiki isn't your thing, then perhaps just put something in JIRA: https://jira.secondlife.com/browse/VWR-8545 Eventually, everything on the wiki page should probably be subtasks on JIRA, but it might be easier to keep it in one spec for now, and then break it up as this matures a little bit and voting/commenting on discrete tasks makes sense. Discussion on this list is also quite welcome. Thanks Rob From dahliatrimble at gmail.com Fri Aug 8 17:35:05 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Aug 8 17:35:08 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <851890.86488.qm@web53801.mail.re2.yahoo.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: Something vaguely similar to this has been demonstrated by the libopenmv team. They used bots to echo the performance of musicians in another sim so a wider audience could see the show. John Hurliman has a video of this on his blog at http://www.jhurliman.org/index.php/2006/long-range-in-second-life-or-cleverly-disguised-robots/ The SL Shakespeare Company has also conducted research along these lines. OpenSim has an experimental feature where a region that becomes highly loaded can be split into multiple smaller regions and each segment can then be processed on a seperate CPU core, but I'm not certain how complete the implementation is yet. On Fri, Aug 8, 2008 at 12:14 PM, Steven Hornik wrote: > I want to preface that I'm not a developer but lurk on this list to see > what's happening. I'm sure this isn't the best place to post this question > but thought some here might be able to provide an answer or at least a > pointer in the right direction. > > Here is the dilemma: finite limit to how many avatars can be on one sim. > Solution (well I don't know if this can be done and that's why I'm asking > here): Mirrored sims, a bit of explanation, please ignore my use of > incorrect terminology. Let's say I have an island with objects, scripts > etc. That sim can "hold" roughly 60 AV's, what if I had 500 AV's that > needed to access that sim. What is to prevent SL from using a mirror > image of one server that holds my island/objects/scripts and scaling it > (as needed) depending on how many av's were trying to access that one > location. So I might be on the sim and interacting with 59 other AV's. > When someone else tries to access the sim, instead of a sim full message > they would be sent to a mirrored sim - objects/scripts would be the same and > you would be with a different set of 59 AV's, and so on. > > Is this pie-in-the-sky? > > Thanks, > Steven > ________________________ > Dr. Steven Hornik > University of Central Florida > Dixon School of Accounting > 407-823-5739 > Second Life: Robins Hermano > http://mydebitcredit.com > yahoo ID: shornik > twitter: shornik > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080808/8fe934bc/attachment.htm From kaleajinkya at gmail.com Fri Aug 8 21:44:24 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Fri Aug 8 21:44:29 2008 Subject: [sldev] Re: [HELP]Compilation error In-Reply-To: References: Message-ID: I was not getting this error earlier. I tried building after a long time and now it is throwing this error. Can anyone help me regarding the same. Thank you , On Fri, Aug 8, 2008 at 12:23 PM, Ajinkya Kale wrote: > This is the error messages i get after a build in VC2005 > > 1>------ Build started: Project: test, Configuration: ReleaseNoOpt Win32 > ------ > 1>Compiling... > 1>xform_tut.cpp > 1>v4math_tut.cpp > 1>v4coloru_tut.cpp > 1>v4color_tut.cpp > 1>v3math_tut.cpp > 1>v3dmath_tut.cpp > 1>.\v3dmath_tut.cpp(223) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(223) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(231) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(231) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(236) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(236) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(241) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(241) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(248) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(248) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(253) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(253) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(258) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(258) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(264) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(264) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(269) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(269) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(274) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(274) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(291) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(291) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(292) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(292) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(293) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(293) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(307) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(307) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(312) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(312) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(317) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(317) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(327) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(327) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(332) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(332) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(337) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(337) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(343) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(343) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(348) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(348) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(353) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(353) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(426) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(426) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(431) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(431) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(436) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(436) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(445) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(445) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(450) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(450) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(455) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>.\v3dmath_tut.cpp(455) : warning C4244: 'argument' : conversion from > 'F64' to 'F32', possible loss of data > 1>v3color_tut.cpp > 1>v2math_tut.cpp > 1>test.cpp > 1>reflection_tut.cpp > 1>math.cpp > 1>lluuidhashmap_tut.cpp > 1>lluserrelations_tut.cpp > 1>lluri_tut.cpp > 1>lltut.cpp > 1>lltiming_tut.cpp > 1>lltemplatemessagebuilder_tut.cpp > 1>llstreamtools_tut.cpp > 1>llservicebuilder_tut.cpp > 1>llsdutil_tut.cpp > 1>Generating Code... > 1>Compiling... > 1>llsdserialize_tut.cpp > 1>llsdmessagereader_tut.cpp > 1>llsdmessagebuilder_tut.cpp > 1>llsd_new_tut.cpp > 1>llsaleinfo_tut.cpp > 1>llrandom_tut.cpp > 1>llquaternion_tut.cpp > 1>llpipeutil.cpp > 1>llpermissions_tut.cpp > 1>llnamevalue_tut.cpp > 1>llmime_tut.cpp > 1>lljoint_tut.cpp > 1>llhttpclient_tut.cpp > 1>llhost_tut.cpp > 1>llerror_tut.cpp > 1>lldate_tut.cpp > 1>llbuffer_tut.cpp > 1>llbase64_tut.cpp > 1>llapp_tut.cpp > 1>io.cpp > 1>.\io.cpp(1151) : warning C4305: 'argument' : truncation from 'double' to > 'F32' > 1>Generating Code... > 1>Compiling... > 1>inventory.cpp > 1>.\inventory.cpp(61) : warning C4244: 'initializing' : conversion from > 'time_t' to 'S32', possible loss of data > 1>.\inventory.cpp(193) : warning C4244: 'initializing' : conversion from > 'time_t' to 'S32', possible loss of data > 1>.\inventory.cpp(264) : warning C4244: 'initializing' : conversion from > 'time_t' to 'S32', possible loss of data > 1>common.cpp > 1>.\common.cpp(491) : warning C4307: '+' : integral constant overflow > 1>.\common.cpp(554) : warning C4307: '+' : integral constant overflow > 1>.\common.cpp(598) : warning C4307: '+' : integral constant overflow > 1>Generating Code... > 1>Compiling manifest to resources... > 1>Linking... > 1>io.obj : error LNK2019: unresolved external symbol "public: class > std::list > >::_Iterator<1> __thiscall LLBufferArray::beginSegment(void)" > (?beginSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@XZ) referenced in function "public: > void __thiscall tut::test_object::test<1>(void)" > (??$test@$00@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) > 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: > class std::list > >::_Iterator<1> __thiscall LLBufferArray::beginSegment(void)" > (?beginSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@XZ) > 1>io.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLBufferArray::eraseSegment(class std::list std::allocator >::_Iterator<1> const &)" > (?eraseSegment@LLBufferArray@@QAE_NABV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@@Z) referenced in function "public: > void __thiscall tut::test_object::test<9>(void)" > (??$test@$08@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) > 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: > bool __thiscall LLBufferArray::eraseSegment(class std::list LLSegment,class std::allocator >::_Iterator<1> const &)" > (?eraseSegment@LLBufferArray@@QAE_NABV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@@Z) > 1>io.obj : error LNK2019: unresolved external symbol "public: class > std::list > >::_Iterator<1> __thiscall LLBufferArray::endSegment(void)" > (?endSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@XZ) referenced in function "public: > void __thiscall tut::test_object::test<9>(void)" > (??$test@$08@?$test_object@Ubuffer_data@tut@@@tut@@QAEXXZ) > 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: > class std::list > >::_Iterator<1> __thiscall LLBufferArray::endSegment(void)" > (?endSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@XZ) > 1>io.obj : error LNK2019: unresolved external symbol "public: class > std::list > >::_Iterator<1> __thiscall LLBufferArray::splitAfter(unsigned char *)" > (?splitAfter@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@PAE@Z) referenced in function > "public: void __thiscall tut::test_object tut::buffer_and_stream_data>::test<4>(void)" (??$test@$03@ > ?$test_object@Ubuffer_and_stream_data@tut@@@tut@@QAEXXZ) > 1>llbuffer_tut.obj : error LNK2001: unresolved external symbol "public: > class std::list > >::_Iterator<1> __thiscall LLBufferArray::splitAfter(unsigned char *)" > (?splitAfter@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@PAE@Z) > 1>llbuffer_tut.obj : error LNK2019: unresolved external symbol "public: > class std::list > >::_Iterator<1> __thiscall LLBufferArray::makeSegment(int,int)" > (?makeSegment@LLBufferArray@@QAE?AV?$_Iterator@$00@?$list@VLLSegment > @@V?$allocator@VLLSegment@@@std@@@std@@HH@Z) referenced in function > "public: void __thiscall tut::test_object tut::buffer>::test<12>(void)" (??$test@$0M@@?$test_object@Ubuffer@tut@ > @@tut@@QAEXXZ) > 1>llbuffer_tut.obj : error LNK2019: unresolved external symbol "public: > class std::list > >::_Iterator<1> __thiscall LLBufferArray::constructSegmentAfter(unsigned > char *,class LLSegment &)" (?constructSegmentAfter@LLBufferArray > @@QAE?AV?$_Iterator@$00@?$list@VLLSegment@@V?$allocator@VLLSegment@@@std@ > @@std@@PAEAAVLLSegment@@@Z) referenced in function "public: void > __thiscall tut::test_object::test<13>(void)" (??$test@ > $0N@@?$test_object@Ubuffer@tut@@@tut@@QAEXXZ) > 1>llcommon.lib(llfile.obj) : error LNK2019: unresolved external symbol > __invalid_parameter_noinfo referenced in function "public: struct _Ctypevec > __thiscall std::_Locinfo::_Getctype(void)const " (?_Getctype@_Locinfo@std > @@QBE?AU_Ctypevec@@XZ) > 1>llcommon.lib(llstring.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(llsdserialize_xml.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llxml.lib(llxmlnode.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(lldate.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(lluri.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(llsdutil.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(llstreamtools.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llcommon.lib(llsd.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llcommon.lib(llmemorystream.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llcommon.lib(llsdserialize.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llcommon.lib(llerror.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(lldatapacker.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llinventory.lib(llinventory.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llinventory.lib(llsaleinfo.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llinventory.lib(llpermissions.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llcircuit.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(llassetstorage.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llhttpclient.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llhttpsender.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llmime.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(llservicebuilder.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(message.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(llmessageconfig.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llpumpio.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(llsdrpcclient.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llfiltersd2xmlrpc.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmessage.lib(llsdrpcserver.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>llmath.lib(lluuid.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmath.lib(v4color.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmath.lib(llmd5.obj) : error LNK2001: unresolved external symbol > __invalid_parameter_noinfo > 1>llmessage.lib(llbufferstream.obj) : error LNK2001: unresolved external > symbol __invalid_parameter_noinfo > 1>ReleaseNoOpt/test.exe : fatal error LNK1120: 7 unresolved externals > 1>Build log was saved at "file://h:\SL Open source > codes\slviewer-src-Branch_1-19-0-Viewer\linden\indra\test\ReleaseNoOpt\BuildLog.htm" > 1>test - 43 error(s), 63 warning(s) > ========== Build: 0 succeeded, 1 failed, 22 up-to-date, 0 skipped > ========== > > > -- > Ciao, > Ajinkya > -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080808/80ec11cb/attachment-0001.htm From sheet.spotter at gmail.com Sat Aug 9 10:04:37 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Sat Aug 9 10:04:40 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: <65EA7829717B45E09F11FEF2200F8835@kenb> I would be curious how extensively the existing SL server exploits the use of multi-threading and multi-processor. Is there any opportunity to distribute the functional blocks across multiple threads or processors? For example, could the physics be run on one processor, while the communications (chat, IM, notices, etc.) runs on a separate processor, and the scripts ran on yet another processor? I realize there are dependencies and overlap. Chat distance relies on the location of each avatar, which is calculated by the physics engine. Similarly, scripts frequently rely on position information for performing sensor scans, etc. Are physics, communications, and scripts even the three most important functional blocks? Hmmm.Texture downloads probably figure prominently in the equation. Sheet Spotter _____ From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Dahlia Trimble Sent: August 8, 2008 7:35 PM To: sldev@lists.secondlife.com Subject: Re: [sldev] Scalable Sim Question Something vaguely similar to this has been demonstrated by the libopenmv team. They used bots to echo the performance of musicians in another sim so a wider audience could see the show. John Hurliman has a video of this on his blog at http://www.jhurliman.org/index.php/2006/long-range-in-second-life-or-cleverl y-disguised-robots/ The SL Shakespeare Company has also conducted research along these lines. OpenSim has an experimental feature where a region that becomes highly loaded can be split into multiple smaller regions and each segment can then be processed on a seperate CPU core, but I'm not certain how complete the implementation is yet. On Fri, Aug 8, 2008 at 12:14 PM, Steven Hornik wrote: I want to preface that I'm not a developer but lurk on this list to see what's happening. I'm sure this isn't the best place to post this question but thought some here might be able to provide an answer or at least a pointer in the right direction. Here is the dilemma: finite limit to how many avatars can be on one sim. Solution (well I don't know if this can be done and that's why I'm asking here): Mirrored sims, a bit of explanation, please ignore my use of incorrect terminology. Let's say I have an island with objects, scripts etc. That sim can "hold" roughly 60 AV's, what if I had 500 AV's that needed to access that sim. What is to prevent SL from using a mirror image of one server that holds my island/objects/scripts and scaling it (as needed) depending on how many av's were trying to access that one location. So I might be on the sim and interacting with 59 other AV's. When someone else tries to access the sim, instead of a sim full message they would be sent to a mirrored sim - objects/scripts would be the same and you would be with a different set of 59 AV's, and so on. Is this pie-in-the-sky? Thanks, Steven ________________________ Dr. Steven Hornik University of Central Florida Dixon School of Accounting 407-823-5739 Second Life: Robins Hermano http://mydebitcredit.com yahoo ID: shornik twitter: shornik _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080809/f3bd0a7f/attachment.htm From lenglish5 at cox.net Sat Aug 9 13:02:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 9 13:03:00 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <65EA7829717B45E09F11FEF2200F8835@kenb> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> Message-ID: <489DF7F1.2030201@cox.net> Sheet Spotter wrote: > > I would be curious how extensively the existing SL server exploits the > use of multi-threading and multi-processor. > > Is there any opportunity to distribute the functional blocks across > multiple threads or processors? > > For example, could the physics be run on one processor, while the > communications (chat, IM, notices, etc.) runs on a separate processor, > and the scripts ran on yet another processor? > > I realize there are dependencies and overlap. Chat distance relies on > the location of each avatar, which is calculated by the physics > engine. Similarly, scripts frequently rely on position information for > performing sensor scans, etc. > > Are physics, communications, and scripts even the three most important > functional blocks? Hmmm?Texture downloads probably figure prominently > in the equation. > The first part at refactoring how the grid works is being tested right now with the Open Grid Public Beta testing. Logging into the test metaverse and TPing between grids is now being accomplished by the client interacting with the "Agent Domain," a server which eventually will be analogous to an ISP for your avatar account(s) and it will handle login, group IM, persistent inventory, etc., while the local simulator will handle physics, local chat and geometry issues. The eventual division will be "Agent Domain" vs "Region Domain" where each is responsible for a certain subset of services that the SL client now receives exclusively through the simulator. Within the AD and RD there could easily be multiple servers responsible for various servics, but that should be transparent to the client. There may be other "Domains" defined as time goes on to logically distribute the responsibilities a bit more. Lawson From secret.argent at gmail.com Sat Aug 9 15:54:34 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 9 15:54:30 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489DF7F1.2030201@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> Message-ID: On 2008-08-09, at 15:02, Lawson English wrote: > Logging into the test metaverse and TPing between grids is now > being accomplished by the client interacting with the "Agent > Domain," a server which eventually will be analogous to an ISP for > your avatar account(s) and it will handle login, group IM, > persistent inventory, etc., while the local simulator will handle > physics, local chat and geometry issues. The eventual division will > be "Agent Domain" vs "Region Domain" where each is responsible for > a certain subset of services that the SL client now receives > exclusively through the simulator. I'm not sure that putting the inventory exclusively in the agent domain is a good idea. (1) Inventory garbage collection for inventory "owned by" other grids will be a knotty problem. (2) License and copyright issues. Having a third section of inventory (after your inventory and the library) for region-local inventory that's only available in that region would avoid a lot of copyright issues, and also allow for inventory that's required for a game grid to stay in that grid. From dmahalko at gmail.com Sat Aug 9 16:51:04 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Aug 9 16:51:06 2008 Subject: [sldev] Re: [HELP]Compilation error In-Reply-To: References: Message-ID: The problems are all occurring in project "test" . . . >From my own experiences with it, this project does not appear to be used by the client build process at all. I've seen the "test" project fail to compile, but in the end, the viewer compiles successfully anyway. So, you can likely safely disable compilation of "test", and just ignore all these errors. - Scalar Tardis / Dale Mahalko On Fri, Aug 8, 2008 at 11:44 PM, Ajinkya Kale wrote: > I was not getting this error earlier. I tried building after a long time and > now it is throwing this error. > Can anyone help me regarding the same. Thank you , > > On Fri, Aug 8, 2008 at 12:23 PM, Ajinkya Kale wrote: >> >> This is the error messages i get after a build in VC2005 >> >> 1>------ Build started: Project: test, Configuration: ReleaseNoOpt Win32 >> ------ From lenglish5 at cox.net Sat Aug 9 17:02:10 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 9 17:02:13 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> Message-ID: <489E3002.3020709@cox.net> Argent Stonecutter wrote: > On 2008-08-09, at 15:02, Lawson English wrote: >> Logging into the test metaverse and TPing between grids is now being >> accomplished by the client interacting with the "Agent Domain," a >> server which eventually will be analogous to an ISP for your avatar >> account(s) and it will handle login, group IM, persistent inventory, >> etc., while the local simulator will handle physics, local chat and >> geometry issues. The eventual division will be "Agent Domain" vs >> "Region Domain" where each is responsible for a certain subset of >> services that the SL client now receives exclusively through the >> simulator. > > I'm not sure that putting the inventory exclusively in the agent > domain is a good idea. > > (1) Inventory garbage collection for inventory "owned by" other grids > will be a knotty problem. > (2) License and copyright issues. > > Having a third section of inventory (after your inventory and the > library) for region-local inventory that's only available in that > region would avoid a lot of copyright issues, and also allow for > inventory that's required for a game grid to stay in that grid. > > Oh, absolutely, that's why I said "persistent" inventory to differentiate from sim-specific. And OpenSIm developers are discussing having multiple inventory/asset servers available per avatar/Agent Domain anyway. Lawson From secret.argent at gmail.com Sat Aug 9 17:44:12 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 9 17:44:13 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489E3002.3020709@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> Message-ID: <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> On 2008-08-09, at 19:02, Lawson English wrote: > Argent Stonecutter wrote: >> On 2008-08-09, at 15:02, Lawson English wrote: >>> Logging into the test metaverse and TPing between grids is now >>> being accomplished by the client interacting with the "Agent >>> Domain," a server which eventually will be analogous to an ISP >>> for your avatar account(s) and it will handle login, group IM, >>> persistent inventory, etc., while the local simulator will handle >>> physics, local chat and geometry issues. The eventual division >>> will be "Agent Domain" vs "Region Domain" where each is >>> responsible for a certain subset of services that the SL client >>> now receives exclusively through the simulator. >> >> I'm not sure that putting the inventory exclusively in the agent >> domain is a good idea. > Oh, absolutely, that's why I said "persistent" inventory to > differentiate from sim-specific. OK, I think there's either a terminology problem here or I'm not making things clear. I'm talking about persistent inventory that is NOT in the agent domain. When you return to the same grid, you would have access to the inventory you had in that grid when you left it. > And OpenSIm developers are discussing having multiple inventory/ > asset servers available per avatar/Agent Domain anyway. You mean the agent domain would have components in multiple trust domains? o_O? From lenglish5 at cox.net Sat Aug 9 21:31:29 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 9 21:31:32 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> Message-ID: <489E6F21.2050407@cox.net> Argent Stonecutter wrote: > On 2008-08-09, at 19:02, Lawson English wrote: >> Argent Stonecutter wrote: >>> On 2008-08-09, at 15:02, Lawson English wrote: >>>> Logging into the test metaverse and TPing between grids is now >>>> being accomplished by the client interacting with the "Agent >>>> Domain," a server which eventually will be analogous to an ISP for >>>> your avatar account(s) and it will handle login, group IM, >>>> persistent inventory, etc., while the local simulator will handle >>>> physics, local chat and geometry issues. The eventual division will >>>> be "Agent Domain" vs "Region Domain" where each is responsible for >>>> a certain subset of services that the SL client now receives >>>> exclusively through the simulator. >>> > >>> I'm not sure that putting the inventory exclusively in the agent >>> domain is a good idea. > >> Oh, absolutely, that's why I said "persistent" inventory to >> differentiate from sim-specific. > > OK, I think there's either a terminology problem here or I'm not > making things clear. > > I'm talking about persistent inventory that is NOT in the agent domain. AGent domain invetnroy should potentially be available on ANY grid, permissions and agreements permitting. Connections to region (or grid) -specific inventory servers would be acquired during establishing presence with a specific region/grid. > > When you return to the same grid, you would have access to the > inventory you had in that grid when you left it. > >> And OpenSIm developers are discussing having multiple inventory/asset >> servers available per avatar/Agent Domain anyway. > > You mean the agent domain would have components in multiple trust > domains? o_O? The Agent Domain might have the ability to establish communications with more than one asset server, or IM server, or whatever and the degree/kind of trust for the Agent Domain is whole new set of discussions right there, I think. IN fact, seems to me that a few recent discussions for Groupies and Zero's office hours have been about that topic and of course, Which Linden has been having a blast talking about monetary transactions in the metaverse. Lawson From kaleajinkya at gmail.com Sun Aug 10 04:54:50 2008 From: kaleajinkya at gmail.com (Ajinkya Kale) Date: Sun Aug 10 04:54:53 2008 Subject: [sldev] Re: [HELP]Compilation error In-Reply-To: References: Message-ID: Thanks a lot . That worked :-) :-) On Sat, Aug 9, 2008 at 4:51 PM, Dale Mahalko wrote: > The problems are all occurring in project "test" . . . > > From my own experiences with it, this project does not appear to be > used by the client build process at all. I've seen the "test" project > fail to compile, but in the end, the viewer compiles successfully > anyway. > > So, you can likely safely disable compilation of "test", and just > ignore all these errors. > > - Scalar Tardis / Dale Mahalko > > > On Fri, Aug 8, 2008 at 11:44 PM, Ajinkya Kale > wrote: > > I was not getting this error earlier. I tried building after a long time > and > > now it is throwing this error. > > Can anyone help me regarding the same. Thank you , > > > > On Fri, Aug 8, 2008 at 12:23 PM, Ajinkya Kale > wrote: > >> > >> This is the error messages i get after a build in VC2005 > >> > >> 1>------ Build started: Project: test, Configuration: ReleaseNoOpt Win32 > >> ------ > -- Ciao, Ajinkya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080810/ddbbcc01/attachment.htm From secret.argent at gmail.com Sun Aug 10 07:38:06 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 10 07:38:05 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489E6F21.2050407@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> Message-ID: <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> On 2008-08-09, at 23:31, Lawson English wrote: >> I'm talking about persistent inventory that is NOT in the agent >> domain. > > AGent domain invetnroy should potentially be available on ANY grid, > permissions and agreements permitting. Connections to region (or > grid) -specific inventory servers would be acquired during > establishing presence with a specific region/grid. I'm obviously not making this point clear. What I'm talking about is there being grid-local assets associated with your account. Assets that are not shared with any other grid. This inventory is not shared with any servers that are not in the same protection domain as the grid's region domain. Let's say I log in to grid.piratebay.org. I then teleport to Second Life, and arrive as a Ruth. I go to Yadni's Junkyard and get some freebies. I edit an asset in my inventory. Is that asset now transferred to an asset server at grid.piratebay.org, or does it remain on an asset server in the SL grid? There's several possibilities: 1. Yes, it's now on an asset server in the pirate bay. The copybot ruckus will be nothing to this. 2. You can't do that, you can't take that into your inventory. that's the current situation. 3. No, it stays in the SL asset server but the pirate bay agent domain can get a copy of it, but promises not to give you access to it if you're not on the SL grid. This seems to be what you're suggesting, and from the point of view of content creators it's indistinguishable from #1. 4. It stays in the SL asset server and your client connects directly to that server to manipulate it, and that access is only allowed if you're in the SL grid subject to the SL rules. That's what I'm suggesting. The distinction between 3 and 4 is that SL doesn't have to trust the pirate bay grid to let you teleport into the SL grid from there. You could have a client that does all kinds of bad things, but you don't have the pirate bay grid effectively becoming that client for everyone who happens to be logged into it. From me at signpostmarv.name Sun Aug 10 08:13:27 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Aug 10 08:13:33 2008 Subject: [sldev] Landmarks & Navigation Project suggestion: Mozilla Weave Message-ID: <489F0597.2090607@signpostmarv.name> Snippets copied from the Mozilla Weave project page: "Weave is a Mozilla Labs? project to develop a coherent framework and platform for deeply integrating online services with the browser." "Support for major browser data types, including bookmarks, browsing history, cookies, saved passwords, saved form data, and tabs." Overview of the Idea 1. browser metadata is pushed into the cloud (e.g. bookmarks, history, customizations, etc.) 2. this metadata is transparently reflected everywhere an individual gets online 3. we provide a basic framework for easily sharing and delegating access to this metadata to friends, family and third-parties 4. we build tools and APIs to extend this framework and to provide new user experiences Not entirely sure where the project is at this point, but I'm suggesting Mozilla Weave tech as a possible persistence solution for Landmarks & Navigation history. Given that it's possible to maintain your own Mozilla Weave server, this would allow Residents to maintain their data independently of Linden Lab, which is an important step given the direction of OGP. Given that one of the ideas behind Weave is to "push customizations into the cloud", this opens up the possibility of persisting your SL Preferences, XUI mods (and in the future, viewer plugins ?) away from the machine you use mainly (doubly handy in cases of the Viewer overwriting these customisations). http://labs.mozilla.com/projects/weave/ http://lifehacker.com/400110/set-up-mozilla-weave-on-your-own-server ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080810/6064ea46/smime.bin From dahliatrimble at gmail.com Sun Aug 10 09:52:38 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun Aug 10 09:52:41 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> Message-ID: I think there needs to be a distinction made between inventory and assets. I was under the impression that assets on the asset server were the actual serialized asset, and anything in inventory was just a reference to the asset? If true, then it would seen the inventory could be safely stored in the agent domain without risk as the asset servers could have the final say about whether an outside grid gets access to the asset. On Sun, Aug 10, 2008 at 7:38 AM, Argent Stonecutter wrote: > On 2008-08-09, at 23:31, Lawson English wrote: > >> I'm talking about persistent inventory that is NOT in the agent domain. >>> >> >> > AGent domain invetnroy should potentially be available on ANY grid, >> permissions and agreements permitting. Connections to region (or grid) >> -specific inventory servers would be acquired during establishing presence >> with a specific region/grid. >> > > I'm obviously not making this point clear. > > What I'm talking about is there being grid-local assets associated with > your account. Assets that are not shared with any other grid. This inventory > is not shared with any servers that are not in the same protection domain as > the grid's region domain. > > Let's say I log in to grid.piratebay.org. I then teleport to Second Life, > and arrive as a Ruth. I go to Yadni's Junkyard and get some freebies. I edit > an asset in my inventory. Is that asset now transferred to an asset server > at grid.piratebay.org, or does it remain on an asset server in the SL > grid? > > There's several possibilities: > > 1. Yes, it's now on an asset server in the pirate bay. The copybot ruckus > will be nothing to this. > > 2. You can't do that, you can't take that into your inventory. that's the > current situation. > > 3. No, it stays in the SL asset server but the pirate bay agent domain can > get a copy of it, but promises not to give you access to it if you're not on > the SL grid. This seems to be what you're suggesting, and from the point of > view of content creators it's indistinguishable from #1. > > 4. It stays in the SL asset server and your client connects directly to > that server to manipulate it, and that access is only allowed if you're in > the SL grid subject to the SL rules. That's what I'm suggesting. > > The distinction between 3 and 4 is that SL doesn't have to trust the pirate > bay grid to let you teleport into the SL grid from there. You could have a > client that does all kinds of bad things, but you don't have the pirate bay > grid effectively becoming that client for everyone who happens to be logged > into it. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080810/63df28b9/attachment.htm From secret.argent at gmail.com Sun Aug 10 10:30:57 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 10 10:30:57 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> Message-ID: <231C06B8-DE2F-42BE-BCDF-7921439202C7@gmail.com> On 2008-08-10, at 11:52, Dahlia Trimble wrote: > I think there needs to be a distinction made between inventory and > assets. I was under the impression that assets on the asset server > were the actual serialized asset, and anything in inventory was > just a reference to the asset? If true, then it would seen the > inventory could be safely stored in the agent domain without risk > as the asset servers could have the final say about whether an > outside grid gets access to the asset. Are the asset servers in the region domain or the agent domain? From Lawson English's original note: >> [The agent domain will] handle login, group IM, persistent >> inventory, etc., while the local simulator will handle physics, >> local chat and geometry issues. The eventual division will be >> "Agent Domain" vs "Region Domain" where each is responsible for a >> certain subset of services that the SL client now receives >> exclusively through the simulator. It seemed to me that this was saying that the agent domain was responsible for the assets. From dahliatrimble at gmail.com Sun Aug 10 12:15:46 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Sun Aug 10 12:15:50 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <231C06B8-DE2F-42BE-BCDF-7921439202C7@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <231C06B8-DE2F-42BE-BCDF-7921439202C7@gmail.com> Message-ID: I'm speculating a bit here but I think in sl? the assets are stored in some kind of centralized storage system (the "asset server"), and inventory is kept in another separate storage system. Regions are able to access assets from the central storage system. If the client needs access to the actual asset (such as textures, sounds, etc.) it uses the region as a proxy, so perhaps from the agent domain's perspective, I guess the asset server is part if the region domain? For Opensim, there may be multiple asset servers, or in standalone mode, the region itself may use local databases for asset and inventory storage. Typically in "grid mode" there is a centralized asset store for the grid and another seperate one for inventory. There may also be other configurations that deviate substantially from the either standalone or grid mode. I haven't read the relevant AWG documentation closely enough to know how interop mode deviates from this model so I can't comment. On Sun, Aug 10, 2008 at 10:30 AM, Argent Stonecutter < secret.argent@gmail.com> wrote: > On 2008-08-10, at 11:52, Dahlia Trimble wrote: > >> I think there needs to be a distinction made between inventory and assets. >> I was under the impression that assets on the asset server were the actual >> serialized asset, and anything in inventory was just a reference to the >> asset? If true, then it would seen the inventory could be safely stored in >> the agent domain without risk as the asset servers could have the final say >> about whether an outside grid gets access to the asset. >> > > Are the asset servers in the region domain or the agent domain? > > From Lawson English's original note: > >> [The agent domain will] handle login, group IM, persistent inventory, >>> etc., while the local simulator will handle physics, local chat and geometry >>> issues. The eventual division will be "Agent Domain" vs "Region Domain" >>> where each is responsible for a certain subset of services that the SL >>> client now receives exclusively through the simulator. >>> >> > It seemed to me that this was saying that the agent domain was responsible > for the assets. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080810/0dd24bdd/attachment.htm From lenglish5 at cox.net Sun Aug 10 12:44:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 10 12:44:19 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> Message-ID: <489F4511.40706@cox.net> Argent Stonecutter wrote: > On 2008-08-09, at 23:31, Lawson English wrote: >>> I'm talking about persistent inventory that is NOT in the agent domain. >> > >> AGent domain invetnroy should potentially be available on ANY grid, >> permissions and agreements permitting. Connections to region (or >> grid) -specific inventory servers would be acquired during >> establishing presence with a specific region/grid. > > I'm obviously not making this point clear. > > What I'm talking about is there being grid-local assets associated > with your account. Assets that are not shared with any other grid. > This inventory is not shared with any servers that are not in the same > protection domain as the grid's region domain. > > Let's say I log in to grid.piratebay.org. I then teleport to Second > Life, and arrive as a Ruth. I go to Yadni's Junkyard and get some > freebies. I edit an asset in my inventory. Is that asset now > transferred to an asset server at grid.piratebay.org, or does it > remain on an asset server in the SL grid? > Agent Domains have to be trusted as well. If you use their Agent Domain, your client isn't trusted any more than grid.piratebay.org is. So the LL asset server will treat your avatar as untrusted even though you're a registered user. The moral of the story is: don't switch Agent Domains unless you trust them. > There's several possibilities: > > 1. Yes, it's now on an asset server in the pirate bay. The copybot > ruckus will be nothing to this. > > 2. You can't do that, you can't take that into your inventory. that's > the current situation. > > 3. No, it stays in the SL asset server but the pirate bay agent domain > can get a copy of it, but promises not to give you access to it if > you're not on the SL grid. This seems to be what you're suggesting, > and from the point of view of content creators it's indistinguishable > from #1. > > 4. It stays in the SL asset server and your client connects directly > to that server to manipulate it, and that access is only allowed if > you're in the SL grid subject to the SL rules. That's what I'm > suggesting. > > The distinction between 3 and 4 is that SL doesn't have to trust the > pirate bay grid to let you teleport into the SL grid from there. You > could have a client that does all kinds of bad things, but you don't > have the pirate bay grid effectively becoming that client for everyone > who happens to be logged into it. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Sun Aug 10 14:23:50 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 10 14:23:50 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489F4511.40706@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> Message-ID: On 2008-08-10, at 14:44, Lawson English wrote: > Agent Domains have to be trusted as well. If you use their Agent > Domain, your client isn't trusted any more than grid.piratebay.org > is. So the LL asset server will treat your avatar as untrusted even > though you're a registered user. A registered user of what? This has nothing to do with being a registered user or not. Agent domains need to by default NOT be trusted: if I logged in to grid.piratebay.org, I'm a registered user of piratebay.org. Not of Second Life. That's a completely separate issue from my ability to have non-volatile inventory on the SL grid. >> There's several possibilities: >> >> 1. Yes, it's now on an asset server in the pirate bay. The copybot >> ruckus will be nothing to this. >> >> 2. You can't do that, you can't take that into your inventory. >> that's the current situation. >> >> 3. No, it stays in the SL asset server but the pirate bay agent >> domain can get a copy of it, but promises not to give you access >> to it if you're not on the SL grid. This seems to be what you're >> suggesting, and from the point of view of content creators it's >> indistinguishable from #1. >> >> 4. It stays in the SL asset server and your client connects >> directly to that server to manipulate it, and that access is only >> allowed if you're in the SL grid subject to the SL rules. That's >> what I'm suggesting. >> >> The distinction between 3 and 4 is that SL doesn't have to trust >> the pirate bay grid to let you teleport into the SL grid from >> there. You could have a client that does all kinds of bad things, >> but you don't have the pirate bay grid effectively becoming that >> client for everyone who happens to be logged into it. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated >> posting privileges >> > Peter da Silva peter@taronga.com From lenglish5 at cox.net Sun Aug 10 16:13:47 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 10 16:13:54 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> Message-ID: <489F762B.6080800@cox.net> Argent Stonecutter wrote: > On 2008-08-10, at 14:44, Lawson English wrote: >> Agent Domains have to be trusted as well. If you use their Agent >> Domain, your client isn't trusted any more than grid.piratebay.org >> is. So the LL asset server will treat your avatar as untrusted even >> though you're a registered user. > > A registered user of what? This has nothing to do with being a > registered user or not. Agent domains need to by default NOT be > trusted: if I logged in to grid.piratebay.org, I'm a registered user > of piratebay.org. Not of Second Life. That's a completely separate > issue from my ability to have non-volatile inventory on the SL grid. > Well, yes, but your avatar is already registered with SL and no doubt would already be registered via the SL Agent Domain once the metaverse goes live. If you then chose to login via piratebay.org, the fact that your avatar is already registered with SL is trumped by the fact that you're using piratebay.org as your intermediary with the SL grid. The Agent Domain sets up your interface with the grid. Your avatar doesn't get to talk to the grid until after the Agent Domain does so it inherits the trustworthiness of the AD you are using, which replaces the implicit trustworthiness of using the SL AD to get into the SL Grid. What I expect the SL Grid and associated asset servers to do is treat you as a guest with authorization to use a certain name, if that. Certainly no assets should be made available to you beyond those allowed off-SL to the piratebay.org grid because once you start using the piratebay grid as your proxy, there's no guarantee that you are who you say you are. Pirate bay may have created a man in the middle scenario where all assets are being copied into the piratebay asset server before getting passed on to you. By default all grids and all Agent Domains are non-trusted, but some can obtain higher trust the same way grids/regions can via certification and the like. Lawson >>> There's several possibilities: >>> >>> 1. Yes, it's now on an asset server in the pirate bay. The copybot >>> ruckus will be nothing to this. >>> >>> 2. You can't do that, you can't take that into your inventory. >>> that's the current situation. >>> >>> 3. No, it stays in the SL asset server but the pirate bay agent >>> domain can get a copy of it, but promises not to give you access to >>> it if you're not on the SL grid. This seems to be what you're >>> suggesting, and from the point of view of content creators it's >>> indistinguishable from #1. >>> >>> 4. It stays in the SL asset server and your client connects directly >>> to that server to manipulate it, and that access is only allowed if >>> you're in the SL grid subject to the SL rules. That's what I'm >>> suggesting. >>> >>> The distinction between 3 and 4 is that SL doesn't have to trust the >>> pirate bay grid to let you teleport into the SL grid from there. You >>> could have a client that does all kinds of bad things, but you don't >>> have the pirate bay grid effectively becoming that client for >>> everyone who happens to be logged into it. >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> > > Peter da Silva > peter@taronga.com > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From lenglish5 at cox.net Sun Aug 10 16:22:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 10 16:22:45 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489F762B.6080800@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> Message-ID: <489F7843.9080509@cox.net> Lawson English wrote: > Argent Stonecutter wrote: >> On 2008-08-10, at 14:44, Lawson English wrote: >>> Agent Domains have to be trusted as well. If you use their Agent >>> Domain, your client isn't trusted any more than grid.piratebay.org >>> is. So the LL asset server will treat your avatar as untrusted even >>> though you're a registered user. >> >> A registered user of what? This has nothing to do with being a >> registered user or not. Agent domains need to by default NOT be >> trusted: if I logged in to grid.piratebay.org, I'm a registered user >> of piratebay.org. Not of Second Life. That's a completely separate >> issue from my ability to have non-volatile inventory on the SL grid. >> > Well, yes, but your avatar is already registered with SL and no doubt > would already be registered via the SL Agent Domain once the metaverse > goes live. If you then chose to login via piratebay.org, the fact that > your avatar is already registered with SL is trumped by the fact that > you're using piratebay.org as your intermediary with the SL grid. The > Agent Domain sets up your interface with the grid. Your avatar doesn't > get to talk to the grid until after the Agent Domain does so it > inherits the trustworthiness of the AD you are using, which replaces > the implicit trustworthiness of using the SL AD to get into the SL Grid. > > What I expect the SL Grid and associated asset servers to do is treat > you as a guest with authorization to use a certain name, if that. > Certainly no assets should be made available to you beyond those > allowed off-SL to the piratebay.org grid because once you start using > the piratebay grid as your proxy, there's no guarantee that you are > who you say you are. Pirate bay may have created a man in the middle > scenario where all assets are being copied into the piratebay asset > server before getting passed on to you. By default all grids and all > Agent Domains are non-trusted, but some can obtain higher trust the > same way grids/regions can via certification and the like. It's even worse than that. I wouldn't expect piratesbay.org to be allowed to respresent ANY avatar on the SL grid, period. Lawson From secret.argent at gmail.com Sun Aug 10 18:01:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 10 18:02:01 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489F762B.6080800@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> Message-ID: <4F3C0AF5-35A3-4E27-A46D-3F1A3F4E46AB@gmail.com> On 2008-08-10, at 18:13, Lawson English wrote: > Well, yes, but your avatar is already registered with SL No it isn't. It's *only* registered with piratebay's grid. That's the whole point to this, you don't have to be registered with all the grids separately. I'm not coming in as "Argent Stomecutter", I'm coming in as "Argent Stonecutter.piratebay". Who is a completely different person. No relationship at all. I may not even be me. >>>> There's several possibilities: >>>> >>>> 1. Yes, it's now on an asset server in the pirate bay. The >>>> copybot ruckus will be nothing to this. >>>> >>>> 2. You can't do that, you can't take that into your inventory. >>>> that's the current situation. >>>> >>>> 3. No, it stays in the SL asset server but the pirate bay agent >>>> domain can get a copy of it, but promises not to give you access >>>> to it if you're not on the SL grid. This seems to be what you're >>>> suggesting, and from the point of view of content creators it's >>>> indistinguishable from #1. >>>> >>>> 4. It stays in the SL asset server and your client connects >>>> directly to that server to manipulate it, and that access is >>>> only allowed if you're in the SL grid subject to the SL rules. >>>> That's what I'm suggesting. >>>> >>>> The distinction between 3 and 4 is that SL doesn't have to trust >>>> the pirate bay grid to let you teleport into the SL grid from >>>> there. You could have a client that does all kinds of bad >>>> things, but you don't have the pirate bay grid effectively >>>> becoming that client for everyone who happens to be logged into it. >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated >>>> posting privileges >>>> >>> >> >> Peter da Silva >> peter@taronga.com >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated >> posting privileges >> > Peter da Silva peter@taronga.com From secret.argent at gmail.com Sun Aug 10 18:02:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 10 18:02:41 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489F7843.9080509@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> Message-ID: <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> On 2008-08-10, at 18:22, Lawson English wrote: > It's even worse than that. I wouldn't expect piratesbay.org to be > allowed to respresent ANY avatar on the SL grid, period. Why not? From overtake at keynet.com.br Sun Aug 10 18:50:30 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Sun Aug 10 18:50:48 2008 Subject: [sldev] Check this In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: <007701c8fb54$a33c6cd0$e9b54670$@com.br> Take a look here: http://gridaverse.com/ Very interesting. And here: http://www.altoxeno.com/second-life/gadgets/96-gvurl-a-better-slurl An article about it. {}Overtake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080810/24881db6/attachment-0001.htm From lenglish5 at cox.net Sun Aug 10 19:54:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 10 19:54:46 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> Message-ID: <489FA9F3.9080808@cox.net> Argent Stonecutter wrote: > On 2008-08-10, at 18:22, Lawson English wrote: >> It's even worse than that. I wouldn't expect piratesbay.org to be >> allowed to respresent ANY avatar on the SL grid, period. > > > Why not? > > > Well, if they are the same piratebay with the same rep for handling avatar assets as for handling bootleg torrents, an avatar registered through piratesbay would be banned from just about anywhere except the "wild, wild west" grids. Lawson From nivardus at gmail.com Sun Aug 10 22:47:43 2008 From: nivardus at gmail.com (Gonta) Date: Sun Aug 10 22:47:46 2008 Subject: [sldev] [VWR] shadow-draft-2 branch Freezing In-Reply-To: <71d0a1670808102235w4e355f04oe736d8daee03a3e6@mail.gmail.com> References: <71d0a1670808102235w4e355f04oe736d8daee03a3e6@mail.gmail.com> Message-ID: <71d0a1670808102247w13bf4ba4n47d406ebac1892b1@mail.gmail.com> The last two public commits ?r967 and r940? of the shadow-draft-2 branch have built successfully, but they freeze when I turn on the deferred pipeline. Is anyone else experiencing this issue? Revisions prior to 940 worked fine, (including the first release of code with ambient occlusion.) -Gonta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/0062a521/attachment.htm From fire at eslteacherlink.co.kr Sun Aug 10 22:56:57 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Sun Aug 10 22:57:12 2008 Subject: [sldev] Check out the technology James Cameron, creator of "The Avatar" movie - is making!!! Message-ID: <1dabc2a30808102256x6639eedn611031fb9c8576f8@mail.gmail.com> Hi everyone, I've been on holidays for two weeks, but now I'm back - to revel in wonderful SLED contributions, and keep up on DIGG on an hourly basis. While reading Digg.com today, I came up with a delicious article about James Cameron's "Avatar" movie that he is creating. After reading about the very interesting 3d technology he has created this film, one must sit and ponder the wonderful goodies that will follow for us virtual worlders Seams to me a full Snow-crash realization is innevitable I've highlighted some amazing news below from the article, but to sum up, I see the following resulting from his acheivements: *Consider adding this to our wonderful secondlife client:* - Real-Time video capture of your facial expressions - and automatic projection into the virtual world - A portable monitor / camera you could hold in your hands, point it at something, and instantly translate its contents immediately into the Virtual world! --- anyhow, here's a snippet from the article "The way we developed the performance capture workflow on 'Avatar" is we have our virtual camera, which allows me to, in real time, hold a camera -- it's really a monitor -- in my hands and point it at the actors and see them as their CG chartacters," Cameron said. The actors wear leotards and a "head rig" with a tiny standard-definition camera that takes an image of an actor's face. "That is going though facial algorithms and going back into the camera as a real-time CG face of the character," the helmer said. "You see it talk; you see the eyes move. It is pretty phenomenal. "Once we've laid down a take, the take exists in the digital asset management system," he said. "It an be accessed at any time. Long after the actors have gone home, I'm still out there with the virtual camera, shooting coverage on the scene. I just have to play the take back. I can do the close up, the wide shot. ... I can even move them around on a limited basis. We relight it. We do all kinds of things. "It's this amazing ability to quickly conjure scenes and images and great fantasyscapes that is very visual. We call it 'director centric' because I can use the camera to block the actors," Cameron related. "When you are doing performance capture, creatively it's very daunting. It's very hard to imagine what it will look like. But if you can see it, if you can have a virtual image of what is it going to be like, then you are there. As the processing power goes up our models get more sophisticated and our lighting tools get more sophisticated, even while we are making this movie. I'm still doing a lot of virtual camera work on the film ... on stuff that was shot six months ago." Cameron also used what he calls FPR, or Facial Performance Replacement, which he likens to the film sound technique of ADR (Automated Dialogue Replacement). To describe the process, the director relates that he recently wanted to redo a line spoken by actor Laz Alonzo. "We changed the words and he redid the dialogue. We didn't have to recapture (his body performance) and he didn't have to put the performance capture suit on again. We were just creating new words, and we were creating a new face." On the cinematography, Cameron related that his goal was to create "one movie where the aesthetics of physical production and the aesthetics of virtual production are, to the extent that we could do it, pretty much it identical." Reaching this goal involved development of what Cameron calls the 'Simulcam,' which essentially treats a real camera like the virtual camera and in turn helps to remove guesswork. "We're taking our virtual production toolset and superimposing it on physical production," Cameron said. "We turned the set on the soundstage into a capture volume and turned the physical camera into a capture virtual camera, so we were able to integrate CG characters and environments into our live action." As an example of how this works, he explained: "We have people in flying vehicles, and I can see what is outside the window, fed in, in real time." On 3-D, both Cameron and Pace are looking ahead. "The real question is 'where does all this go?" Cameron said. "Are we looking at a situation maybe 10-15 years out where most laptops are sold with 3-D stereoscopic screens, most montors are stereo compatible, most DVD players can run stereo content? ... I can see this becoming much more pervasive that we are thinking now." He and Pace believe content is the key. -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/4f532b39/attachment.htm From soft at lindenlab.com Sun Aug 10 23:47:00 2008 From: soft at lindenlab.com (Soft) Date: Sun Aug 10 23:47:02 2008 Subject: [sldev] [VWR] shadow-draft-2 branch Freezing In-Reply-To: <71d0a1670808102247w13bf4ba4n47d406ebac1892b1@mail.gmail.com> References: <71d0a1670808102235w4e355f04oe736d8daee03a3e6@mail.gmail.com> <71d0a1670808102247w13bf4ba4n47d406ebac1892b1@mail.gmail.com> Message-ID: On Mon, Aug 11, 2008 at 12:47 AM, Gonta wrote: > The last two public commits ?r967 and r940? of the shadow-draft-2 branch > have built successfully, but they freeze when I turn on the deferred > pipeline. Is anyone else experiencing this issue? Revisions prior to 940 > worked fine, (including the first release of code with ambient occlusion.) Runitai says he's working on ATI compatibility - right now the tree favors ATI and may break on nVidia. Soon it will cover both. From sammy.frederix at gmail.com Mon Aug 11 03:32:04 2008 From: sammy.frederix at gmail.com (Sammy Frederix) Date: Mon Aug 11 03:32:18 2008 Subject: [sldev] [VWR] shadow-draft-2 branch Freezing In-Reply-To: References: <71d0a1670808102235w4e355f04oe736d8daee03a3e6@mail.gmail.com> <71d0a1670808102247w13bf4ba4n47d406ebac1892b1@mail.gmail.com> Message-ID: <7F8BB6D3-EDD9-4AD7-B917-9AC6621540D3@gmail.com> On 11/08/2008, at 4:47 PM, Soft wrote: > > Runitai says he's working on ATI compatibility - right now the tree > favors ATI and may break on nVidia. Soon it will cover both. Do you happen to know which ATI chips are supported? From secret.argent at gmail.com Mon Aug 11 04:03:04 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Aug 11 04:03:05 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <489FA9F3.9080808@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> Message-ID: <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> On 2008-08-10, at 21:54, Lawson English wrote: > Argent Stonecutter wrote: >> On 2008-08-10, at 18:22, Lawson English wrote: >>> It's even worse than that. I wouldn't expect piratesbay.org to be >>> allowed to respresent ANY avatar on the SL grid, period. >> >> Why not? > Well, if they are the same piratebay with the same rep for handling > avatar assets as for handling bootleg torrents, an avatar > registered through piratesbay would be banned from just about > anywhere except the "wild, wild west" grids. If the fact that the user is teleporting in from piratesbay instead of registering a free alt on secondlife makes it more dangerous to let the piratesbay account in, then there's a problem in the design. THAT is what I'm trying to get an idea of here. From lenglish5 at cox.net Mon Aug 11 04:32:39 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 11 04:32:41 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> Message-ID: <48A02357.2070306@cox.net> Argent Stonecutter wrote: > On 2008-08-10, at 21:54, Lawson English wrote: >> Argent Stonecutter wrote: >>> On 2008-08-10, at 18:22, Lawson English wrote: >>>> It's even worse than that. I wouldn't expect piratesbay.org to be >>>> allowed to respresent ANY avatar on the SL grid, period. >>> > >>> Why not? > >> Well, if they are the same piratebay with the same rep for handling >> avatar assets as for handling bootleg torrents, an avatar registered >> through piratesbay would be banned from just about anywhere except >> the "wild, wild west" grids. > > > If the fact that the user is teleporting in from piratesbay instead of > registering a free alt on secondlife makes it more dangerous to let > the piratesbay account in, then there's a problem in the design. > > THAT is what I'm trying to get an idea of here. > Well, if you look at how login to the Agent Domain works, the client uses the AD as the intermediary to perform the introductions to any and all regions. http://wiki.secondlife.com/wiki/SLGOGP_Teleport_Strawman A malicious agent domain could insert itself as a man-in-the-middle proxy for all transactions between the sim and the client, and obtain any and all assets being sent to the client for display. Basically, it would be a copybot on steroids, funneling data directly into its own pirating-asset server, all the data being sent from the Second Life simulator to the client. I don't see any way around this issue: any Agent Domain that is allowed to connect to the SL grid must be deemed as trustworthy as the most trusted grid granted access to the SL asset server. Agent Domains, by their nature, have to be the most trusted part of the entire system, because they have access to everything the client does because every client that logs in via an AD is a potential copybot for that AD. Lawson From secret.argent at gmail.com Mon Aug 11 06:01:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Aug 11 06:01:36 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A02357.2070306@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> Message-ID: <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> On 2008-08-11, at 06:32, Lawson English wrote: > A malicious agent domain could insert itself as a man-in-the-middle > proxy for all transactions between the sim and the client, and > obtain any and all assets being sent to the client for display. > Basically, it would be a copybot on steroids, funneling data > directly into its own pirating-asset server, all the data being > sent from the Second Life simulator to the client. > > I don't see any way around this issue: any Agent Domain that is > allowed to connect to the SL grid must be deemed as trustworthy as > the most trusted grid granted access to the SL asset server. Agent > Domains, by their nature, have to be the most trusted part of the > entire system, because they have access to everything the client > does because every client that logs in via an AD is a potential > copybot for that AD. OK, so what you're telling me is that SL can never allow logins from any other grid's agent domain, because the design is fundamentally broken from a security standpoint as well as horribly inefficient. From lenglish5 at cox.net Mon Aug 11 06:58:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 11 06:58:50 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <65EA7829717B45E09F11FEF2200F8835@kenb> <489DF7F1.2030201@cox.net> <489E3002.3020709@cox.net> <62F6C612-ED2B-4969-8A11-4302B75E1077@gmail.com> <489E6F21.2050407@cox.net> <82056DE5-0370-4340-94ED-DA58E1AEA391@gmail.com> <489F4511.40706@cox.net> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> Message-ID: <48A04599.8010601@cox.net> Argent Stonecutter wrote: > On 2008-08-11, at 06:32, Lawson English wrote: >> A malicious agent domain could insert itself as a man-in-the-middle >> proxy for all transactions between the sim and the client, and obtain >> any and all assets being sent to the client for display. Basically, >> it would be a copybot on steroids, funneling data directly into its >> own pirating-asset server, all the data being sent from the Second >> Life simulator to the client. >> >> I don't see any way around this issue: any Agent Domain that is >> allowed to connect to the SL grid must be deemed as trustworthy as >> the most trusted grid granted access to the SL asset server. Agent >> Domains, by their nature, have to be the most trusted part of the >> entire system, because they have access to everything the client does >> because every client that logs in via an AD is a potential copybot >> for that AD. > > OK, so what you're telling me is that SL can never allow logins from > any other grid's agent domain, because the design is fundamentally > broken from a security standpoint as well as horribly inefficient. I don't know about inefficient. If you think it is than why don't you contact ZEro and Zha and Tess and so on to help them fix the design or at least have them explain to me why my analysis is off. And as far as "never" allowing something goes, I never said that. However, an Agent Domain is in a unique position to do mischief and has to be at least as trusted as the most trusted external grid that the SL servers agree to deal with. Lawson From soft at lindenlab.com Mon Aug 11 07:13:48 2008 From: soft at lindenlab.com (Soft) Date: Mon Aug 11 07:13:51 2008 Subject: [sldev] Re: release/ to be renamed trunk/ In-Reply-To: References: Message-ID: A reminder on this. Note that the old release/new trunk may be unbuildable, pending resolution of a lingering issue from last week. On Wed, Aug 6, 2008 at 3:51 PM, Soft wrote: > I just sent one of my quarterly gripes to an internal list about the > abiguity of our "release/" branch name. It occurs to me that I don't > need to keep the name the same internally and externally, however. So: > > ** This is a heads up that the branch will change names with the > Friday source drop. > > If you do an svn update on your release/ branch and it fails, simply > do an svn relocate with the old and new full URLs. Help in placing all > the wiki changes would be very much appreciated. > From secret.argent at gmail.com Mon Aug 11 08:43:54 2008 From: secret.argent at gmail.com (Argent) Date: Mon Aug 11 08:43:59 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A04599.8010601@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> Message-ID: <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> On Mon, Aug 11, 2008 at 8:58 AM, Lawson English wrote: > I don't know about inefficient. If you think it is than why don't you > contact ZEro and Zha and Tess and so on to help them fix the design or at > least have them explain to me why my analysis is off. > If I understand you correctly, every asset request by the client will be sent to the agent domain, which will contact the resource domain, fetch the asset, and forward it to the client. That doesn't seem scalable. Are you sure you're interpreting the design correctly? It doesn't seem to me that the agent domain could be doing the proxying you're suggesting. > And as far as "never" allowing something goes, I never said that. However, > an Agent Domain is in a unique position to do mischief and has to be at > least as trusted as the most trusted external grid that the SL servers agree > to deal with. > That means that you wouldn't ever be able to log on to Opengrid and teleport to Secondlife, no? Pirates Bay would be an extreme case, but the same logic would apply to every other agent domain. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/52cacecc/attachment.htm From monkowsk at watson.ibm.com Mon Aug 11 11:20:45 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Aug 11 11:21:51 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: <48A082FD.5040104@watson.ibm.com> Dahlia Trimble wrote: > OpenSim has an experimental feature where a region that becomes highly > loaded can be split into multiple smaller regions and each segment can > then be processed on a seperate CPU core, but I'm not certain how > complete the implementation is yet. My experience on crowded sims has been that no only is the sim unresponsive to motion controls and so forth, but also the client frame rate becomes intolerably slow. Splitting the sim can help with the responsiveness, but I suspect the frame rate will still leave it intolerable. Mike From lenglish5 at cox.net Mon Aug 11 15:39:46 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 11 15:39:48 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F762B.6080800@cox.net> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> Message-ID: <48A0BFB2.90201@cox.net> Argent wrote: > On Mon, Aug 11, 2008 at 8:58 AM, Lawson English > wrote: > > I don't know about inefficient. If you think it is than why don't > you contact ZEro and Zha and Tess and so on to help them fix the > design or at least have them explain to me why my analysis is off. > > > If I understand you correctly, every asset request by the client will > be sent to the agent domain, which will contact the resource domain, > fetch the asset, and forward it to the client. Not what I meant to say. My understanding is that the pattern will continue what is used for TP. The AD vouches to the asset server that the client is really that specific agent that is rezzed currently in that specific region/grid, obtains the initial seed cap for asset transactions for that specific agent/region combo, passes it on to the client, and then bows out. After that any communication involves the client, region and asset server, not the AD. I would expect that there are time limits on how long a given capability is valid and that once the client logs out or leaves a given grid, the cap is deauthorized in some way. > > That doesn't seem scalable. > > Are you sure you're interpreting the design correctly? It doesn't seem > to me that the agent domain could be doing the proxying you're suggesting. > The details are murky to me, but I think that that is the gist of it: The AD validates the client during initial login, and validates the grids that the client visits. But it only performs introductions for the initial connections with the various services. But that is enough to make it the ultimate man-in-the-middle malware if it was untrustworthy because it could grab the real CAP and pass a faux-CAP onto the client and transfer whatever data the client is asking for to its own pirate server before passing it on. > And as far as "never" allowing something goes, I never said that. > However, an Agent Domain is in a unique position to do mischief > and has to be at least as trusted as the most trusted external > grid that the SL servers agree to deal with. > > > That means that you wouldn't ever be able to log on to Opengrid and > teleport to Secondlife, no? > > Pirates Bay would be an extreme case, but the same logic would apply > to every other agent domain. Unless the Agent Domain has trust agreements in place with a specific grid or set of grids, I don't think that you can log into an arbitrary Agent Domain and automatically expect to get into any arbitrary region (grid). This is certainly only MY interpretation of things, and I may be totally out there as far as my understanding of the design goes. But I think I'm right. The AD is the keeper of the accounts of multiple agents. It must be deemed trustworthy by wide range of destination regions AND a wide range of asset servers and other services and not just by default, but only by agreements/contracts/certificates/whatevers. Lawson From lenglish5 at cox.net Mon Aug 11 15:44:27 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 11 15:44:29 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A082FD.5040104@watson.ibm.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <48A082FD.5040104@watson.ibm.com> Message-ID: <48A0C0CB.2060908@cox.net> Mike Monkowski wrote: > Dahlia Trimble wrote: >> OpenSim has an experimental feature where a region that becomes >> highly loaded can be split into multiple smaller regions and each >> segment can then be processed on a seperate CPU core, but I'm not >> certain how complete the implementation is yet. > > My experience on crowded sims has been that no only is the sim > unresponsive to motion controls and so forth, but also the client > frame rate becomes intolerably slow. Splitting the sim can help with > the responsiveness, but I suspect the frame rate will still leave it > intolerable. Quite a few proposals for how to handle scalable sims have been discussed in the brainstorming and use-case pages of the AWG and AW Groupies. It's not an easy problem. http://wiki.secondlife.com/wiki/Brainstorming#ANALYSIS:_Region_Subdivision_as_a_scaling_method https://wiki.secondlife.com/wiki/Use_Cases Lawson From skidz.tweak at gmail.com Mon Aug 11 16:02:57 2008 From: skidz.tweak at gmail.com (Skidz Tweak) Date: Mon Aug 11 15:59:27 2008 Subject: [sldev] Check this In-Reply-To: <007701c8fb54$a33c6cd0$e9b54670$@com.br> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <007701c8fb54$a33c6cd0$e9b54670$@com.br> Message-ID: <48a0c449.2586460a.489f.ffff9b68@mx.google.com> Hey there Sylvio. just seen this message as I was doing me weekly read through the group :) I am actually the creator of Gridaverse. thx for spreading the word. really appreciate it. Have lot of big plans for it. Once I get it running really smooth on the main Secondlife Grid, I plan on supporting all the other grids out there. I would really be interested in hearing anyone else opinion. or ideas on what I could do better. so feedback is really welcomed. From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Sylvio Deutsch Sent: Sunday, August 10, 2008 8:51 PM To: sldev@lists.secondlife.com Subject: [sldev] Check this Take a look here: http://gridaverse.com/ Very interesting. And here: http://www.altoxeno.com/second-life/gadgets/96-gvurl-a-better-slurl An article about it. {}Overtake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/33827535/attachment.htm From dahliatrimble at gmail.com Mon Aug 11 16:07:10 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon Aug 11 16:07:13 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A082FD.5040104@watson.ibm.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <48A082FD.5040104@watson.ibm.com> Message-ID: Granted, it's only one possible solution that only addresses server side load. Unfortunately, low client side FPS rates are for the most part outside of the realm of control of the server. However, I wouldn't want to discourage efforts to increase server capability simply because current clients may encounter situations where they may be overloaded by a crowded region. Technology has a habit of improving over time and I would bet that newer viewers may become more efficient or optimized, and more powerful display hardware will decrease in price and become more mainstream. There are some tricks that a user can do to improve the frame rates in crowded areas. Alt-zooming on the subject of interest can have a huge effect. To a lesser degree, changing the graphics settings to a lower quality level and enabling avatar imposters can make the difference between staying in world or crashing with an overheated GPU. Perhaps someday the viewer could adjust these settings dynamically in order to provide acceptable frame rates for any type of content being displayed. On Mon, Aug 11, 2008 at 11:20 AM, Mike Monkowski wrote: > Dahlia Trimble wrote: > >> OpenSim has an experimental feature where a region that becomes highly >> loaded can be split into multiple smaller regions and each segment can then >> be processed on a seperate CPU core, but I'm not certain how complete the >> implementation is yet. >> > > My experience on crowded sims has been that no only is the sim unresponsive > to motion controls and so forth, but also the client frame rate becomes > intolerably slow. Splitting the sim can help with the responsiveness, but I > suspect the frame rate will still leave it intolerable. > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/e5865438/attachment.htm From secret.argent at gmail.com Mon Aug 11 16:59:43 2008 From: secret.argent at gmail.com (Argent) Date: Mon Aug 11 16:59:47 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A0BFB2.90201@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> Message-ID: <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> On Mon, Aug 11, 2008 at 5:39 PM, Lawson English wrote: > it could grab the real CAP and pass a faux-CAP onto the client and transfer > whatever data the client is asking for to its own pirate server before > passing it on. Good point. But... that raises another question. If the CAP can't be authenticated as being from the region domain you think you're connecting to then any kind of transproxy will have the same problems... and the point of a transproxy is that you don't know it's there. That's why SSL requires certificate authorities and PGP requires the web of trust and SSH requires an unchanging host key. > Unless the Agent Domain has trust agreements in place with a specific grid > or set of grids, I don't think that you can log into an arbitrary Agent > Domain and automatically expect to get into any arbitrary region (grid). I'm not sure that buys you much practical protection, so long as you can get a free account on SL with no meaningful authentication, since it's unlikely that there will be any regions that refuse to allow logins from the Second Life agent domain. > It must be deemed trustworthy by wide range of destination regions AND a > wide range of asset servers and other services and not just by default, but > only by agreements/contracts/certificates/whatevers. What I'm saying is that the AD really can at most be trusted to provide a unique name and UUID that it guarantees represents the same person each time it's used. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080811/69de985b/attachment-0001.htm From lenglish5 at cox.net Mon Aug 11 17:46:14 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 11 17:46:16 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> Message-ID: <48A0DD56.9080607@cox.net> Argent wrote: > On Mon, Aug 11, 2008 at 5:39 PM, Lawson English > wrote: > > it could grab the real CAP and pass a faux-CAP onto the client and > transfer whatever data the client is asking for to its own pirate > server before passing it on. > > > Good point. > > But... that raises another question. > > If the CAP can't be authenticated as being from the region domain you > think you're connecting to then any kind of transproxy will have the > same problems... and the point of a transproxy is that you don't know > it's there. That's why SSL requires certificate authorities and PGP > requires the web of trust and SSH requires an unchanging host key. > > > Unless the Agent Domain has trust agreements in place with a > specific grid or set of grids, I don't think that you can log into > an arbitrary Agent Domain and automatically expect to get into any > arbitrary region (grid). > > > I'm not sure that buys you much practical protection, so long as you > can get a free account on SL with no meaningful authentication, since > it's unlikely that there will be any regions that refuse to allow > logins from the Second Life agent domain. > > > It must be deemed trustworthy by wide range of destination regions > AND a wide range of asset servers and other services and not just > by default, but only by agreements/contracts/certificates/whatevers. > > > What I'm saying is that the AD really can at most be trusted to > provide a unique name and UUID that it guarantees represents the same > person each time it's used. Well, it can also be trusted (we hope) not to play man-in-the-middle games. Lawson From lenglish5 at cox.net Tue Aug 12 00:54:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Aug 12 00:54:25 2008 Subject: [sldev] [AWG] AW Groupies meeting on Trust Domains Tuesday 9:30 AM SLT Message-ID: <48A141AC.5040606@cox.net> Tuesday's 9:30 AM SLT meeting will be more on trust domains. A bit of preliminary background can be found here: http://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model As always, if you need an invite to get to thornbridgetown, IM Saijanai Kuhn, Tree Kyomoon or Zha Ewry for an AW Groupies invite. Lawson (Saijanai Kuhn) From lenglish5 at cox.net Tue Aug 12 11:19:25 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Aug 12 11:19:37 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A0DD56.9080607@cox.net> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> <48A0DD56.9080607@cox.net> Message-ID: <48A1D42D.6020801@cox.net> Lawson English wrote: > Argent wrote: >> [..] >> >> What I'm saying is that the AD really can at most be trusted to >> provide a unique name and UUID that it guarantees represents the same >> person each time it's used. > Well, it can also be trusted (we hope) not to play man-in-the-middle > games. > > Lawson > > > This morning's AW Groupies topic was all about this stuff: https://wiki.secondlife.com/wiki/AW_Groupies/Chat_Logs/AWGroupies-2008-08-12 Lawson From open at autistici.org Tue Aug 12 12:42:51 2008 From: open at autistici.org (Opensource Obscure) Date: Tue Aug 12 12:42:55 2008 Subject: [sldev] Repackaging of the rendering engine (shading, blocking light) Message-ID: <4f3f40f256266498db26dac5648028e3@localhost> Hi all, this article needs to be shared :) Maybe some people on this mailing list are directly involved in this project and they want to add something? I know the AR Second Life project at Georgia Tech is not really news, but I didn't know about the rendering enhancements talked about here. [...] - Is the software for AR Second Life available to the public to download and try out? - Right now, we haven't even got it integrated into the latest source build. We will have a student working on it starting in the fall semester. So, hopefully September, October, we'll start making it available. There's some components of it that I want to contribute immediately back. For example, we repackaged the rendering engine such that we can do a bunch of effects like shading and blocking light. That would be really useful for anybody who wants to do machinima. [...] from 'When Worlds Collide' - http://bit.ly/1gonVj or http://www.escapistmagazine.com/articles/view/issues/issue_162/5130-When-Worlds-Collide Ciao, Opensource Obscure From evolutie at gmail.com Tue Aug 12 13:27:15 2008 From: evolutie at gmail.com (evolutie) Date: Tue Aug 12 13:27:21 2008 Subject: [sldev] Check this In-Reply-To: <48a0c449.2586460a.489f.ffff9b68@mx.google.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <007701c8fb54$a33c6cd0$e9b54670$@com.br> <48a0c449.2586460a.489f.ffff9b68@mx.google.com> Message-ID: <5fb4b1fa0808121327x6cff57b5qfaf475dc077fedba@mail.gmail.com> Hi there, and check out this: http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ pooweeeee, evo On Tue, Aug 12, 2008 at 12:02 AM, Skidz Tweak wrote: > Hey there Sylvio? just seen this message as I was doing me weekly read > through the group :) > > > > I am actually the creator of Gridaverse? thx for spreading the word? really > appreciate it. Have lot of big plans for it? > > > > Once I get it running really smooth on the main Secondlife Grid, I plan on > supporting all the other grids out there. > > > > I would really be interested in hearing anyone else opinion? or ideas on > what I could do better? so feedback is really welcomed. > > > > > > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Sylvio Deutsch > Sent: Sunday, August 10, 2008 8:51 PM > To: sldev@lists.secondlife.com > Subject: [sldev] Check this > > > > Take a look here: http://gridaverse.com/ > > > > Very interesting. > > > > And here: > http://www.altoxeno.com/second-life/gadgets/96-gvurl-a-better-slurl > > An article about it. > > > > > > > > {}Overtake > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- http://www.creativemachinery.org From missannotoole at yahoo.com Tue Aug 12 14:50:22 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Tue Aug 12 14:50:24 2008 Subject: [sldev] Check this Message-ID: <538961.99230.qm@web59108.mail.re1.yahoo.com> EPIC FAKE!! Wonder what they smoked to make "The Cloud"? lol These guys better have something to real time demo soon or they won't be able to show face within 5 miles of a VC firm. ----- Original Message ---- From: evolutie To: Skidz Tweak Cc: sldev@lists.secondlife.com Sent: Tuesday, August 12, 2008 4:27:15 PM Subject: Re: [sldev] Check this Hi there, and check out this: http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ pooweeeee, evo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080812/94141f82/attachment.htm From me at signpostmarv.name Tue Aug 12 15:04:50 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Aug 12 15:04:52 2008 Subject: [sldev] Check this In-Reply-To: <538961.99230.qm@web59108.mail.re1.yahoo.com> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> Message-ID: <48A20902.1000508@signpostmarv.name> Looks like the artist is a fan of Paprika..... Ann Otoole wrote: > EPIC FAKE!! > > Wonder what they smoked to make "The Cloud"? > > lol > > These guys better have something to real time demo soon or they won't > be able to show face within 5 miles of a VC firm. > > ----- Original Message ---- > From: evolutie > To: Skidz Tweak > Cc: sldev@lists.secondlife.com > Sent: Tuesday, August 12, 2008 4:27:15 PM > Subject: Re: [sldev] Check this > > Hi there, > > and check out this: > http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ > > pooweeeee, > evo > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080812/21758abf/smime.bin From lenglish5 at cox.net Tue Aug 12 15:45:41 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Aug 12 15:45:47 2008 Subject: [sldev] Check this In-Reply-To: <538961.99230.qm@web59108.mail.re1.yahoo.com> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> Message-ID: <48A21295.4090804@cox.net> Ann Otoole wrote: > EPIC FAKE!! > > Wonder what they smoked to make "The Cloud"? > > lol > > These guys better have something to real time demo soon or they won't > be able to show face within 5 miles of a VC firm. > > ----- Original Message ---- > From: evolutie > To: Skidz Tweak > Cc: sldev@lists.secondlife.com > Sent: Tuesday, August 12, 2008 4:27:15 PM > Subject: Re: [sldev] Check this > > Hi there, > > and check out this: > http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ > > pooweeeee, > evo > > Apparently, that was meant as an "artist's conception" of the video, not the real video. Or, at least I HOPE they meant it that way. Lawson From sldev at bitparts.org Tue Aug 12 16:01:05 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Tue Aug 12 16:01:46 2008 Subject: [sldev] Check this In-Reply-To: <48A21295.4090804@cox.net> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A21295.4090804@cox.net> Message-ID: <48A21631.9030606@bitparts.org> It's an interesting concept, if true/feasible, it would seem to be what Phillip intended SL to be from the beginning - more of a streaming /view/ of a world, rather than streaming updates of what your PC has to render. Broadband these days can send video fairly well - the trouble would be rendering this kind of realism not just for one person, but for 20, 60, 100 thousand at a time - on /top/ of the existing computations regarding physics, scripting, etc. Their cloud.. better be bigger than any existing cloud. I doubt any of the distributed computing "clouds" could even handle more than a couple of avatars at a time, and those don't guarantee CPU time to any given process. Lawson English wrote: > Ann Otoole wrote: >> EPIC FAKE!! >> >> Wonder what they smoked to make "The Cloud"? >> >> lol >> >> These guys better have something to real time demo soon or they won't >> be able to show face within 5 miles of a VC firm. >> >> ----- Original Message ---- >> From: evolutie >> To: Skidz Tweak >> Cc: sldev@lists.secondlife.com >> Sent: Tuesday, August 12, 2008 4:27:15 PM >> Subject: Re: [sldev] Check this >> >> Hi there, >> >> and check out this: >> http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ >> >> >> pooweeeee, >> evo >> >> > Apparently, that was meant as an "artist's conception" of the video, > not the real video. Or, at least I HOPE they meant it that way. > > Lawson > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > From darien.caldwell at gmail.com Tue Aug 12 17:33:17 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Tue Aug 12 17:33:23 2008 Subject: [sldev] Check this In-Reply-To: <48A21631.9030606@bitparts.org> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A21295.4090804@cox.net> <48A21631.9030606@bitparts.org> Message-ID: <835a5b860808121733j202bff2ev2ac2e299b0625607@mail.gmail.com> I'm still waiting on my flying car. :P On 8/12/08, Buckaroo Mu wrote: > It's an interesting concept, if true/feasible, it would seem to be what > Phillip intended SL to be from the beginning - more of a streaming > /view/ of a world, rather than streaming updates of what your PC has to > render. Broadband these days can send video fairly well - the trouble > would be rendering this kind of realism not just for one person, but for > 20, 60, 100 thousand at a time - on /top/ of the existing computations > regarding physics, scripting, etc. Their cloud.. better be bigger than > any existing cloud. I doubt any of the distributed computing "clouds" > could even handle more than a couple of avatars at a time, and those > don't guarantee CPU time to any given process. > > Lawson English wrote: >> Ann Otoole wrote: >>> EPIC FAKE!! >>> >>> Wonder what they smoked to make "The Cloud"? >>> >>> lol >>> >>> These guys better have something to real time demo soon or they won't >>> be able to show face within 5 miles of a VC firm. >>> >>> ----- Original Message ---- >>> From: evolutie >>> To: Skidz Tweak >>> Cc: sldev@lists.secondlife.com >>> Sent: Tuesday, August 12, 2008 4:27:15 PM >>> Subject: Re: [sldev] Check this >>> >>> Hi there, >>> >>> and check out this: >>> http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ >>> >>> >>> >>> pooweeeee, >>> evo >>> >>> >> Apparently, that was meant as an "artist's conception" of the video, >> not the real video. Or, at least I HOPE they meant it that way. >> >> Lawson >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From monkowsk at watson.ibm.com Tue Aug 12 17:57:28 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Aug 12 17:57:48 2008 Subject: [sldev] Check this In-Reply-To: <538961.99230.qm@web59108.mail.re1.yahoo.com> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> Message-ID: <48A23177.9090809@watson.ibm.com> The video is a collection of various clips and stills, but there is some truth to it. See http://www.techcrunch.com/2008/07/09/otoy-developing-server-side-3d-rendering-technology/ Mike Ann Otoole wrote: > EPIC FAKE!! > > Wonder what they smoked to make "The Cloud"? > > lol > > These guys better have something to real time demo soon or they won't be > able to show face within 5 miles of a VC firm. > > ----- Original Message ---- > From: evolutie > To: Skidz Tweak > Cc: sldev@lists.secondlife.com > Sent: Tuesday, August 12, 2008 4:27:15 PM > Subject: Re: [sldev] Check this > > Hi there, > > and check out this: > http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ > > pooweeeee, > evo From spot at napalmriot.com Tue Aug 12 20:29:00 2008 From: spot at napalmriot.com (Spot) Date: Tue Aug 12 20:29:08 2008 Subject: [sldev] Check this In-Reply-To: <48A23177.9090809@watson.ibm.com> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A23177.9090809@watson.ibm.com> Message-ID: <48A254FC.5040909@napalmriot.com> There are actually shots from that Cityspace video in the Screenshots section of the OTOY site here.. http://www.otoy.com/site/start.htm Specifically 'The Palace' and 'Subway' that I can see. Spot Mike Monkowski wrote: > The video is a collection of various clips and stills, but there is > some truth to it. See > http://www.techcrunch.com/2008/07/09/otoy-developing-server-side-3d-rendering-technology/ > > > Mike > > > Ann Otoole wrote: >> EPIC FAKE!! >> >> Wonder what they smoked to make "The Cloud"? >> >> lol >> >> These guys better have something to real time demo soon or they won't >> be able to show face within 5 miles of a VC firm. >> >> ----- Original Message ---- >> From: evolutie >> To: Skidz Tweak >> Cc: sldev@lists.secondlife.com >> Sent: Tuesday, August 12, 2008 4:27:15 PM >> Subject: Re: [sldev] Check this >> >> Hi there, >> >> and check out this: >> http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ >> >> >> pooweeeee, >> evo > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From spot at napalmriot.com Tue Aug 12 20:45:19 2008 From: spot at napalmriot.com (Spot) Date: Tue Aug 12 20:45:28 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> Message-ID: <48A258CF.90000@napalmriot.com> I have not read the rest of the thread yet, so this may have been brought up. However, BigWorld does something much like this with their MMO platform (IIRC). They use a honeycomb like griding technique which watches the load on each separate section, and then splits thats section when a threshold is met, handing the other side of the split to a new processor, and so on, until (in theory) it could get down to each avatar sitting on it's own processor (assuming it was burning up enough cycles to need it). The interesting part is that they do this in real-time. It may happen in the middle of a group battle and the members never know that the responsibility for a few of them just got shifted to another shoulder. Spot Dahlia Trimble wrote: > Something vaguely similar to this has been demonstrated by the > libopenmv team. They used bots to echo the performance of musicians in > another sim so a wider audience could see the show. John Hurliman has > a video of this on his blog at > http://www.jhurliman.org/index.php/2006/long-range-in-second-life-or-cleverly-disguised-robots/ > The SL Shakespeare Company has also conducted research along these lines. > > OpenSim has an experimental feature where a region that becomes highly > loaded can be split into multiple smaller regions and each segment can > then be processed on a seperate CPU core, but I'm not certain how > complete the implementation is yet. > > > On Fri, Aug 8, 2008 at 12:14 PM, Steven Hornik > wrote: > > I want to preface that I'm not a developer but lurk on this list > to see what's happening. I'm sure this isn't the best place to > post this question but thought some here might be able to provide > an answer or at least a pointer in the right direction. > > Here is the dilemma: finite limit to how many avatars can be on > one sim. > Solution (well I don't know if this can be done and that's why I'm > asking here): Mirrored sims, a bit of explanation, please ignore > my use of incorrect terminology. Let's say I have an island with > objects, scripts etc. That sim can "hold" roughly 60 AV's, what > if I had 500 AV's that needed to access that sim. What is to > prevent SL from using a mirror image of one server that holds my > island/objects/scripts and scaling it (as needed) depending on how > many av's were trying to access that one location. So I might be > on the sim and interacting with 59 other AV's. When someone else > tries to access the sim, instead of a sim full message they would > be sent to a mirrored sim - objects/scripts would be the same and > you would be with a different set of 59 AV's, and so on. > > Is this pie-in-the-sky? > > Thanks, > Steven > > ________________________ > Dr. Steven Hornik > University of Central Florida > Dixon School of Accounting > 407-823-5739 > Second Life: Robins Hermano > http://mydebitcredit.com > yahoo ID: shornik > twitter: shornik > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From spot at napalmriot.com Tue Aug 12 21:10:43 2008 From: spot at napalmriot.com (Spot) Date: Tue Aug 12 21:10:50 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> Message-ID: <48A25EC3.6060009@napalmriot.com> I don't post on here much, but I've been following your discussion and this one is burning in the back of my mind. Since we are more or less dealing with virtual 'worlds' here, doesn't it make some sense to base trust/authority on how well a particular grid is governed? Much like travel/extradition agreements between national entities. Do you let people from this foreign country into your country? Can that depend on how quick that foreign entity is to enforce things you care about, such as copyright issues, etc? I am kind of running on a impulsive train of thought here. Feel free to smack me down. Spot Argent wrote: > On Mon, Aug 11, 2008 at 5:39 PM, Lawson English > wrote: > > it could grab the real CAP and pass a faux-CAP onto the client and > transfer whatever data the client is asking for to its own pirate > server before passing it on. > > > Good point. > > But... that raises another question. > > If the CAP can't be authenticated as being from the region domain you > think you're connecting to then any kind of transproxy will have the > same problems... and the point of a transproxy is that you don't know > it's there. That's why SSL requires certificate authorities and PGP > requires the web of trust and SSH requires an unchanging host key. > > > Unless the Agent Domain has trust agreements in place with a > specific grid or set of grids, I don't think that you can log into > an arbitrary Agent Domain and automatically expect to get into any > arbitrary region (grid). > > > I'm not sure that buys you much practical protection, so long as you > can get a free account on SL with no meaningful authentication, since > it's unlikely that there will be any regions that refuse to allow > logins from the Second Life agent domain. > > > It must be deemed trustworthy by wide range of destination regions > AND a wide range of asset servers and other services and not just > by default, but only by agreements/contracts/certificates/whatevers. > > > What I'm saying is that the AD really can at most be trusted to > provide a unique name and UUID that it guarantees represents the same > person each time it's used. > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From dahliatrimble at gmail.com Tue Aug 12 21:47:44 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Aug 12 21:47:47 2008 Subject: [sldev] Check this In-Reply-To: <48A254FC.5040909@napalmriot.com> References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A23177.9090809@watson.ibm.com> <48A254FC.5040909@napalmriot.com> Message-ID: They certainly have done a nice job with textures and the lighting isn't bad. Looks totally feasable to me if they stream a small size video, something like 640x480. Maybe even easier if several viewers can share portions of the same perspective at the same time. The problem probably comes when they have a lot of fast moving objects, many viewers with different perspectives, 1080p resolutions, high frame rates, and more people wanting to view than they have hardware to support. I imagine the costs of the hardware in the could could also be quite high if they want very high quality output. I doubt they can achieve high quality rendering at acceptable frame rates without GPU support even if the resolutions are small. I wonder how much of that is video playing on backdrops (or even still images) and how much is actual 3D rendering? It's a common technique to mix the two. On Tue, Aug 12, 2008 at 8:29 PM, Spot wrote: > There are actually shots from that Cityspace video in the Screenshots > section of the OTOY site here.. > > http://www.otoy.com/site/start.htm > > Specifically 'The Palace' and 'Subway' that I can see. > > Spot > > > Mike Monkowski wrote: > >> The video is a collection of various clips and stills, but there is some >> truth to it. See >> http://www.techcrunch.com/2008/07/09/otoy-developing-server-side-3d-rendering-technology/ >> >> Mike >> >> >> Ann Otoole wrote: >> >>> EPIC FAKE!! >>> >>> Wonder what they smoked to make "The Cloud"? >>> >>> lol >>> >>> These guys better have something to real time demo soon or they won't be >>> able to show face within 5 miles of a VC firm. >>> >>> ----- Original Message ---- >>> From: evolutie >>> To: Skidz Tweak >>> Cc: sldev@lists.secondlife.com >>> Sent: Tuesday, August 12, 2008 4:27:15 PM >>> Subject: Re: [sldev] Check this >>> >>> Hi there, >>> >>> and check out this: >>> >>> http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ >>> >>> pooweeeee, >>> evo >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080812/2e6ec2e7/attachment.htm From spot at napalmriot.com Tue Aug 12 21:50:26 2008 From: spot at napalmriot.com (Spot) Date: Tue Aug 12 21:50:33 2008 Subject: [sldev] Check this In-Reply-To: References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A23177.9090809@watson.ibm.com> <48A254FC.5040909@napalmriot.com> Message-ID: <48A26812.1010401@napalmriot.com> Yes, there are many questions I have, which I fear will not be answered for some time to come. Until then, I am adopting an "I'll believe it when I see it" attitude. :) Spot Dahlia Trimble wrote: > They certainly have done a nice job with textures and the lighting > isn't bad. Looks totally feasable to me if they stream a small size > video, something like 640x480. Maybe even easier if several viewers > can share portions of the same perspective at the same time. The > problem probably comes when they have a lot of fast moving objects, > many viewers with different perspectives, 1080p resolutions, high > frame rates, and more people wanting to view than they have hardware > to support. I imagine the costs of the hardware in the could could > also be quite high if they want very high quality output. I doubt they > can achieve high quality rendering at acceptable frame rates without > GPU support even if the resolutions are small. > > I wonder how much of that is video playing on backdrops (or even still > images) and how much is actual 3D rendering? It's a common technique > to mix the two. > > On Tue, Aug 12, 2008 at 8:29 PM, Spot > wrote: > > There are actually shots from that Cityspace video in the > Screenshots section of the OTOY site here.. > > http://www.otoy.com/site/start.htm > > Specifically 'The Palace' and 'Subway' that I can see. > > Spot > > > Mike Monkowski wrote: > > The video is a collection of various clips and stills, but > there is some truth to it. See > http://www.techcrunch.com/2008/07/09/otoy-developing-server-side-3d-rendering-technology/ > > > Mike > > > Ann Otoole wrote: > > EPIC FAKE!! > > Wonder what they smoked to make "The Cloud"? > > lol > > These guys better have something to real time demo soon or > they won't be able to show face within 5 miles of a VC firm. > > ----- Original Message ---- > From: evolutie > > To: Skidz Tweak > > Cc: sldev@lists.secondlife.com > > Sent: Tuesday, August 12, 2008 4:27:15 PM > Subject: Re: [sldev] Check this > > Hi there, > > and check out this: > http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-virtual-world-rendered-in-the-cloud/ > > > pooweeeee, > evo > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From chaosstar at gmail.com Wed Aug 13 04:16:31 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Aug 13 04:16:35 2008 Subject: [sldev] Internal viewer library URL in install.xml, Linux build Message-ID: <9bb32d430808130416o6acbc4c9y36f0223c7ff26d0@mail.gmail.com> Greetings, seems like this one is for Babbage Linden.. in the install.xml of the /trunk release of the viewer seem to be a few internal URLs, mostly server related, however one of those made it into the viewer libs as well: The current install.xml tries to fetch gtk-atk-pango-lib from int.codex.lindenlab.com/~babbage :3 I rewrote the url to s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-linux-20080816.tar.gz and it is working fine again. Wasn't sure if I'm supposed to JIRA this, considering it's about the svn trunk. From chaosstar at gmail.com Wed Aug 13 04:25:38 2008 From: chaosstar at gmail.com (Ambrosia) Date: Wed Aug 13 04:25:41 2008 Subject: [sldev] Re: Internal viewer library URL in install.xml, Linux build In-Reply-To: <9bb32d430808130416o6acbc4c9y36f0223c7ff26d0@mail.gmail.com> References: <9bb32d430808130416o6acbc4c9y36f0223c7ff26d0@mail.gmail.com> Message-ID: <9bb32d430808130425y2d85153dpfc663de243650d4a@mail.gmail.com> Sorry, typo in that one. It should be 20080616.tar.gz On Wed, Aug 13, 2008 at 13:16, Ambrosia wrote: > Greetings, > > seems like this one is for Babbage Linden.. > > in the install.xml of the /trunk release of the viewer seem to be a > few internal URLs, mostly server related, however one of those made it > into the viewer libs as well: > > The current install.xml tries to fetch gtk-atk-pango-lib from > int.codex.lindenlab.com/~babbage :3 > > I rewrote the url to > s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-linux-20080816.tar.gz > and it is working fine again. > > Wasn't sure if I'm supposed to JIRA this, considering it's about the svn trunk. > From secret.argent at gmail.com Wed Aug 13 05:06:04 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Aug 13 05:05:57 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A25EC3.6060009@napalmriot.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> <48A25EC3.6060009@napalmriot.com> Message-ID: On 2008-08-12, at 23:10, Spot wrote: > Since we are more or less dealing with virtual 'worlds' here, > doesn't it make some sense to base trust/authority on how well a > particular grid is governed? The point I'm getting at is that you shouldn't need to trust a grid in the first place, because anyone from another grid can just get a free SL account anyway. Unless SL starts charging for all accounts all you need to do is maintain a non-volatile local inventory so that a remote account doesn't transfer anything out of the grid that a free local account wouldn't. From secret.argent at gmail.com Wed Aug 13 05:22:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Aug 13 05:22:14 2008 Subject: [sldev] Check this In-Reply-To: References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A23177.9090809@watson.ibm.com> <48A254FC.5040909@napalmriot.com> Message-ID: <8F111CA9-81A6-4655-A690-B2983B031F9F@gmail.com> People gripe at lag in SL with only 40,000 agents in-world. If the "cloud" has to handle all the rendering for each agent, what's that going to cost? We're talking about more than a sim's worth of computations just for the rendering, and streaming every pixel in world over the Internet... the CPU and bandwidth requirements are insane. With 40,000 agents you're going to need a cloud many times the size of the SL grid to keep up. From robla at lindenlab.com Wed Aug 13 10:39:16 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Aug 13 10:39:22 2008 Subject: [sldev] Internal viewer library URL in install.xml, Linux build In-Reply-To: <9bb32d430808130416o6acbc4c9y36f0223c7ff26d0@mail.gmail.com> References: <9bb32d430808130416o6acbc4c9y36f0223c7ff26d0@mail.gmail.com> Message-ID: <48A31C44.8070902@lindenlab.com> On 8/13/08 4:16 AM, Ambrosia wrote: > seems like this one is for Babbage Linden.. > > in the install.xml of the /trunk release of the viewer seem to be a > few internal URLs, mostly server related, however one of those made it > into the viewer libs as well: > > The current install.xml tries to fetch gtk-atk-pango-lib from > int.codex.lindenlab.com/~babbage :3 > > I rewrote the url to > s3.amazonaws.com/viewer-source-downloads/install_pkgs/gtk-atk-pango-glib-linux-20080816.tar.gz > and it is working fine again. > > Wasn't sure if I'm supposed to JIRA this, considering it's about the svn trunk > By all means, please do. VWR project, "Source code" component. Attaching a patch (however trivial) is also appreciated, and don't be bashful about putting yourself in doc/contributions.txt as part of the patch. Rob From grant at lindenlab.com Wed Aug 13 12:41:59 2008 From: grant at lindenlab.com (Grant Linden) Date: Wed Aug 13 12:42:02 2008 Subject: [sldev] Topic of discussion for this weeks Rx Team Office Hours Message-ID: <907af5560808131241j72fbded8x2f65eba8a73ef0a0@mail.gmail.com> Topic of discussion for this weeks Rx Team Office Hours - Linden Lab turned off OI and replaced it with a temporary solution. Erica Linden will be present to answer questions. Thursday August 14th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080813/84c4480c/attachment.htm From gigstaggart at gmail.com Wed Aug 13 14:15:48 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Aug 13 14:15:53 2008 Subject: [sldev] Topic of discussion for this weeks Rx Team Office Hours In-Reply-To: <907af5560808131241j72fbded8x2f65eba8a73ef0a0@mail.gmail.com> References: <907af5560808131241j72fbded8x2f65eba8a73ef0a0@mail.gmail.com> Message-ID: <48A34F04.6080601@gmail.com> Grant Linden wrote: > Topic of discussion for this weeks Rx Team Office Hours - Linden Lab turned > off OI and replaced it with a temporary solution. Erica Linden will be > present to answer questions. > What's OI? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080813/cad7f45d/smime.bin From mark at identityserver.net Wed Aug 13 15:10:08 2008 From: mark at identityserver.net (Domino Marama) Date: Wed Aug 13 15:10:11 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights Message-ID: <1218665408.29451.12.camel@domino-laptop> Hi, I'm using the wiki documentation at http://wiki.secondlife.com/wiki/Avatar_Appearance to write an import script for the avatar into Blender (http://dominodesigns.info) I'm not sure how the weights in the .llm files are supposed to be used. As the weights in the file aren't in the expected 0.0 to 1.0 range, I'm assuming there's some math involved, but there's nothing obvious coming to mind. The major part I'm missing is the bone weights, is there some formula I should be using to generate these? So far I've done the entire importer just from the wiki info and I'd prefer to finish it without needing to dive into the client code if possible. Thanks, Domino From sllists at boroon.dasgupta.ch Wed Aug 13 16:33:54 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed Aug 13 16:34:01 2008 Subject: OI = Orientation Island (was: [sldev] Topic of discussion for this weeks Rx Team Office Hours) In-Reply-To: <48A34F04.6080601@gmail.com> References: <907af5560808131241j72fbded8x2f65eba8a73ef0a0@mail.gmail.com> <48A34F04.6080601@gmail.com> Message-ID: <48A36F62.6070804@boroon.dasgupta.ch> Jason Giglio schrieb: > What's OI? http://wiki.secondlife.com/wiki/Orientation_Island cheers Boroondas From overtake at keynet.com.br Thu Aug 14 03:15:52 2008 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Thu Aug 14 03:17:44 2008 Subject: [sldev] Check this In-Reply-To: <5fb4b1fa0808121327x6cff57b5qfaf475dc077fedba@mail.gmail.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <007701c8fb54$a33c6cd0$e9b54670$@com.br> <48a0c449.2586460a.489f.ffff9b68@mx.google.com> <5fb4b1fa0808121327x6cff57b5qfaf475dc077fedba@mail.gmail.com> Message-ID: <003d01c8fdf6$f9991340$eccb39c0$@com.br> That?s amazing!!! Even considering the first part can be "fake", the quality is amazing. They say it?s all made server side? That can be great for logging with low end computers, but wouldn?t limit a lot what else the system can do? I wonder when we will have proper shadows in SL, that would make a lot for it. {}Overtake -----Mensagem original----- De: evolutie [mailto:evolutie@gmail.com] Enviada em: ter?a-feira, 12 de agosto de 2008 17:27 Para: Skidz Tweak Cc: Sylvio Deutsch; sldev@lists.secondlife.com Assunto: Re: [sldev] Check this Hi there, and check out this: http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-vir tual-world-rendered-in-the-cloud/ pooweeeee, evo On Tue, Aug 12, 2008 at 12:02 AM, Skidz Tweak wrote: > Hey there Sylvio just seen this message as I was doing me weekly read > through the group :) > > > > I am actually the creator of Gridaverse thx for spreading the word really > appreciate it. Have lot of big plans for it > > > > Once I get it running really smooth on the main Secondlife Grid, I plan on > supporting all the other grids out there. > > > > I would really be interested in hearing anyone else opinion or ideas on > what I could do better so feedback is really welcomed. > > > > > > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Sylvio Deutsch > Sent: Sunday, August 10, 2008 8:51 PM > To: sldev@lists.secondlife.com > Subject: [sldev] Check this > > > > Take a look here: http://gridaverse.com/ > > > > Very interesting. > > > > And here: > http://www.altoxeno.com/second-life/gadgets/96-gvurl-a-better-slurl > > An article about it. > > > > > > > > {}Overtake > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- http://www.creativemachinery.org From secret.argent at gmail.com Wed Aug 13 05:22:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 14 03:46:27 2008 Subject: [sldev] Check this In-Reply-To: References: <538961.99230.qm@web59108.mail.re1.yahoo.com> <48A23177.9090809@watson.ibm.com> <48A254FC.5040909@napalmriot.com> Message-ID: <8F111CA9-81A6-4655-A690-B2983B031F9F@gmail.com> People gripe at lag in SL with only 40,000 agents in-world. If the "cloud" has to handle all the rendering for each agent, what's that going to cost? We're talking about more than a sim's worth of computations just for the rendering, and streaming every pixel in world over the Internet... the CPU and bandwidth requirements are insane. With 40,000 agents you're going to need a cloud many times the size of the SL grid to keep up. From spot at napalmriot.com Thu Aug 14 04:00:41 2008 From: spot at napalmriot.com (Spot) Date: Thu Aug 14 04:00:48 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> <48A25EC3.6060009@napalmriot.com> Message-ID: <48A41059.2000001@napalmriot.com> Perhaps I am unclear on the goal. I thought the entire point was to create grid interoperability where someone could bounce from grid to grid to grid if they so wished (ala first few chapters of Snowcrash with the 'countries' of Los Angeles). In order to make something like that remotely viable, access should not be dependent on having a separate account with each grid (IMO). That is a barrier to entry which your average person will not cross. You will get grid segregation on a grand scale, and most of it would be on the top two or three grids. As far as inventory control is concerned, that is a more complicated matter, but it seems could also be managed with higher level agreements between grids. Much of this stuff really falls under control of the population's expectations. If people are made _aware_ that assets from this grid can/and do exist in these other grids, then they will not have their expectations broken. You have your real issues with the population when the infrastructure allows for the unexpected. Spot Argent Stonecutter wrote: > On 2008-08-12, at 23:10, Spot wrote: >> Since we are more or less dealing with virtual 'worlds' here, doesn't >> it make some sense to base trust/authority on how well a particular >> grid is governed? > > The point I'm getting at is that you shouldn't need to trust a grid in > the first place, because anyone from another grid can just get a free > SL account anyway. Unless SL starts charging for all accounts all you > need to do is maintain a non-volatile local inventory so that a remote > account doesn't transfer anything out of the grid that a free local > account wouldn't. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From lenglish5 at cox.net Thu Aug 14 04:43:42 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 14 04:43:46 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A41059.2000001@napalmriot.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> <48A25EC3.6060009@napalmriot.com> <48A41059.2000001@napalmriot.com> Message-ID: <48A41A6E.5020207@cox.net> Spot wrote: > Perhaps I am unclear on the goal. I thought the entire point was to > create grid interoperability where someone could bounce from grid to > grid to grid if they so wished (ala first few chapters of Snowcrash > with the 'countries' of Los Angeles). > > In order to make something like that remotely viable, access should > not be dependent on having a separate account with each grid (IMO). > That is a barrier to entry which your average person will not cross. > You will get grid segregation on a grand scale, and most of it would > be on the top two or three grids. As far as inventory control is > concerned, that is a more complicated matter, but it seems could also > be managed with higher level agreements between grids. > > Much of this stuff really falls under control of the population's > expectations. If people are made _aware_ that assets from this grid > can/and do exist in these other grids, then they will not have their > expectations broken. You have your real issues with the population > when the infrastructure allows for the unexpected. > > Spot > There's probably a hundred hours or so of transcripts of discussions about these topics available for review on the wiki. Its not like we haven't been debating these topics for the past 11 months or something. https://wiki.secondlife.com/wiki/AW_Groupies#Architecture_Working_Group_meetings Is a pretty good place to start. > Argent Stonecutter wrote: >> On 2008-08-12, at 23:10, Spot wrote: >>> Since we are more or less dealing with virtual 'worlds' here, >>> doesn't it make some sense to base trust/authority on how well a >>> particular grid is governed? >> >> The point I'm getting at is that you shouldn't need to trust a grid >> in the first place, because anyone from another grid can just get a >> free SL account anyway. Unless SL starts charging for all accounts >> all you need to do is maintain a non-volatile local inventory so that >> a remote account doesn't transfer anything out of the grid that a >> free local account wouldn't. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Thu Aug 14 05:01:07 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Aug 14 05:00:57 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <48A41059.2000001@napalmriot.com> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <489F7843.9080509@cox.net> <0C1A5AC6-CC7D-4295-BE86-B415A1A36AEC@gmail.com> <489FA9F3.9080808@cox.net> <708C6414-23DE-43D4-AF36-43820C94F1A3@gmail.com> <48A02357.2070306@cox.net> <9F9849C3-E0AF-492C-94E5-B8CF129C7CF9@gmail.com> <48A04599.8010601@cox.net> <16309a040808110843h1ebc9552u6eb0ef6abce40969@mail.gmail.com> <48A0BFB2.90201@cox.net> <16309a040808111659q624f12faha6f5918a2eefc20@mail.gmail.com> <48A25EC3.6060009@napalmriot.com> <48A41059.2000001@napalmriot.com> Message-ID: <357A0B63-CFDD-4129-93ED-E13B1EF4B51E@gmail.com> On 2008-08-14, at 06:00, Spot wrote: > Perhaps I am unclear on the goal. I thought the entire point was to > create grid interoperability where someone could bounce from grid > to grid to grid if they so wished (ala first few chapters of > Snowcrash with the 'countries' of Los Angeles). That's true, but the goal has nothing to do with the security issue. My point was not that you should have to get multiple accounts, but that the fact that you can get a free account means that completely blocking access from another grid doesn't actually provide any real security from that grid's users. > Much of this stuff really falls under control of the population's > expectations. If people are made _aware_ that assets from this grid > can/and do exist in these other grids, then they will not have > their expectations broken. That's not what people's expectations are, though. From chess at us.ibm.com Thu Aug 14 06:11:54 2008 From: chess at us.ibm.com (David M Chess) Date: Thu Aug 14 06:12:00 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: <20080814114347.81F8F41B292@stupor.lindenlab.com> Message-ID: > From: Lawson English >There's probably a hundred hours or so of transcripts of discussions >about these topics available for review on the wiki. Its not like we >haven't been debating these topics for the past 11 months or something. > > >https://wiki.secondlife.com/wiki/AW_Groupies#Architecture_Working_Group_meetings > >Is a pretty good place to start. There's also some "boiled down" versions of current thinking about the trust model and use-cases in Infinity's space: https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases Contributions more than welcome. Dale Innis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080814/d28de0ba/attachment.htm From monkowsk at watson.ibm.com Thu Aug 14 06:51:44 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Aug 14 06:53:11 2008 Subject: [sldev] Check this In-Reply-To: <003d01c8fdf6$f9991340$eccb39c0$@com.br> References: <851890.86488.qm@web53801.mail.re2.yahoo.com> <007701c8fb54$a33c6cd0$e9b54670$@com.br> <48a0c449.2586460a.489f.ffff9b68@mx.google.com> <5fb4b1fa0808121327x6cff57b5qfaf475dc077fedba@mail.gmail.com> <003d01c8fdf6$f9991340$eccb39c0$@com.br> Message-ID: <48A43870.90002@watson.ibm.com> This update was added to the article linked below. > Update 3: Here?s what OTOY?s Jules Urbach has to say: > > The 14 mins of real time rendering in this material is streaming live to a Treo 700 at 240 kpbs. This was captured on March 2007, the server was running an ATI RX 1900 GPU. The tech has improved massively since then (as has the HW we now run on). There was never intention to show any part of this to the public until we could include voxel rendering and Lightstage based characters. I think anyone who liked what they saw, will find the final project much more impressive. > > The whole aim of our work last month on the Ruby demo for AMD was to show that the quality of offline and real time work is identical starting with this generation of GPUs. The following presentations this month are just introducing Lightstage and how it makes characters (or any CG object) look 100% real in those real time environments. > > The virtual worlds these technologies are going to be applied to was not meant to be discussed until later this year, after one further announcement regarding the server side platform being developed for OTOY. > > We had nothing to do with editing or leaking this video and can?t comment on anything other than the OTOY technology, since this project is still under NDA. > > Jules Urbach Mike Sylvio Deutsch wrote: > That?s amazing!!! Even considering the first part can be "fake", the quality > is amazing. They say it?s all made server side? That can be great for > logging with low end computers, but wouldn?t limit a lot what else the > system can do? > > I wonder when we will have proper shadows in SL, that would make a lot for > it. > > > > {}Overtake > > > > > -----Mensagem original----- > De: evolutie [mailto:evolutie@gmail.com] > Enviada em: ter?a-feira, 12 de agosto de 2008 17:27 > Para: Skidz Tweak > Cc: Sylvio Deutsch; sldev@lists.secondlife.com > Assunto: Re: [sldev] Check this > > Hi there, > > and check out this: > http://www.techcrunch.com/2008/08/11/liveplace-to-launch-photo-realistic-vir > tual-world-rendered-in-the-cloud/ > > pooweeeee, > evo From monkowsk at watson.ibm.com Thu Aug 14 07:27:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Aug 14 07:31:49 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights In-Reply-To: <1218665408.29451.12.camel@domino-laptop> References: <1218665408.29451.12.camel@domino-laptop> Message-ID: <48A440ED.90707@watson.ibm.com> Ah those tricky Lindens! :-) The implementation is in llviewerjointmesh.cpp. It turns out that each weight actually contains two pieces of information. The number to the left of the decimal point is the index of the joint and also implicitly indexes to the following joint. The actual weight is to the right of the decimal point and interpolates between these two joints. I've added this to the wiki page. Mike Domino Marama wrote: > Hi, > > I'm using the wiki documentation at > http://wiki.secondlife.com/wiki/Avatar_Appearance to write an import > script for the avatar into Blender (http://dominodesigns.info) > > I'm not sure how the weights in the .llm files are supposed to be used. > As the weights in the file aren't in the expected 0.0 to 1.0 range, I'm > assuming there's some math involved, but there's nothing obvious coming > to mind. > > The major part I'm missing is the bone weights, is there some formula I > should be using to generate these? So far I've done the entire importer > just from the wiki info and I'd prefer to finish it without needing to > dive into the client code if possible. > > Thanks, > Domino > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From lenglish5 at cox.net Thu Aug 14 07:39:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Aug 14 07:39:23 2008 Subject: [sldev] Scalable Sim Question In-Reply-To: References: Message-ID: <48A44398.10706@cox.net> David M Chess wrote: > > > From: Lawson English > > >There's probably a hundred hours or so of transcripts of discussions > >about these topics available for review on the wiki. Its not like we > >haven't been debating these topics for the past 11 months or something. > > > > > >https://wiki.secondlife.com/wiki/AW_Groupies#Architecture_Working_Group_meetings > > > >Is a pretty good place to start. > > There's also some "boiled down" versions of current thinking about the > trust model and use-cases in Infinity's space: > > https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model > https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases > > > Contributions more than welcome. > > Dale Innis That too ;-) Lawson From mark at identityserver.net Thu Aug 14 08:39:38 2008 From: mark at identityserver.net (Domino Marama) Date: Thu Aug 14 08:39:44 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights In-Reply-To: <48A440ED.90707@watson.ibm.com> References: <1218665408.29451.12.camel@domino-laptop> <48A440ED.90707@watson.ibm.com> Message-ID: <1218728378.31336.44.camel@domino-laptop> On Thu, 2008-08-14 at 10:27 -0400, Mike Monkowski wrote: > Ah those tricky Lindens! :-) > > The implementation is in llviewerjointmesh.cpp. It turns out that each > weight actually contains two pieces of information. --->8---- > > I've added this to the wiki page. > > Mike Thanks Mike, the numbers make perfect sense now - with stuff like 0.085 and 24.0, I knew something had to be up.. It's so obvious now you've explained it :) /me runs off to code From richard at lindenlab.com Thu Aug 14 14:28:27 2008 From: richard at lindenlab.com (Richard Nelson) Date: Thu Aug 14 14:28:29 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights In-Reply-To: <1218728378.31336.44.camel@domino-laptop> References: <1218665408.29451.12.camel@domino-laptop> <48A440ED.90707@watson.ibm.com> <1218728378.31336.44.camel@domino-laptop> Message-ID: That is correct. Keep in mind that the index is into an "expanded" list of joints, not just a linear array of the joints as defined in the skeleton file. In particular, any joint that has more than one child will have to be repeated in the list for each of its children. R. On Thu, 14 Aug 2008 08:39:38 -0700, Domino Marama wrote: > On Thu, 2008-08-14 at 10:27 -0400, Mike Monkowski wrote: >> Ah those tricky Lindens! :-) >> >> The implementation is in llviewerjointmesh.cpp. It turns out that each >> weight actually contains two pieces of information. --->8---- >> >> I've added this to the wiki page. >> >> Mike > > Thanks Mike, the numbers make perfect sense now - with stuff like 0.085 > and 24.0, I knew something had to be up.. It's so obvious now you've > explained it :) > > /me runs off to code > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From grant at lindenlab.com Thu Aug 14 17:40:14 2008 From: grant at lindenlab.com (Grant Linden) Date: Thu Aug 14 17:40:16 2008 Subject: [sldev] Topic of discussion for this weeks Rx Team Office Hour - Rheta Shan will present her winning design Message-ID: <907af5560808141740x1df3d022h96efece05612b6ab@mail.gmail.com> Topic of discussion for this week's Rx Team Office Hour - Rheta Shan will present her winning design from Dusan Writer's contest to design a "newbie-friendly" version of the Second Life client. Thursday August 21st from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080814/c54c4324/attachment.htm From gareth at litesim.com Fri Aug 15 05:38:19 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 15 05:38:21 2008 Subject: [sldev] GPL issues.... Message-ID: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> It appears that Henri Beauchamp believes the viewer is not licensed under the GPL. I have had a lot of corrospondence with him over his distribution of binaries without matching source code (he only provides patches and a link to the upstream source, the job of merging the patches to get the same binary build is left up to the end user). As far as i'm aware, Nicholaz Beresford also uses this method of distribution, but is nowhere near as arrogant about it. However, i'm rather concerned by the attitude that it's fine to simply not comply with the license if you're otherwise nice to the community. Nicholaz seems to be quite an honest individual, while Henri alternates between bizarre misunderstandings of the nature of the GPL and the viewer's licensing under it and excuses. His latest is that he won't release the code because he doesn't have the quota with his ISP, and that people may want to recombine his patches in different ways. The SL viewer is currently in quite a weird situation - it's GPLed, but deriviative works casually make it very difficult in some cases to modify them via this form of noncompliance and neither LL or any contributor seems to act to enforce it. At the same time, the trademark issues, artwork and proprietary dependencies (such as vivox etc) make it rather less than open. What's the word on this? Will we see active GPL enforcement from LL? Does a contributor want to help out with this? If anyone with a patch in the 1.19.0.5 source wants to help out enforcing this please contact me. From gareth at litesim.com Fri Aug 15 07:12:05 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 15 07:12:08 2008 Subject: [sldev] GPL issues.... In-Reply-To: <000601c8fee0$3ffec610$a400000a@gwsystems2.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <000601c8fee0$3ffec610$a400000a@gwsystems2.com> Message-ID: <61dbdd7d0808150712i51cf827ema9901e383576dbde@mail.gmail.com> He provides only the modified source. This is actually not in compliance with the GPL, but Nicholaz is a fairly decent guy and i'm not as concerned by his behaviour. I am concerned with the more general loose GPL enforcement. On Fri, Aug 15, 2008 at 3:07 PM, Gary Wardell wrote: > Hi, > > Nicholaz releases a binary and a few .xml files that the user has to copy into a previously installed Linden viewer installation > directory of a specific version/build. > > Personally I like this method because it makes it easy to drop back to the Lindin build to check if a certain behavior is in that > build or not. > > He also provides his source for those who want to do their own builds. I think this is to be in compliance with GPL. > > I know this because I run the Nicholaz viewer. > > Gary > >> -----Original Message----- >> From: sldev-bounces@lists.secondlife.com >> [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Gareth Nelson >> Sent: Fri, August 15, 2008 8:38 AM >> To: sldev@lists.secondlife.com >> Subject: [sldev] GPL issues.... >> >> >> It appears that Henri Beauchamp believes the viewer is not licensed >> under the GPL. I have had a lot of corrospondence with him over his >> distribution of binaries without matching source code (he only >> provides patches and a link to the upstream source, the job of merging >> the patches to get the same binary build is left up to the end user). >> >> As far as i'm aware, Nicholaz Beresford also uses this method of >> distribution, but is nowhere near as arrogant about it. However, i'm >> rather concerned by the attitude that it's fine to simply not comply >> with the license if you're otherwise nice to the community. Nicholaz >> seems to be quite an honest individual, while Henri alternates between >> bizarre misunderstandings of the nature of the GPL and the viewer's >> licensing under it and excuses. His latest is that he won't release >> the code because he doesn't have the quota with his ISP, and that >> people may want to recombine his patches in different ways. >> >> The SL viewer is currently in quite a weird situation - it's GPLed, >> but deriviative works casually make it very difficult in some cases to >> modify them via this form of noncompliance and neither LL or any >> contributor seems to act to enforce it. At the same time, the >> trademark issues, artwork and proprietary dependencies (such as vivox >> etc) make it rather less than open. >> >> What's the word on this? Will we see active GPL enforcement from LL? >> Does a contributor want to help out with this? If anyone with a patch >> in the 1.19.0.5 source wants to help out enforcing this please contact >> me. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated >> posting privileges > > From annagulaev at gmail.com Fri Aug 15 10:50:05 2008 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri Aug 15 10:50:08 2008 Subject: [sldev] [VWR] mainland vs estate from map info? Message-ID: Is there any way to determine if a MapBlockReply is for a mainland or estate region, or is it necessary to make a EstateCovenantRequest for each region? Thanks, Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080815/3e1404bf/attachment.htm From schlenk at uni-oldenburg.de Fri Aug 15 14:39:12 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Fri Aug 15 14:40:15 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> Message-ID: Am 15.08.2008 um 14:38 schrieb Gareth Nelson: > It appears that Henri Beauchamp believes the viewer is not licensed > under the GPL. I have had a lot of corrospondence with him over his > distribution of binaries without matching source code (he only > provides patches and a link to the upstream source, the job of merging > the patches to get the same binary build is left up to the end user). > Which is a rather small task compared with setting up a working build environment for the viewer. Just some wget calls and maybe an invocation of patch. > What's the word on this? Will we see active GPL enforcement from LL? > Does a contributor want to help out with this? If anyone with a patch > in the 1.19.0.5 source wants to help out enforcing this please contact > me. I personally would think enforcing the GPL strictly like you advocate it here is mostly silly for this case. Sure you have a marginally valid point that the GPL mandates full source if you distribute binaries. So, the easy solution for most 3rd party viewers would be to just stop distributing binaries and just providing the patch files..., better for ISP quotas, GPL zealots and all people are happy. Sadly this misses the point for most users of those 3rd Party viewers. I doubt 10% of them are capable to compile the viewer themselves, especially if not using GNU Linux where most of the toolchain is easily installed. I agree that strict enforcement is a good thing if your dealing with explicit commercial interest, like the typical router manufacturer using GNU Linux and not publishing full source or any source at all etc. But in this case you mostly annoy people with it for no reason other than GPL fanatism, for a project thats dual licensed anyway. Whats next? Should all patches posted to JIRA be declared GPL only to force Linden labs to fork the commercial and GPL trees? I would understand it if you were personally involved in the 'contributors' list, but at least i cannot find your name in linden/doc/contributions.txt. IANAL but one can read the GPL in a way that Henri complies to the GPL..., he provides the source of his patches, and the source in one place as required by the GPL. You might argue that a link to a different server is not 'in one place' but thats arguable. A patch surely fullfills the GPL clauses about 'standard format' and patch and wget, which you need to get it working is included with Henris OS usually, so not a problem either. He surely is in compliance with the targets of the GPL as stated in the preamble. Michael From mark at identityserver.net Fri Aug 15 15:25:36 2008 From: mark at identityserver.net (Domino Marama) Date: Fri Aug 15 17:05:45 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights In-Reply-To: References: <1218665408.29451.12.camel@domino-laptop> <48A440ED.90707@watson.ibm.com> <1218728378.31336.44.camel@domino-laptop> Message-ID: <1218839136.4634.8.camel@domino-laptop> On Thu, 2008-08-14 at 14:28 -0700, Richard Nelson wrote: > That is correct. Keep in mind that the index is into an "expanded" list > of joints, not just a linear array of the joints as defined in the > skeleton file. In particular, any joint that has more than one child will > have to be repeated in the list for each of its children. Thanks for pointing that out. I took the easy route in coding the list expansion :) Python Code... if llm['hasWeights']: mode = Blender.Mesh.AssignModes.REPLACE jn = { 'hair':['mNeck', 'mHead'], 'head':['mNeck', 'mHead'], 'eyelash':['mHead'], 'upperBody':['mPelvis', 'mTorso','mChest', 'mNeck', 'lowerBody':[ 'mPelvis', 'mHipRight', 'mKneeRight', 'mAnkleRight', 'mPelvis', 'mHipLeft', 'mKneeLeft', 'mAnkleLeft' ], 'skirt':['mTorso', 'mPelvis', 'mPelvis', 'mHipRight', 'mKneeRight', 'mPelvis', 'mHipLeft', 'mKneeLeft' ] }[ name ] cn = { 'hair':['mHead', None], 'head':['mHead', None], 'eyelash':[None], 'upperBody':['mTorso', 'mChest', 'mNeck', None, 'mCollarLeft', 'mShoulderLeft', 'mElbowLeft', 'mWristLeft', None, 'mCollarRight','mShoulderRight', 'mElbowRight', 'mWristRight', None], 'lowerBody':['mHipRight', 'mKneeRight', 'mAnkleRight', None, 'mHipLeft', 'mKneeLeft', 'mAnkleLeft', None ], 'skirt':[ 'mPelvis', None, 'mHipRight', 'mKneeRight', None, 'mHipLeft', 'mKneeLeft', None ] }[name] for j in llm['skinJoints']: mesh.addVertGroup( j ) for i in xrange( len(llm['weights'] )): b, w = llm['weights'][ i ] mesh.assignVertsToGroup( jn[ b - 1 ], [ i ], 1.0 - w, mode ) if cn[b-1] != None: if w != 0.0: mesh.assignVertsToGroup( cn[ b - 1 ], [ i ], w, mode ) From gareth at litesim.com Fri Aug 15 17:40:19 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 15 17:40:20 2008 Subject: Fwd: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808151736y5b46f9d8ic0ab580a9db97e84@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <61dbdd7d0808151736y5b46f9d8ic0ab580a9db97e84@mail.gmail.com> Message-ID: <61dbdd7d0808151740m27ed7384n9c4a2781bc62b5ba@mail.gmail.com> Keep doing this, silly gmail...... ---------- Forwarded message ---------- From: Gareth Nelson Date: Sat, Aug 16, 2008 at 1:36 AM Subject: Re: [sldev] GPL issues.... To: Celierra Darling Downloading each individual patch, decompressing it and applying it. One could code a script to do it, but of course that would be a script "used for compilation and installation" and we shouldn't have to code one seperately On Sat, Aug 16, 2008 at 1:20 AM, Celierra Darling wrote: > On Fri, Aug 15, 2008 at 5:38 AM, Gareth Nelson wrote: >> (he only >> provides patches and a link to the upstream source, the job of merging >> the patches to get the same binary build is left up to the end user). >> > > How much work is left out from what is provided? Is it a relatively > simple matter of applying all the patches en masse (something like > patch -p 0 < cat ../patches/*.patch), or is there a lot of manual > conflict resolution necessary to get something that works, or > something else? > > ~Cel > From danteferret at gmail.com Fri Aug 15 19:33:18 2008 From: danteferret at gmail.com (Dante Tucker) Date: Fri Aug 15 19:33:21 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808151740m27ed7384n9c4a2781bc62b5ba@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <61dbdd7d0808151736y5b46f9d8ic0ab580a9db97e84@mail.gmail.com> <61dbdd7d0808151740m27ed7384n9c4a2781bc62b5ba@mail.gmail.com> Message-ID: <4d211a610808151933p48a95ca4u149af1510bba8d14@mail.gmail.com> Unfortunatly Linden Labs appears to have no issue with the way the viewer is distributed. If you are a contributer you have the legal right to pursue stricter distribution of third party clients. But as it is now no one has a problem with how third party clients are distributed, so there is no reason to change it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080815/16825779/attachment.htm From secret.argent at gmail.com Sat Aug 16 09:32:25 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 16 09:32:10 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808150712i51cf827ema9901e383576dbde@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <000601c8fee0$3ffec610$a400000a@gwsystems2.com> <61dbdd7d0808150712i51cf827ema9901e383576dbde@mail.gmail.com> Message-ID: Have you contacted Nicholaz? He may not realize that he's not in compliance. On 2008-08-15, at 09:12, Gareth Nelson wrote: > He provides only the modified source. This is actually not in > compliance with the GPL, but Nicholaz is a fairly decent guy and i'm > not as concerned by his behaviour. I am concerned with the more > general loose GPL enforcement. From secret.argent at gmail.com Sat Aug 16 09:45:37 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 16 09:45:25 2008 Subject: [sldev] GPL issues.... In-Reply-To: References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> Message-ID: <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> On 2008-08-15, at 16:39, Michael Schlenker wrote: > Sadly this misses the point for most users of those 3rd Party viewers. > I doubt 10% of them are capable to compile the viewer themselves, > especially > if not using GNU Linux where most of the toolchain is easily > installed. It's pretty easy on OS X too. It's only Microsoft who is still trying to make compilers a profit center. > But in this case you mostly annoy people with it for no reason > other than > GPL fanatism, for a project thats dual licensed anyway. Whats next? > Should > all patches posted to JIRA be declared GPL only to force Linden > labs to fork > the commercial and GPL trees? That wouldn't be an issue, LL doesn't accept patches if you don't assign copyright to them. From jacek.antonelli at gmail.com Sat Aug 16 11:16:41 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Sat Aug 16 11:16:43 2008 Subject: [sldev] Git-based viewer source archive Message-ID: <105c09f0808161116r6dcd2d21n69ab73dd79246799@mail.gmail.com> I've set up a Git repository containing the source for every release or release candidate of the viewer since January 2007. It could prove useful for anyone interested in using Git to manage a viewer fork or working copy for patch development. If you're not interested in using Git, you can safely ignore this message. The repository is available online for anyone to clone: http://github.com/jacek/sl-viewer-source-archive/ Git's distributed nature and powerful merging ability mean that you cound clone the archive repository to start your own personal fork, then pull changes to easily keep your working copy up to date without overwriting your changes. If you have an existing Git repository, I believe you could add the archive as a remote repository, then cherry-pick commits from it to get the same effect (albeit somewhat less conveniently). It also serves as a quick way to see what changed from release to release. (I'm sure you can do this with LL's Trac, but it takes more effort there to identify the revisions to compare, etc.) I'll be keeping it up to date with each new release / RC as LL makes the source available. I'd be doing that anyway for my own work, but hopefully by making it a publicly-available resource I can save other people the duplicate effort. - Jacek From robin.cornelius at gmail.com Sat Aug 16 11:27:10 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 16 11:27:16 2008 Subject: [sldev] Git-based viewer source archive In-Reply-To: <105c09f0808161116r6dcd2d21n69ab73dd79246799@mail.gmail.com> References: <105c09f0808161116r6dcd2d21n69ab73dd79246799@mail.gmail.com> Message-ID: <48A71BFE.7000704@gmail.com> Jacek Antonelli wrote: > I've set up a Git repository containing the source for every release > or release candidate of the viewer since January 2007. It could prove > useful for anyone interested in using Git to manage a viewer fork or > working copy for patch development. If you're not interested in using > Git, you can safely ignore this message. hah, i've had a git tree for a few months ;-) http://git.debian.org/git/pkg-games/slviewer.git/ http://git.debian.org/git/pkg-games/slviewer-artwork.git/ What i do on mine is merge in release versions and some RC's with pristine-tar so all upstream are tagged and available as unmodified and the debian packaging is in the Master branch in a debian/ folder But yea git is sweet for this kind of development. I think the Lindens are looking at hg (Mecurial) for a VCS system internally and that is a dynamic distributed system like git and BoS (literately) wrote the book on it. Thanks for the effort though, can never have enough git trees ;-p and a pure tree based on only the official sources will have some advantages as mine would require faffing about but is perfect for debian users trying to build debian packages, but less useful for everyone else. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080816/0ac508bb/signature.pgp From robin.cornelius at gmail.com Sat Aug 16 11:31:03 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 16 11:31:17 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> Message-ID: <48A71CE7.9010001@gmail.com> Argent Stonecutter wrote: > On 2008-08-15, at 16:39, Michael Schlenker wrote: >> But in this case you mostly annoy people with it for no reason other than >> GPL fanatism, for a project thats dual licensed anyway. Whats next? >> Should >> all patches posted to JIRA be declared GPL only to force Linden labs >> to fork >> the commercial and GPL trees? > > That wouldn't be an issue, LL doesn't accept patches if you don't assign > copyright to them. In fact by posting patches to JIRA you are bound my the contribution agreement :- At the top of the JIRA banner :- "All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you've read, understood, and agreed to those terms." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080816/86430d1f/signature-0001.pgp From darien.caldwell at gmail.com Sat Aug 16 12:20:38 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sat Aug 16 12:20:40 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A71CE7.9010001@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> Message-ID: <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> I know i'm going to get dogpiled for saying this, but wouldn't be the first time. :) Sit back and think about what you are saying. You want to sue someone, because you don't want to have to patch the source yourself. Think about the level of ridiculousness in what you are doing. If he wasn't distributing his changes, that's one thing. But this, is truely something else. And the statement that it's okay for Nicholaz to not distribute full sources because he is a 'decent guy', but for Henri, it's not, speaks to your true intentions. From gareth at litesim.com Sat Aug 16 14:15:20 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sat Aug 16 14:15:22 2008 Subject: [sldev] GPL issues.... In-Reply-To: <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> Message-ID: <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> Who said anything about sueing? I wouldn't even have standing to sue, since I haven't got any patches in the viewer (the reason for this by the way is in fact the contributor agreement - otherwise i'd be a hell of a lot more active with viewer development). I also stated that i'm "not as concerned about" Nicholaz since he's a decent guy, not "it's fine for him to violate the license because he's a decent guy". I haven't yet bothered to contact Nicholaz simply because I doubt he'd really respond in the same arrogant manner Henri has. Henri's response was literally to state that the viewer isn't GPLed, but his patches are. If the attitude is that it's fine for him to claim this, then fair enough - I won't bother. However, let that meme get spread around and it'll be a ticking timebomb to more serious violations. On Sat, Aug 16, 2008 at 8:20 PM, Darien Caldwell wrote: > I know i'm going to get dogpiled for saying this, but wouldn't be the > first time. :) > > Sit back and think about what you are saying. You want to sue someone, > because you don't want to have to patch the source yourself. Think > about the level of ridiculousness in what you are doing. If he wasn't > distributing his changes, that's one thing. But this, is truely > something else. > > And the statement that it's okay for Nicholaz to not distribute full > sources because he is a 'decent guy', but for Henri, it's not, speaks > to your true intentions. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From marinekelley at gmail.com Sun Aug 17 00:37:27 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Aug 17 00:37:31 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> Message-ID: <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> In an ideal world, an open-source dev releases their binaries AND the EXACT source code and makefiles to reproduce the EXACT same binary. Why ? Just so the end-user can check that the binaries they downloaded are exactly what is advertised with an MD5 hash or some other signature. It is all too easy to distribute flawed binaries (with a little keylogger here, a short dial home there) and clean source code along with it. Most people tend to think that "this is ok" to download a binary if the provided source code seems clean, but it's like agreeing to buy a house just from the pictures. Unfortunately this is not possible with the SL viewer. Far too clumsy, maintaining a custom viewer over different SL versions is already quite tedious. Some parts of the SL viewer are not even open-source, and a full viewer compressed is 60Mb compared to just 6Mb for just a compressed exe (which is only what the user needs). So try to enforce that and the number of custom viewers around will be dramatically reduced. Only companies would be able to maintain that, and to me it's the contrary of the goal of open-sourcing a product. Marine 2008/8/16 Gareth Nelson > Who said anything about sueing? I wouldn't even have standing to sue, > since I haven't got any patches in the viewer (the reason for this by > the way is in fact the contributor agreement - otherwise i'd be a hell > of a lot more active with viewer development). > > I also stated that i'm "not as concerned about" Nicholaz since he's a > decent guy, not "it's fine for him to violate the license because he's > a decent guy". I haven't yet bothered to contact Nicholaz simply > because I doubt he'd really respond in the same arrogant manner Henri > has. Henri's response was literally to state that the viewer isn't > GPLed, but his patches are. If the attitude is that it's fine for him > to claim this, then fair enough - I won't bother. However, let that > meme get spread around and it'll be a ticking timebomb to more serious > violations. > > On Sat, Aug 16, 2008 at 8:20 PM, Darien Caldwell > wrote: > > I know i'm going to get dogpiled for saying this, but wouldn't be the > > first time. :) > > > > Sit back and think about what you are saying. You want to sue someone, > > because you don't want to have to patch the source yourself. Think > > about the level of ridiculousness in what you are doing. If he wasn't > > distributing his changes, that's one thing. But this, is truely > > something else. > > > > And the statement that it's okay for Nicholaz to not distribute full > > sources because he is a 'decent guy', but for Henri, it's not, speaks > > to your true intentions. > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/20a21911/attachment.htm From gareth at litesim.com Sun Aug 17 01:14:28 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 17 01:14:30 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> Message-ID: <61dbdd7d0808170114j6f636fdy600aa955bc34ce85@mail.gmail.com> [gareth@lovely ~]$ ls -loh ~/slviewer*.tar -rw-r--r-- 1 gareth 110M Mar 29 09:29 /home/gareth/slviewer-linux-libs-Branch_1-19-1-Viewer-r83294.tar -rw-r--r-- 1 gareth 30M Mar 29 09:21 /home/gareth/slviewer-src-Branch_1-19-1-Viewer-r83294.tar This is uncompressed, the 3rd-party libs need not be redistributed (or at least the binary portions need not be) either, only the source tarball. It's perfectly feasible to distribute the source tree. On Sun, Aug 17, 2008 at 8:37 AM, Marine Kelley wrote: > In an ideal world, an open-source dev releases their binaries AND the EXACT > source code and makefiles to reproduce the EXACT same binary. Why ? Just so > the end-user can check that the binaries they downloaded are exactly what is > advertised with an MD5 hash or some other signature. It is all too easy to > distribute flawed binaries (with a little keylogger here, a short dial home > there) and clean source code along with it. Most people tend to think that > "this is ok" to download a binary if the provided source code seems clean, > but it's like agreeing to buy a house just from the pictures. > > Unfortunately this is not possible with the SL viewer. Far too clumsy, > maintaining a custom viewer over different SL versions is already quite > tedious. Some parts of the SL viewer are not even open-source, and a full > viewer compressed is 60Mb compared to just 6Mb for just a compressed exe > (which is only what the user needs). So try to enforce that and the number > of custom viewers around will be dramatically reduced. Only companies would > be able to maintain that, and to me it's the contrary of the goal of > open-sourcing a product. > > Marine > > > > 2008/8/16 Gareth Nelson >> >> Who said anything about sueing? I wouldn't even have standing to sue, >> since I haven't got any patches in the viewer (the reason for this by >> the way is in fact the contributor agreement - otherwise i'd be a hell >> of a lot more active with viewer development). >> >> I also stated that i'm "not as concerned about" Nicholaz since he's a >> decent guy, not "it's fine for him to violate the license because he's >> a decent guy". I haven't yet bothered to contact Nicholaz simply >> because I doubt he'd really respond in the same arrogant manner Henri >> has. Henri's response was literally to state that the viewer isn't >> GPLed, but his patches are. If the attitude is that it's fine for him >> to claim this, then fair enough - I won't bother. However, let that >> meme get spread around and it'll be a ticking timebomb to more serious >> violations. >> >> On Sat, Aug 16, 2008 at 8:20 PM, Darien Caldwell >> wrote: >> > I know i'm going to get dogpiled for saying this, but wouldn't be the >> > first time. :) >> > >> > Sit back and think about what you are saying. You want to sue someone, >> > because you don't want to have to patch the source yourself. Think >> > about the level of ridiculousness in what you are doing. If he wasn't >> > distributing his changes, that's one thing. But this, is truely >> > something else. >> > >> > And the statement that it's okay for Nicholaz to not distribute full >> > sources because he is a 'decent guy', but for Henri, it's not, speaks >> > to your true intentions. >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > From robin.cornelius at gmail.com Sun Aug 17 01:33:48 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Aug 17 01:33:54 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> Message-ID: <48A7E26C.6040201@gmail.com> Marine Kelley wrote: > In an ideal world, an open-source dev releases their binaries AND the > EXACT source code and makefiles to reproduce the EXACT same binary. Why > ? Just so the end-user can check that the binaries they downloaded are > exactly what is advertised with an MD5 hash or some other signature. It > is all too easy to distribute flawed binaries (with a little keylogger > here, a short dial home there) and clean source code along with it. Most > people tend to think that "this is ok" to download a binary if the > provided source code seems clean, but it's like agreeing to buy a house > just from the pictures. > > Unfortunately this is not possible with the SL viewer. Far too clumsy, > maintaining a custom viewer over different SL versions is already quite > tedious. Some parts of the SL viewer are not even open-source, and a > full viewer compressed is 60Mb compared to just 6Mb for just a > compressed exe (which is only what the user needs). So try to enforce > that and the number of custom viewers around will be dramatically > reduced. Only companies would be able to maintain that, and to me it's > the contrary of the goal of open-sourcing a product. I completely disagree, I maintain my git tree in sync with my binary releases. At any given instant i can tarball an exact release version. In fact when i push a binary i automaticly push a debianised source as well and i know for a fact that some of my users pull the source file and build themselves. I also GPG sign the sources and the binaries so it is known that I created it. I maintain patches using a patch management system so its quick and easy to remove,update, add patches to the build and also reference the clean upstream source I could not work the other way around. The problems are caused by the tools used, git, quilt, pristine tar and friends make maintaining multiple custom viewer versions alongside upstream versions simple add in the debian package management tools and it becomes a breeze. I guess windows and visual studio does not really have these tools unless you either use cygwin to use the unix tools or use some clumsy front end to the tool. I also offer FULL downloads of a complete viewer package (minus the non free bits, which i strip in my build process). Oh and BTW i am not a company, i'm just a Debian package maintainer. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/b5ec9ee4/signature.pgp From marinekelley at gmail.com Sun Aug 17 02:10:24 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Aug 17 02:10:28 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A7E26C.6040201@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> Message-ID: <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> I develop and release on Windows, VS2005 and I'm getting it the hard way, thankyouverymuch :p I don't have any patch management system, do not know what git is (yes I know there is a thread about it in the list, didn't take the time to read it yet), nor quilt, pristine tar, nor can manage a debian package to save my life. Yes I work in the IT industry. So here is what I suggest : let all the regular and well-organized Linux developers maintain and release their own "tarballs", and all the other OS devs like me can get stuffed. After all, who needs VS2005 anymore. Maintaining open-source packages like this viewer is for serious people, not for us peons. And about Henri, I do understand his way of working. He wants people to be able to pick the patches they want, especially since most patches on his site are not his own. If he made a monolithic bundle he would be accused of absorbing other people's work, or to at least not be flexible enough. So his way of releasing may not be GPL-compliant (mine isn't either), but it's much more practical. 2008/8/17 Robin Cornelius > Marine Kelley wrote: > > In an ideal world, an open-source dev releases their binaries AND the > > EXACT source code and makefiles to reproduce the EXACT same binary. Why > > ? Just so the end-user can check that the binaries they downloaded are > > exactly what is advertised with an MD5 hash or some other signature. It > > is all too easy to distribute flawed binaries (with a little keylogger > > here, a short dial home there) and clean source code along with it. Most > > people tend to think that "this is ok" to download a binary if the > > provided source code seems clean, but it's like agreeing to buy a house > > just from the pictures. > > > > Unfortunately this is not possible with the SL viewer. Far too clumsy, > > maintaining a custom viewer over different SL versions is already quite > > tedious. Some parts of the SL viewer are not even open-source, and a > > full viewer compressed is 60Mb compared to just 6Mb for just a > > compressed exe (which is only what the user needs). So try to enforce > > that and the number of custom viewers around will be dramatically > > reduced. Only companies would be able to maintain that, and to me it's > > the contrary of the goal of open-sourcing a product. > > I completely disagree, I maintain my git tree in sync with my binary > releases. At any given instant i can tarball an exact release version. > > In fact when i push a binary i automaticly push a debianised source as > well and i know for a fact that some of my users pull the source file > and build themselves. I also GPG sign the sources and the binaries so it > is known that I created it. > > I maintain patches using a patch management system so its quick and easy > to remove,update, add patches to the build and also reference the clean > upstream source > > I could not work the other way around. > > The problems are caused by the tools used, git, quilt, pristine tar and > friends make maintaining multiple custom viewer versions alongside > upstream versions simple add in the debian package management tools and > it becomes a breeze. > > I guess windows and visual studio does not really have these tools > unless you either use cygwin to use the unix tools or use some clumsy > front end to the tool. > > I also offer FULL downloads of a complete viewer package (minus the non > free bits, which i strip in my build process). > > Oh and BTW i am not a company, i'm just a Debian package maintainer. > > > Robin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/e8d26259/attachment-0001.htm From robin.cornelius at gmail.com Sun Aug 17 02:25:10 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Aug 17 02:25:17 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> Message-ID: <48A7EE76.2050509@gmail.com> Marine Kelley wrote: > I develop and release on Windows, VS2005 and I'm getting it the hard > way, thankyouverymuch :p > > I don't have any patch management system, do not know what git is (yes I > know there is a thread about it in the list, didn't take the time to > read it yet), nor quilt, pristine tar, nor can manage a debian package > to save my life. Yes I work in the IT industry. > > So here is what I suggest : let all the regular and well-organized Linux > developers maintain and release their own "tarballs", and all the other > OS devs like me can get stuffed. After all, who needs VS2005 anymore. > Maintaining open-source packages like this viewer is for serious people, > not for us peons. You made a bold statement that only a company could release sources and binarys for multiple versions of the viewer, i simply gave an example of how this was not true. I never said non-linux people get stuffed i just said that its difficult to manage large projects with patches and multiple branches in visual studio alone. Thats why I who also work in the IT industry and has to use VS at work uses these linux tools such as patch and git/svn etc because it makes my life easier and quicker and reduces mistakes therefore increasing my productivity. Geeez people get so upset so quickly on this list. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/c41ee4a2/signature.pgp From gigstaggart at gmail.com Sun Aug 17 04:27:00 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 17 04:27:03 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> Message-ID: <48A80B04.1070007@gmail.com> Marine Kelley wrote: > Maintaining open-source packages like this viewer is for serious people, not > for us peons. If you are going to distribute a binary, then you must distribute the sources that go with it. It's that simple, and it's not a negotiable point. If you don't do it, you are infringing on the copyrights. Whether anyone enforces it or not is up to the copyright holders. There are at least 20 copyright holders on the viewer code base (myself included). Any of them can bring an action. I would like it very much if people complied with the GPL. It's not that difficult. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/57c9a07a/smime.bin From marinekelley at gmail.com Sun Aug 17 04:39:12 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Aug 17 04:39:15 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A80B04.1070007@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> Message-ID: <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> > > > There are at least 20 copyright holders on the viewer code base (myself > included). Any of them can bring an action. > I do not use any patch from anybody else than me. The code I provide is solely mine, and needs to be applied on the vanilla LL codebase only. > > I would like it very much if people complied with the GPL. It's not > that difficult. > For a Windows developer it is much harder than for a Linux developer. Last time I checked at least. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/5e22da30/attachment.htm From schlenk at uni-oldenburg.de Sun Aug 17 04:56:06 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sun Aug 17 04:56:03 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A71CE7.9010001@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> Message-ID: <48A811D6.7030208@uni-oldenburg.de> Robin Cornelius schrieb: > Argent Stonecutter wrote: >> On 2008-08-15, at 16:39, Michael Schlenker wrote: > >>> But in this case you mostly annoy people with it for no reason other than >>> GPL fanatism, for a project thats dual licensed anyway. Whats next? >>> Should >>> all patches posted to JIRA be declared GPL only to force Linden labs >>> to fork >>> the commercial and GPL trees? >> That wouldn't be an issue, LL doesn't accept patches if you don't assign >> copyright to them. > > In fact by posting patches to JIRA you are bound my the contribution > agreement :- > > At the top of the JIRA banner :- > > "All submissions to this site are governed by Second Life Project > Contribution Agreement. By submitting patches and other information > using this site, you acknowledge that you've read, understood, and > agreed to those terms." > Agreed not an issue in the current situation. More a hypothetical threat to setup a parallel infrastructure just to force some fork just for the cause of GPL fanatism. Probably won't happen even if some people might like because it doesn't really work when you control only one side of the protocol and do not have a GPL'ed server. As my stuff gets a BSD/MIT license mostly i don't care anyway. Michael From schlenk at uni-oldenburg.de Sun Aug 17 05:01:06 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sun Aug 17 05:01:02 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A80B04.1070007@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> Message-ID: <48A81302.3020909@uni-oldenburg.de> Jason Giglio schrieb: > Marine Kelley wrote: >> Maintaining open-source packages like this viewer is for serious people, not >> for us peons. > > If you are going to distribute a binary, then you must distribute the > sources that go with it. It's that simple, and it's not a negotiable > point. And wrong. You must provide a way to get the sources, for at most the cost of doing the copy and the actual distribution, you are NOT required to distribute them with your binaries. Just read the GPL again. Distributing the sources together with the binaries is just one way to comply. See http://www.gnu.org/licenses/old-licenses/gpl-2.0.html 3 a-c Michael From secret.argent at gmail.com Sun Aug 17 05:15:20 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 17 05:15:10 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> Message-ID: <2262CBB4-31AA-4CEC-955F-C15CE3DD094D@gmail.com> On 2008-08-17, at 04:10, Marine Kelley wrote: > I don't have any patch management system, do not know what git is > (yes I know there is a thread about it in the list, didn't take the > time to read it yet), nor quilt, pristine tar, nor can manage a > debian package to save my life. Yes I work in the IT industry. You don't need to use GIT, you can use SVN or CVS. I don't know about SVN but there are some good integrated-with-windows-explorer CVS implementations for windows. > So here is what I suggest : let all the regular and well-organized > Linux developers maintain and release their own "tarballs", and all > the other OS devs like me can get stuffed. I'm not sure I understand your point. There are several ZIP tools for windows that can create a ZIP file (the Windows equivalent of a tarball) of your source tree with one right-click. From gigstaggart at gmail.com Sun Aug 17 05:28:29 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 17 05:28:33 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A81302.3020909@uni-oldenburg.de> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> Message-ID: <48A8196D.7080400@gmail.com> Michael Schlenker wrote: > And wrong. > > You must provide a way to get the sources, for at most the cost of doing > the copy and the actual distribution, you are NOT required to distribute > them with your binaries. Just read the GPL again. Distributing the > sources together with the binaries is just one way to comply. I didn't say "with your binaries", I said you must "distribute the code that goes with (i.e. produced) the binary". -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/deac0cde/smime-0001.bin From gareth at litesim.com Sun Aug 17 08:03:14 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 17 08:03:16 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A81302.3020909@uni-oldenburg.de> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> Message-ID: <61dbdd7d0808170803t50bd119aye330913e1569b34e@mail.gmail.com> On Sun, Aug 17, 2008 at 1:01 PM, Michael Schlenker wrote: > Jason Giglio schrieb: >> Marine Kelley wrote: >>> Maintaining open-source packages like this viewer is for serious people, not >>> for us peons. >> >> If you are going to distribute a binary, then you must distribute the >> sources that go with it. It's that simple, and it's not a negotiable >> point. > > And wrong. > > You must provide a way to get the sources, for at most the cost of doing > the copy and the actual distribution, you are NOT required to distribute > them with your binaries. Just read the GPL again. Distributing the > sources together with the binaries is just one way to comply. > > See http://www.gnu.org/licenses/old-licenses/gpl-2.0.html 3 a-c > > > Michael Distributing patches is insufficient: http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient From gareth at litesim.com Sun Aug 17 08:18:04 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 17 08:18:06 2008 Subject: Fwd: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808170817i3fc5ae2cwaa83b4797241a81b@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> <61dbdd7d0808170803t50bd119aye330913e1569b34e@mail.gmail.com> <48A83ED7.30309@uni-oldenburg.de> <61dbdd7d0808170817i3fc5ae2cwaa83b4797241a81b@mail.gmail.com> Message-ID: <61dbdd7d0808170818x354f9bfel97eb74e01fbb36a7@mail.gmail.com> gmail, you anger me! ---------- Forwarded message ---------- From: Gareth Nelson Date: Sun, Aug 17, 2008 at 4:17 PM Subject: Re: [sldev] GPL issues.... To: Michael Schlenker And of course no such written offer is to be found on the 3rd-party viewer download pages which prompted me to start this thread On Sun, Aug 17, 2008 at 4:08 PM, Michael Schlenker wrote: > Gareth Nelson schrieb: >> On Sun, Aug 17, 2008 at 1:01 PM, Michael Schlenker >> wrote: >>> Jason Giglio schrieb: >>>> Marine Kelley wrote: >>>>> Maintaining open-source packages like this viewer is for serious people, not >>>>> for us peons. >>>> If you are going to distribute a binary, then you must distribute the >>>> sources that go with it. It's that simple, and it's not a negotiable >>>> point. >>> And wrong. >>> >>> You must provide a way to get the sources, for at most the cost of doing >>> the copy and the actual distribution, you are NOT required to distribute >>> them with your binaries. Just read the GPL again. Distributing the >>> sources together with the binaries is just one way to comply. >>> >>> See http://www.gnu.org/licenses/old-licenses/gpl-2.0.html 3 a-c >>> >>> >>> Michael >> >> Distributing patches is insufficient: >> http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient > > True. But your not required to publish the full source in a public place > anyway. Its enough to offer to send them on request. > > Michael > From marinekelley at gmail.com Sun Aug 17 10:59:44 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Aug 17 10:59:48 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808170818x354f9bfel97eb74e01fbb36a7@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> <61dbdd7d0808170803t50bd119aye330913e1569b34e@mail.gmail.com> <48A83ED7.30309@uni-oldenburg.de> <61dbdd7d0808170817i3fc5ae2cwaa83b4797241a81b@mail.gmail.com> <61dbdd7d0808170818x354f9bfel97eb74e01fbb36a7@mail.gmail.com> Message-ID: <9e52a8c10808171059o12874798y12f84b467e03ce1e@mail.gmail.com> > > > >> Distributing patches is insufficient: > >> > http://www.gnu.org/licenses/gpl-faq.html#DistributingSourceIsInconvenient > I'm not questioning the GPL or anything, but isn't that a bit clumsy for the dev ? This FAQ says, roughly, that if in one year from now someone wants to download the source code of the present binaries, nothing guarantees me that the website I'm relying on right now will still provide the sources in a year. The way I understand it is this : - I am relying on LL to provide the source code for me when I release a new version of my viewer - This is wrong because nothing tells me that in one year LL will still provide any source code, let alone that particular source code I have used to compile the viewer I am providing now - But in one year, the SL viewer will have changed and improved a bit (I hope), the version of the sources and binaries will be different Does that mean that I have to publish the patched SL source code along with my binaries, keeping all the versions in an repository (SVN or others) ad vitam aeternam ? Or am I allowed to remove the source code for viewers that I do not provide anymore ? Because in the case of the second option, then this does not really impact most custom viewers since as soon as LL stops providing their source code we will stop providing custom viewers (granted, there would be some inertia until SL becomes totally incompatible). In other words, we can rely on LL for the source code because custom viewers will die with it. Not sure if I'm clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/cb7a4711/attachment.htm From gigstaggart at gmail.com Sun Aug 17 11:11:12 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 17 11:11:14 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808171059o12874798y12f84b467e03ce1e@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> <61dbdd7d0808170803t50bd119aye330913e1569b34e@mail.gmail.com> <48A83ED7.30309@uni-oldenburg.de> <61dbdd7d0808170817i3fc5ae2cwaa83b4797241a81b@mail.gmail.com> <61dbdd7d0808170818x354f9bfel97eb74e01fbb36a7@mail.gmail.com> <9e52a8c10808171059o12874798y12f84b467e03ce1e@mail.gmail.com> Message-ID: <48A869C0.70201@gmail.com> Marine Kelley wrote: > Does that mean that I have to publish the patched SL source code along with > my binaries, keeping all the versions in an repository (SVN or others) ad > vitam aeternam ? Or am I allowed to remove the source code for viewers that > I do not provide anymore ? You can remove the source code at the same time you remove the binary, assuming that they were both offered at the same time, and you didn't use the written offer clause that requires the source code to be available for 3 years. > Because in the case of the second option, then this does not really impact > most custom viewers since as soon as LL stops providing their source code we > will stop providing custom viewers (granted, there would be some inertia > until SL becomes totally incompatible). In other words, we can rely on LL > for the source code because custom viewers will die with it. Your logic is flawed because you assume it's OK to violate the GPL by not providing "corresponding" source code to the binaries you distribute in the first place. You can't build on logic that assumes it's OK to violate the GPL. In the case of a modified viewer being distributed, you can't download the corresponding source code from Linden Lab ever. So, no, your logic is completely wrong. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/5d78227b/smime.bin From gigstaggart at gmail.com Sun Aug 17 11:16:06 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 17 11:16:11 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9F88984D-5053-48B8-8EFA-514B2FDAA838@gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> Message-ID: <48A86AE6.7020905@gmail.com> Marine Kelley wrote: >> >> There are at least 20 copyright holders on the viewer code base (myself >> included). Any of them can bring an action. >> > > I do not use any patch from anybody else than me. The code I provide is > solely mine, and needs to be applied on the vanilla LL codebase only. > Sorry to jump backward in the thread, but even the code Linden Lab distributes has multiple copyright claims to it, because the contributor agreement does not remove the rights of the original author to enforce copyright infringement claims. So you could be sued by anyone that has ever had a patch accepted by Linden Lab if you infringe on the copyright by violating the terms of the GPL. I don't think anyone would, but you never know. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080817/1b845cd4/smime-0001.bin From marinekelley at gmail.com Sun Aug 17 11:36:26 2008 From: marinekelley at gmail.com (Marine Kelley) Date: Sun Aug 17 11:36:29 2008 Subject: [sldev] GPL issues.... In-Reply-To: <48A86AE6.7020905@gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A71CE7.9010001@gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> Message-ID: <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> > Sorry to jump backward in the thread, but even the code Linden Lab > distributes has multiple copyright claims to it, because the contributor > agreement does not remove the rights of the original author to enforce > copyright infringement claims. > > So you could be sued by anyone that has ever had a patch accepted by > Linden Lab if you infringe on the copyright by violating the terms of > the GPL. I don't think anyone would, but you never know. > > -Jason > So it is not ok to just publish a 134Kb patch because it could contain some proprietary code coming from open-source contributors such as you (I thought LL had the sole copyright on contributed code), but it is ok to publish the whole 90Mb source code, including said proprietary code and custom code. Minus the proprietary libraries. Did I get that right ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/fa62f23b/attachment.htm From teravus at gmail.com Sun Aug 17 12:32:16 2008 From: teravus at gmail.com (Teravus Ovares) Date: Sun Aug 17 12:32:19 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> Message-ID: <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> We've hit the 5 responses in 24 hours guideline from http://wiki.secondlife.com/wiki/SLDev . In addition, from the start this discussion was against the "If the topic is not specifically a Second Life development-related topic (e.g. mailing list policy or a licensing discussion), it should be redirected to the wiki, the bug tracker, or the appropriate forum immediately." guideline from the start. Any chance that we can take this to a more appropriate forum? Linden Labs has a licensing e-mail specifically to deal with licensing issues. licensing@lindenlab.com Best Regards Teravus On 8/17/08, Marine Kelley wrote: > > > Sorry to jump backward in the thread, but even the code Linden Lab >> distributes has multiple copyright claims to it, because the contributor >> agreement does not remove the rights of the original author to enforce >> copyright infringement claims. >> >> So you could be sued by anyone that has ever had a patch accepted by >> Linden Lab if you infringe on the copyright by violating the terms of >> the GPL. I don't think anyone would, but you never know. >> >> -Jason >> > > > So it is not ok to just publish a 134Kb patch because it could contain some > proprietary code coming from open-source contributors such as you (I thought > LL had the sole copyright on contributed code), but it is ok to publish the > whole 90Mb source code, including said proprietary code and custom code. > Minus the proprietary libraries. Did I get that right ? > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080817/ec758d22/attachment.htm From latifer at streamgrid.net Sun Aug 17 12:49:39 2008 From: latifer at streamgrid.net (Latif Khalifa) Date: Sun Aug 17 12:49:42 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> Message-ID: <5ebce2ec0808171249i6fef531j4e24b83cb1a34fce@mail.gmail.com> > So it is not ok to just publish a 134Kb patch because it could contain some > proprietary code coming from open-source contributors such as you (I thought > LL had the sole copyright on contributed code), but it is ok to publish the > whole 90Mb source code, including said proprietary code and custom code. > Minus the proprietary libraries. Did I get that right ? According to the FAQ its not OK to distribute the binary compiled with that 134Kb patch applied wihtout providing the full source used for building the bin. Publishing patches only is not prohibited in any way. -- L From secret.argent at gmail.com Sun Aug 17 13:48:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 17 13:48:30 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9e52a8c10808171059o12874798y12f84b467e03ce1e@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <48A81302.3020909@uni-oldenburg.de> <61dbdd7d0808170803t50bd119aye330913e1569b34e@mail.gmail.com> <48A83ED7.30309@uni-oldenburg.de> <61dbdd7d0808170817i3fc5ae2cwaa83b4797241a81b@mail.gmail.com> <61dbdd7d0808170818x354f9bfel97eb74e01fbb36a7@mail.gmail.com> <9e52a8c10808171059o12874798y12f84b467e03ce1e@mail.gmail.com> Message-ID: <64A0E215-5FC5-45B7-B282-F5D50D329BA8@gmail.com> On 2008-08-17, at 12:59, Marine Kelley wrote: > Does that mean that I have to publish the patched SL source code > along with my binaries, keeping all the versions in an repository > (SVN or others) ad vitam aeternam ? Yes. > Or am I allowed to remove the source code for viewers that I do not > provide anymore ? No. From gareth at litesim.com Sun Aug 17 19:27:50 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 17 19:27:52 2008 Subject: [sldev] GPL issues.... In-Reply-To: <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> Message-ID: <61dbdd7d0808171927sa1b5b0wbc257d36543ddd45@mail.gmail.com> I really could have had no idea this would turn into such a "hot topic", but for myself i'll take this private. On Sun, Aug 17, 2008 at 8:32 PM, Teravus Ovares wrote: > We've hit the 5 responses in 24 hours guideline from > http://wiki.secondlife.com/wiki/SLDev . > > In addition, from the start this discussion was against the "If the topic is > not specifically a Second Life development-related topic (e.g. mailing list > policy or a licensing discussion), it should be redirected to the wiki, the > bug tracker, or the appropriate forum immediately." guideline from the > start. > > Any chance that we can take this to a more appropriate forum? Linden Labs > has a licensing e-mail specifically to deal with licensing issues. > licensing@lindenlab.com > > Best Regards > > Teravus > > On 8/17/08, Marine Kelley wrote: >>> >>> Sorry to jump backward in the thread, but even the code Linden Lab >>> distributes has multiple copyright claims to it, because the contributor >>> agreement does not remove the rights of the original author to enforce >>> copyright infringement claims. >>> >>> So you could be sued by anyone that has ever had a patch accepted by >>> Linden Lab if you infringe on the copyright by violating the terms of >>> the GPL. I don't think anyone would, but you never know. >>> >>> -Jason >> >> >> So it is not ok to just publish a 134Kb patch because it could contain >> some proprietary code coming from open-source contributors such as you (I >> thought LL had the sole copyright on contributed code), but it is ok to >> publish the whole 90Mb source code, including said proprietary code and >> custom code. Minus the proprietary libraries. Did I get that right ? >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sldev at free.fr Mon Aug 18 13:14:50 2008 From: sldev at free.fr (Henri Beauchamp) Date: Mon Aug 18 13:14:53 2008 Subject: [sldev] GPL issues.... In-Reply-To: <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> Message-ID: <20080818221450.43c9017c.sldev@free.fr> On Sun, 17 Aug 2008 15:32:16 -0400, Teravus Ovares wrote: > We've hit the 5 responses in 24 hours guideline from > http://wiki.secondlife.com/wiki/SLDev . > > In addition, from the start this discussion was against the "If the topic is > not specifically a Second Life development-related topic (e.g. mailing list > policy or a licensing discussion), it should be redirected to the wiki, the > bug tracker, or the appropriate forum immediately." guideline from the > start. > > Any chance that we can take this to a more appropriate forum? Linden Labs > has a licensing e-mail specifically to deal with licensing issues. > licensing@lindenlab.com > > Best Regards > > Teravus Sorry to add to the noise in this list, but seeing as I'm the one being under attack... I will use my "droit de r?ponse" in this unique message. For a start... There is no issue at all ! The Cool SL Viewer and all the alternate viewers I so far saw published are not violating the GPL License in any way. To speak about my own website, where the Cool SL Viewer is hosted, all the sources necessary to build the binaries are available on my website or on websites linked to from my website. The GPL never imposed on anyone that both the sources and the binaries would have to be stored on the very same webserver or on webservers ran/administrated/owned by the same person. The spirit of the GPL is that you must always be able to rebuild the exact same binary as the provided one with the sources made available via the same medium (and here, the medium is Internet via the HTTP protocol). Would I be distributing the viewer on a CD-ROM, then yes, I would have to provide the source tarball as well as the pacthes on it. The GPL does not impose either that you provide the sources in one form or another (you could even provide them on printed paper if you so wish !), so the fact that the sources necessary to rebuild the alternate viewer are provided as a reference sources tarball (provided via a link to the sources archive page of the SL Wiki) and a number of patches to apply to the reference sources is perfectly legit. Should not it be legit, then *ALL* the makers of Linux distributions (including the GPL only ones such as Debian) would be violating the GPL. Why ?... Because when you look into a RPM or DEB sources packages (for example, but the same is true with Gentoo "ebuilds" and other package management systems), you will find a reference sources tarball (the sources as provided by the "upstream", i.e. the author/originator of the software), and a collection of patches (CVE and bug fixes, vendor specific patches, etc) which are applied when the binary is built. So, the fact I do not provide a tarball with the patched sources is in *NO WAY* a violation of the GPL. I'm even providing the "make-SL" script to help people building the viewer with just one command. All they have to do is to download the reference sources and the patches, everything being accessible/linked to on my website, put everything into a single folder, and run "make-SL" in it ! That's no different than downloading a RPM source package, unpacking it (then you find yourself with the original/reference sources tarball and various patches in the /usr/src/rpm/SOURCES directory) and typing the "rpm -bb" command to build the binary (at which point, the reference sources are untared, the patches applied, and the "make" command finally launched to compile the patched sources. I will add to this fact that: 1.- Even if I wanted, I could not provide such sources. My ISP only grants me 100Mb of data space for all my websites (and the Cool SL Viewer's is not the only one !), so my quota would not be enough to hold the 2 to 4 binaries together with the 2 to 4 patched sources tarballs. 2.- The patches may be applied to a number of versions and branches of the viewer, and this is one of the interests of patches, together with the possibility for someone building themselves the viewer, to decide that one or several patches should not be applied (for example if they suspect a patch could be the reason for a bug, or if a given patch does not apply cleanly (without rejects) to a different version or branch than the one I used to build the binary). It is therefore MUCH better to provide individual patches rather than a patched source tree/tarball. 3.- The only reference I make to the GPL on my website relates to my own patches (i.e. I release them under the GPL). The licensing of the SL Viewer itself is not even pure GPL (basically, LL reserves itself the right to branch the GPL viewer and make it a closed source, non-GPL branch). The official viewer licensing is *NOT* my business and it is only one more reason for me to avoid hosting its sources. Now, about Mr Gareth Nelson's behaviour and how "arrogant" I am... He started IMing me in world, not even saying "hello" before right out, in a very iron learned tone (and actually quite arrogant !) saying that I was violating the GPL... After trying to explain him this was not the case and that he got mislead, and seeing how it would not lead anywhere, I demanded that he stopped IMing me, telling him the conversation was over. He did... but only to fill out a GPL violation form and send it via email to everyone he could think about. After a few more emails, where he kept trying to rise futile arguments which I dismantled one after the other, I finally got fed up and added him to my spam filter. Seeing how his emails were not going to buy anything from me, he then posted to this list, while it's not even the right place to discuss about such topics... Would I be only a little paranoid, I'd say that this person is trying to harass me ("why", is the only thing I could not find an answer for, and the only reason why I think he is just being thick). Well, Mr Gareth Nelson, be sure that if you find me "arrogant", I think, on my side, that you are just one of those fanatics that only deserve being ignored. If you don't like the way I am sharing my work, *for free* with the open source community... well, go dance ! Henri. From gareth at litesim.com Mon Aug 18 13:42:07 2008 From: gareth at litesim.com (Gareth Nelson) Date: Mon Aug 18 13:42:10 2008 Subject: [sldev] GPL issues.... In-Reply-To: <20080818221450.43c9017c.sldev@free.fr> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> Message-ID: <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> I will respond once more in public, then if Henri or anyone else objects please take it private: > For a start... There is no issue at all ! > > The Cool SL Viewer and all the alternate viewers I so far saw > published are not violating the GPL License in any way. > > To speak about my own website, where the Cool SL Viewer is hosted, > all the sources necessary to build the binaries are available on my > website or on websites linked to from my website. The "complete corresponding source" is not available from LL, and it is not available from your own site. LL host only the original source code, and you host only the patches. > The GPL never imposed on anyone that both the sources and the binaries > would have to be stored on the very same webserver or on webservers > ran/administrated/owned by the same person. The spirit of the GPL is > that you must always be able to rebuild the exact same binary as the > provided one with the sources made available via the same medium (and > here, the medium is Internet via the HTTP protocol). Would I be > distributing the viewer on a CD-ROM, then yes, I would have to provide > the source tarball as well as the pacthes on it. The GPL does impose that either the source code or a written offer for source code must be provided. You have neither on your site. In fact, i'll ask now - may I have the source tree you used? If you deny this request in public then shame on you. > The GPL does not impose either that you provide the sources in one form > or another (you could even provide them on printed paper if you so > wish !), so the fact that the sources necessary to rebuild the alternate > viewer are provided as a reference sources tarball (provided via a link > to the sources archive page of the SL Wiki) and a number of patches to > apply to the reference sources is perfectly legit. "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." > Should not it be legit, then *ALL* the makers of Linux distributions > (including the GPL only ones such as Debian) would be violating the GPL. > Why ?... > Because when you look into a RPM or DEB sources packages (for example, > but the same is true with Gentoo "ebuilds" and other package management > systems), you will find a reference sources tarball (the sources as > provided by the "upstream", i.e. the author/originator of the software), > and a collection of patches (CVE and bug fixes, vendor specific patches, > etc) which are applied when the binary is built. Gentoo ebuilds provide no binaries, and RPM distros generally also provide SRPMs. Even if they didn't do this, it wouldn't make a difference to this situation as you are not those distros. > So, the fact I do not provide a tarball with the patched sources is in > *NO WAY* a violation of the GPL. I'm even providing the "make-SL" script > to help people building the viewer with just one command. All they have > to do is to download the reference sources and the patches, everything > being accessible/linked to on my website, put everything into a single > folder, and run "make-SL" in it ! Funny enough, I tried your make-SL script and found it deleted some of the viewer source i'd already downloaded. This isn't your fault of course (I should have read it before executing it) but of course the preferred option is to just provide the source tree. May I have it please? > That's no different than downloading a RPM source package, unpacking it > (then you find yourself with the original/reference sources tarball and > various patches in the /usr/src/rpm/SOURCES directory) and typing the > "rpm -bb" command to build the binary (at which point, the reference > sources are untared, the patches applied, and the "make" command finally > launched to compile the patched sources. Again, there's nothing wrong with providing patches for a GPLed work, the problem is distributing the binary with patches alone, rather than the actual source tree. > > I will add to this fact that: > > 1.- Even if I wanted, I could not provide such sources. My ISP only grants > me 100Mb of data space for all my websites (and the Cool SL Viewer's > is not the only one !), so my quota would not be enough to hold the > 2 to 4 binaries together with the 2 to 4 patched sources tarballs. Not mentioning the fact that your ISP quota is not a good enough excuse, I presume you've heard of this site: www.sourceforge.net > 2.- The patches may be applied to a number of versions and branches of > the viewer, and this is one of the interests of patches, together with > the possibility for someone building themselves the viewer, to decide > that one or several patches should not be applied (for example if they > suspect a patch could be the reason for a bug, or if a given patch > does not apply cleanly (without rejects) to a different version or > branch than the one I used to build the binary). > It is therefore MUCH better to provide individual patches rather than > a patched source tree/tarball. Odd, how does one apply the patches in a nonstandard order without getting rejects? But despite this, your legal obligation is to provide source, even if you think your way is better. > 3.- The only reference I make to the GPL on my website relates to my own > patches (i.e. I release them under the GPL). The licensing of the > SL Viewer itself is not even pure GPL (basically, LL reserves itself > the right to branch the GPL viewer and make it a closed source, > non-GPL branch). The official viewer licensing is *NOT* my business > and it is only one more reason for me to avoid hosting its sources. * Copyright (c) 2003-2008, Linden Research, Inc. * * Second Life Viewer Source Code * The source code in this file ("Source Code") is provided by Linden Lab * to you under the terms of the GNU General Public License, version 2.0 * ("GPL"), unless you have obtained a separate licensing agreement * ("Other License"), formally executed by you and Linden Lab. Terms of * the GPL can be found in doc/GPL-license.txt in this distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/gplv2 * * There are special exceptions to the terms and conditions of the GPL as * it is applied to this Source Code. View the full text of the exception * in the file doc/FLOSS-exception.txt in this software distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/flossexception * * By copying, modifying or distributing this software, you acknowledge * that you have read and understood your obligations described above, * and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ "unless you have obtained a separate licensing agreement * ("Other License"), formally executed by you and Linden Lab" Unless you have another license, it's GPLed. If it wasn't GPLed and you didn't have another license, you'd have no right to redistribute or modify it at all. Claiming the viewer isn't GPLed when you surely must have seen this header every time you modified a file is just simply bizarre. > Now, about Mr Gareth Nelson's behaviour and how "arrogant" I am... > > He started IMing me in world, not even saying "hello" before right > out, in a very iron learned tone (and actually quite arrogant !) > saying that I was violating the GPL... I of course can't dispute this without pasting the logs, but suffice to say I was not arrogant in the least and even re-assured you I was trying to give friendly advice, it is you who was being arrogant. > After trying to explain him this was not the case and that he got > mislead, and seeing how it would not lead anywhere, I demanded that he > stopped IMing me, telling him the conversation was over. He did... but > only to fill out a GPL violation form and send it via email to everyone > he could think about. "everyone he could think about" - 2 lindens, the FSF and yourself. Please explain how this is inappropriate in any way? > After a few more emails, where he kept trying to rise futile arguments > which I dismantled one after the other, I finally got fed up and > added him to my spam filter. Your own view of the situation was that the simple argument that "you must provide source code if you distribute a GPLed work" is flawed. That view of course is itself flawed for anyone with even the simplest understanding of the GPL or software licensing in general. > Seeing how his emails were not going to buy anything from me, he then > posted to this list, while it's not even the right place to discuss > about such topics... So, next time should I just post in public first and then in private? I believe it's more decent to contact you in private first, and thus did so with a fairly casual IM before you came up with your weird excuses. If this list of course is the wrong place to discuss licensing issues (as it appears it might be) then I apologise to all reading, though the general idea of mentioning this in public (alongside concerns about this general practice - you just happened to be particularly arrogant in your statements to the effect of "the viewer isn't GPLed" and similar) I believe was proper. > Would I be only a little paranoid, I'd say that this person is > trying to harass me ("why", is the only thing I could not find > an answer for, and the only reason why I think he is just being > thick). No, i've not contacted you in private again as you're well aware, I won't dignify the "thick" insult with a response. > Well, Mr Gareth Nelson, be sure that if you find me "arrogant", > I think, on my side, that you are just one of those fanatics that > only deserve being ignored. If you don't like the way I am sharing > my work, *for free* with the open source community... well, go > dance ! Wow, what a fanatic I am: I actually think people should follow the terms of the license. If you don't want to follow the terms, then don't distribute the code. As for the whole "i'm sharing my work for free so i'm immune from criticism" idea, total nonsense. From chaosstar at gmail.com Tue Aug 19 00:46:17 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Aug 19 00:46:20 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> Message-ID: <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> >From the GPL: 'Accompany it with the complete corresponding machine-readable source code...' 'If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code' Actually Henri, Gareth is right. You need to provide the original sources of the whole application with your patches, (or everything with your changes) in full. Now, I will not make any assumptions about how he approached the matter, but I don't like how this whole thing turned out, not at all. I will leave further thoughts to myself tho. I'm offering to host your viewer and binaries in full on my ftp. I'm also for now extending that offer to all other maintainers of modified viewers that aren't distributing the code in full yet. A central repository will simply make it so only one copy of each LL source release needs to be hosted on the same server for all viewers wishing to store binaries/patches there. >> For a start... There is no issue at all ! >> The Cool SL Viewer and all the alternate viewers I so far saw >> published are not violating the GPL License in any way. > The "complete corresponding source" is not available from LL, and it > is not available from your own site. LL host only the original source > code, and you host only the patches. From nik at terminaldischarge.net Tue Aug 19 01:29:33 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Aug 19 01:29:22 2008 Subject: [sldev] GPL issues.... Message-ID: <12651.195.188.152.16.1219134573.squirrel@webmail.terminaldischarge.net> ---------------------------- Original Message ---------------------------- Subject: Re: [sldev] GPL issues.... From: "Nik Radford" Date: Tue, August 19, 2008 9:29 am To: "Ambrosia" -------------------------------------------------------------------------- Well he doesn't have to supply the full source on the site. Going back to Gareths words about a written request, Henri can just give the complete source code only when asked for by written request. >From the FAQ This is for GPLv2 which is what the viewer is licensed under: What does ?written offer valid for any third party? mean in GPLv2? Does that mean everyone in the world can get the source to any GPL'ed program no matter what? If you choose to provide source through a written offer, then anybody who requests the source from you is entitled to receive it. If you commercially distribute binaries not accompanied with source code, the GPL says you must provide a written offer to distribute the source code later. When users non-commercially redistribute the binaries they received from you, they must pass along a copy of this written offer. This means that people who did not get the binaries directly from you can still receive copies of the source code, along with the written offer. The reason we require the offer to be valid for any third party is so that people who receive the binaries indirectly in that way can order the source code from you. >>From the GPL: > > 'Accompany it with the complete corresponding machine-readable > source code...' > > 'If distribution of executable or object code is made by offering > access to copy from a designated place, then offering equivalent > access to copy the source code from the same place counts as > distribution of the source code' > > Actually Henri, Gareth is right. You need to provide the original > sources of the whole application with your patches, (or everything > with your changes) in full. > > Now, I will not make any assumptions about how he approached the > matter, but I don't like how this whole thing turned out, not at all. > I will leave further thoughts to myself tho. > > I'm offering to host your viewer and binaries in full on my ftp. I'm > also for now extending that offer to all other maintainers of modified > viewers that aren't distributing the code in full yet. A central > repository will simply make it so only one copy of each LL source > release needs to be hosted on the same server for all viewers wishing > to store binaries/patches there. > >>> For a start... There is no issue at all ! > >>> The Cool SL Viewer and all the alternate viewers I so far saw >>> published are not violating the GPL License in any way. > >> The "complete corresponding source" is not available from LL, and it >> is not available from your own site. LL host only the original source >> code, and you host only the patches. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net From nik at terminaldischarge.net Tue Aug 19 01:36:10 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Aug 19 01:35:59 2008 Subject: [sldev] GPL issues.... In-Reply-To: <12651.195.188.152.16.1219134573.squirrel@webmail.terminaldischarge.ne t> References: <12651.195.188.152.16.1219134573.squirrel@webmail.terminaldischarge.net> Message-ID: <18984.195.188.152.16.1219134970.squirrel@webmail.terminaldischarge.net> I just read futher down in the faq.. meh. Stupid license crap. Someone read the FAQ and all of it, and figure out who is right and wrong so we can move on please. http://www.gnu.org/licenses/gpl-faq.htm > > > ---------------------------- Original Message ---------------------------- > Subject: Re: [sldev] GPL issues.... > From: "Nik Radford" > Date: Tue, August 19, 2008 9:29 am > To: "Ambrosia" > -------------------------------------------------------------------------- > > Well he doesn't have to supply the full source on the site. > > Going back to Gareths words about a written request, Henri can just give > the complete source code only when asked for by written request. > >>From the FAQ This is for GPLv2 which is what the viewer is licensed >> under: > > What does ?written offer valid for any third party? mean in GPLv2? Does > that mean everyone in the world can get the source to any GPL'ed program > no matter what? > > If you choose to provide source through a written offer, then anybody > who requests the source from you is entitled to receive it. > > If you commercially distribute binaries not accompanied with source > code, the GPL says you must provide a written offer to distribute the > source code later. When users non-commercially redistribute the > binaries they received from you, they must pass along a copy of this > written offer. This means that people who did not get the binaries > directly from you can still receive copies of the source code, along > with the written offer. > > The reason we require the offer to be valid for any third party is so > that people who receive the binaries indirectly in that way can order > the source code from you. > > > >>>From the GPL: >> >> 'Accompany it with the complete corresponding machine-readable >> source code...' >> >> 'If distribution of executable or object code is made by offering >> access to copy from a designated place, then offering equivalent >> access to copy the source code from the same place counts as >> distribution of the source code' >> >> Actually Henri, Gareth is right. You need to provide the original >> sources of the whole application with your patches, (or everything >> with your changes) in full. >> >> Now, I will not make any assumptions about how he approached the >> matter, but I don From chaosstar at gmail.com Tue Aug 19 01:36:17 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Aug 19 01:36:21 2008 Subject: [sldev] GPL issues.... In-Reply-To: <12651.195.188.152.16.1219134573.squirrel@webmail.terminaldischarge.net> References: <12651.195.188.152.16.1219134573.squirrel@webmail.terminaldischarge.net> Message-ID: <9bb32d430808190136k333a980eg553847d79bc632bd@mail.gmail.com> Well, Henri needs to put a written offer of the source code on his site, but yeah. 'If you want the source code sent to you instead of just grabbing the patches and LL code from that link, send me an e-mail.' That's all that'd be required. Then Gareth would make his request, Henri'd give him the source, and all the other people would happily continue to use the link to the LL homepage to get it instead of writing a letter. Sounds like the best solution to me. On Tue, Aug 19, 2008 at 10:29, Nik Radford wrote: > > > ---------------------------- Original Message ---------------------------- > Subject: Re: [sldev] GPL issues.... > From: "Nik Radford" > Date: Tue, August 19, 2008 9:29 am > To: "Ambrosia" > -------------------------------------------------------------------------- > > Well he doesn't have to supply the full source on the site. > > Going back to Gareths words about a written request, Henri can just give > the complete source code only when asked for by written request. > > >From the FAQ This is for GPLv2 which is what the viewer is licensed under: > > What does "written offer valid for any third party" mean in GPLv2? Does > that mean everyone in the world can get the source to any GPL'ed program > no matter what? > > If you choose to provide source through a written offer, then anybody > who requests the source from you is entitled to receive it. > > If you commercially distribute binaries not accompanied with source > code, the GPL says you must provide a written offer to distribute the > source code later. When users non-commercially redistribute the > binaries they received from you, they must pass along a copy of this > written offer. This means that people who did not get the binaries > directly from you can still receive copies of the source code, along > with the written offer. > > The reason we require the offer to be valid for any third party is so > that people who receive the binaries indirectly in that way can order > the source code from you. > > > >>>From the GPL: >> >> 'Accompany it with the complete corresponding machine-readable >> source code...' >> >> 'If distribution of executable or object code is made by offering >> access to copy from a designated place, then offering equivalent >> access to copy the source code from the same place counts as >> distribution of the source code' >> >> Actually Henri, Gareth is right. You need to provide the original >> sources of the whole application with your patches, (or everything >> with your changes) in full. >> >> Now, I will not make any assumptions about how he approached the >> matter, but I don't like how this whole thing turned out, not at all. >> I will leave further thoughts to myself tho. >> >> I'm offering to host your viewer and binaries in full on my ftp. I'm >> also for now extending that offer to all other maintainers of modified >> viewers that aren't distributing the code in full yet. A central >> repository will simply make it so only one copy of each LL source >> release needs to be hosted on the same server for all viewers wishing >> to store binaries/patches there. >> >>>> For a start... There is no issue at all ! >> >>>> The Cool SL Viewer and all the alternate viewers I so far saw >>>> published are not violating the GPL License in any way. >> >>> The "complete corresponding source" is not available from LL, and it >>> is not available from your own site. LL host only the original source >>> code, and you host only the patches. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > Nik. > > ------------------------------------------ > E-Mail: Nik@Terminaldischarge.net > (We)Blog: http://blog.terminaldischarge.net > > > Nik. > > ------------------------------------------ > E-Mail: Nik@Terminaldischarge.net > (We)Blog: http://blog.terminaldischarge.net > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From nik at terminaldischarge.net Tue Aug 19 01:42:04 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Tue Aug 19 01:41:53 2008 Subject: [sldev] GPL issues.... Message-ID: <24760.195.188.152.16.1219135324.squirrel@webmail.terminaldischarge.net> Agreed. Nik ---------------------------- Original Message ---------------------------- Subject: Re: [sldev] GPL issues.... From: "Ambrosia" Date: Tue, August 19, 2008 9:36 am To: "Nik Radford" Cc: sldev@lists.secondlife.com -------------------------------------------------------------------------- >Well, Henri needs to put a written offer of the source code on his site, but yeah. > 'If you want the source code sent to you instead of just grabbing the patches and LL code from that link, send me an e-mail.' > That's all that'd be required. Then Gareth would make his request, Henri'd give him the source, and all the other people would happily continue to use the link to the LL homepage to get it instead of writing a letter. Sounds like the best solution to me. On Tue, Aug 19, 2008 at 10:29, Nik Radford wrote: >> >> >> ---------------------------- Original Message---------------------------- >> Subject: Re: [sldev] GPL issues.... >> From: "Nik Radford" >> Date: Tue, August 19, 2008 9:29 am >> To: "Ambrosia" >>-------------------------------------------------------------------------- >> >> Well he doesn't have to supply the full source on the site. >> >> Going back to Gareths words about a written request, Henri can just give >> the complete source code only when asked for by written request. >> >>From the FAQ This is for GPLv2 which is what the viewer is licensed under: >> >> What does "written offer valid for any third party" mean in GPLv2? Does >> that mean everyone in the world can get the source to any GPL'ed program >> no matter what? >> >> If you choose to provide source through a written offer, then anybody >> who requests the source from you is entitled to receive it. >> >> If you commercially distribute binaries not accompanied with source >> code, the GPL says you must provide a written offer to distribute the >> source code later. When users non-commercially redistribute the >> binaries they received from you, they must pass along a copy of this >> written offer. This means that people who did not get the binaries >> directly from you can still receive copies of the source code, along >> with the written offer. >> >> The reason we require the offer to be valid for any third party is so >> that people who receive the binaries indirectly in that way can order >> the source code from you. >> >> >> From sldev at free.fr Tue Aug 19 01:45:54 2008 From: sldev at free.fr (Henri Beauchamp) Date: Tue Aug 19 01:45:59 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> Message-ID: <20080819104554.530ed850.sldev@free.fr> On Tue, 19 Aug 2008 09:46:17 +0200, Ambrosia wrote: > From the GPL: > > 'Accompany it with the complete corresponding machine-readable > source code...' Of course, with the "printed paper" sources, I was exaggerating to show how far one could go with the GPL, but nonetheless, printed paper is also machine readable (there are excellent text scanners around)... In some exceptional cases (in some countries with oppressing governements, or where sharing some type of knowledge with foreign countries is forbidden by the Law) it is the only way to share some software sources. An example ?... Take PGP: in the past (before GPG existed), the US Law did forbid the exportation of source code containing high quality cryptographic algorithms (those that the US government could not break...) to the foreign countries... Well, the sources did make their way out... via snail mail and printed paper copies ! I honestly don't remember if PGP was GPL or not, but it's one example where printed paper would definitely be the "preferred form" (as quoted from the GPL). > 'If distribution of executable or object code is made by offering > access to copy from a designated place, then offering equivalent > access to copy the source code from the same place counts as > distribution of the source code' > > Actually Henri, Gareth is right. You need to provide the original > sources of the whole application with your patches, (or everything > with your changes) in full. First, Gareth is wrong by pretending I need to provide the _patched_ sources. Second, I do provide the source tarball in the "same place", as required by the GPL. This 'same place' is Internet, and more accurately, the web. Should I provide the binaries on a CD-ROM, I would have to provide the sources tarball in the "same place" to (i.e. on the CD-ROM). Again, and for the last time, the GPL never imposed that the binary and the code would be held on the same server on Internet ! What would be the use of duplicating the sources on each website providing patches to the viewer, given the sources are already available in two places on Internet (the SL wiki, and LL's SVN Track) ? Taking again the CD-ROM example above, it would be like providing the source tarball in several folders of a single CD-ROM (i.e. providing several copies in the "same place" (the CD-ROM)...). > Now, I will not make any assumptions about how he approached the > matter, but I don't like how this whole thing turned out, not at all. > I will leave further thoughts to myself tho. > > I'm offering to host your viewer and binaries in full on my ftp. That's a very kind offer, but I decline it: I prefer to have full control of my website and not rely on someone's else good will and disponibility. For a start, with my own website I can do anything I want without any restriction (but the total file size quota), such as, for example, retreiving the full statistics for this site. Again, there is *no need* for me to bother providing LL's original tarball. This is my last message on this list about this issue. If you don't agree with it, please take the discussion to the appropriate place. Also, be sure that Linden Lab got an army of lawyers: I don't think they need any "GPL fanatic" such as Gareth to pinpoint and solve by themselves the violations to the license of the viewer. Regards, Henri. From chaosstar at gmail.com Tue Aug 19 01:57:14 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Aug 19 01:57:19 2008 Subject: [sldev] GPL issues.... In-Reply-To: <20080819104554.530ed850.sldev@free.fr> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> <20080819104554.530ed850.sldev@free.fr> Message-ID: <9bb32d430808190157q5274819t5c163943d2caa665@mail.gmail.com> > Again, and for the last time, the GPL never imposed that the binary > and the code would be held on the same server on Internet ! > > Regards, > > Henri. Agreed. >From GPL-FAQ, just noticed: --- 'Can I put the binaries on my Internet server and put the source on a different Internet site? The GPL says you must offer access to copy the source code "from the same place"; that is, next to the binaries. However, if you make arrangements with another site to keep the necessary source code available, and put a link or cross-reference to the source code next to the binaries, we think that qualifies as "from the same place".' --- The only worry they have is that if you don't make arrangements with the other site, it might pull the source while you still provide the binaries. So, should LL remove the appropriate source, simple don't offer the binary anymore (or make their source available elsewhere). Problem solved. From gareth at litesim.com Tue Aug 19 02:02:48 2008 From: gareth at litesim.com (Gareth Nelson) Date: Tue Aug 19 02:02:50 2008 Subject: [sldev] GPL issues.... In-Reply-To: <9bb32d430808190157q5274819t5c163943d2caa665@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> <20080819104554.530ed850.sldev@free.fr> <9bb32d430808190157q5274819t5c163943d2caa665@mail.gmail.com> Message-ID: <61dbdd7d0808190202h732bcd72w4c095bf29f3d9e20@mail.gmail.com> /me sighs (thought people would take the hint about killing this thread) LL don't maintain source for the "cool viewer", only the original unmodified viewer. Where can I get the full source tree for the cool viewer? Henri - please may you send me a copy if it's not available to download without messing around with the patchsets. On Tue, Aug 19, 2008 at 9:57 AM, Ambrosia wrote: >> Again, and for the last time, the GPL never imposed that the binary >> and the code would be held on the same server on Internet ! >> >> Regards, >> >> Henri. > > Agreed. > > >From GPL-FAQ, just noticed: > > --- > > 'Can I put the binaries on my Internet server and put the source on a > different Internet site? > > The GPL says you must offer access to copy the source code "from > the same place"; that is, next to the binaries. However, if you make > arrangements with another site to keep the necessary source code > available, and put a link or cross-reference to the source code next > to the binaries, we think that qualifies as "from the same place".' > > --- > > The only worry they have is that if you don't make arrangements with > the other site, it might pull the source while you still provide the > binaries. > > So, should LL remove the appropriate source, simple don't offer the > binary anymore (or make their source available elsewhere). > > Problem solved. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From Celierra at gmail.com Tue Aug 19 02:49:09 2008 From: Celierra at gmail.com (Celierra Darling) Date: Tue Aug 19 02:49:13 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808190202h732bcd72w4c095bf29f3d9e20@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <61dbdd7d0808181342s2bb6e6bat52015e84a1f593b9@mail.gmail.com> <9bb32d430808190046k76224f3rf3a009e2bd993617@mail.gmail.com> <20080819104554.530ed850.sldev@free.fr> <9bb32d430808190157q5274819t5c163943d2caa665@mail.gmail.com> <61dbdd7d0808190202h732bcd72w4c095bf29f3d9e20@mail.gmail.com> Message-ID: If it's really just a one-line application, perhaps some kind soul could just post the patched sources somewhere (with or without Henri's active involvement), so that there's no practical need to continue this? From jayden.beresford at gmail.com Tue Aug 19 03:11:23 2008 From: jayden.beresford at gmail.com (Sean Heying) Date: Tue Aug 19 03:11:25 2008 Subject: [sldev] GPL issues.... Message-ID: <5756afe60808190311i76e5faa5qed8b9f0cd0991c01@mail.gmail.com> Gareth... please take your fight elsewhere. Anyone who is so deeply associated with Linda Lovell the ageplayer and who is stated as being deeply Aspergers affected is easily spotted as a "dog with a bone". I want my nice SLDev discussions back, not this fight. From loom at loomiverse.net Tue Aug 19 04:23:54 2008 From: loom at loomiverse.net (Loom) Date: Tue Aug 19 04:24:00 2008 Subject: [sldev] GPL issues.... In-Reply-To: <20080818221450.43c9017c.sldev@free.fr> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <835a5b860808161220l78ed1397yabd3fe762543979@mail.gmail.com> <61dbdd7d0808161415qa63a323u8f246ac60f4c8e4e@mail.gmail.com> <9e52a8c10808170037h390582abibcf5d2ce5947c3e3@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> Message-ID: <1219145034.5349.7.camel@dennis-study.lentil> On Mon, 2008-08-18 at 22:14 +0200, Henri Beauchamp wrote: > Would I be only a little paranoid, I'd say that this person is > trying to harass me ("why", is the only thing I could not find > an answer for, and the only reason why I think he is just being > thick). > Maybe it's because LiteSim want to include some of your patches in their client (which they don't provide sources for BTW) but Gareth can't manage to apply them properly. http://www.litesim.com/php/mybb/member.php?action=profile&uid=2 I don't think it should be a requirement that posters to this or any other list disclose their occupation or affiliations before posting, but in this case, it has a bearing on the accusations of breach of GPL. So I am formally requesting (in writing) that the owners of LiteSim Pty Ltd or their representatives supply me with a full copy of the sources for all of the GPL derived works which they offer for download. After all, fair is fair. Loom Kish From gareth at litesim.com Tue Aug 19 04:31:04 2008 From: gareth at litesim.com (Gareth Nelson) Date: Tue Aug 19 04:31:07 2008 Subject: [sldev] GPL issues.... In-Reply-To: <1219145034.5349.7.camel@dennis-study.lentil> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <1219145034.5349.7.camel@dennis-study.lentil> Message-ID: <61dbdd7d0808190431k46c3d447h1970eb367d820ad0@mail.gmail.com> > So I am formally requesting (in writing) that the owners of LiteSim Pty > Ltd or their representatives supply me with a full copy of the sources > for all of the GPL derived works which they offer for download. https://www.litesim.com/code From blindwanderer at gmail.com Tue Aug 19 09:37:57 2008 From: blindwanderer at gmail.com (Strife Onizuka) Date: Tue Aug 19 09:38:02 2008 Subject: [sldev] Avatar Data Files - Formula for bone weights In-Reply-To: <48A440ED.90707@watson.ibm.com> References: <1218665408.29451.12.camel@domino-laptop> <48A440ED.90707@watson.ibm.com> Message-ID: <89ca6da00808190937p308cf8acrcfc0d0df370726e3@mail.gmail.com> So that's what it means, years ago when I wrote my SL mesh reader that was the one part I couldn't figure out... On Thu, Aug 14, 2008 at 9:27 AM, Mike Monkowski wrote: > Ah those tricky Lindens! :-) > > The implementation is in llviewerjointmesh.cpp. It turns out that each > weight actually contains two pieces of information. The number to the left > of the decimal point is the index of the joint and also implicitly indexes > to the following joint. The actual weight is to the right of the decimal > point and interpolates between these two joints. > > I've added this to the wiki page. > > Mike > > > > Domino Marama wrote: > >> Hi, >> >> I'm using the wiki documentation at >> http://wiki.secondlife.com/wiki/Avatar_Appearance to write an import >> script for the avatar into Blender (http://dominodesigns.info) >> >> I'm not sure how the weights in the .llm files are supposed to be used. >> As the weights in the file aren't in the expected 0.0 to 1.0 range, I'm >> assuming there's some math involved, but there's nothing obvious coming >> to mind. >> >> The major part I'm missing is the bone weights, is there some formula I >> should be using to generate these? So far I've done the entire importer >> just from the wiki info and I'd prefer to finish it without needing to >> dive into the client code if possible. >> >> Thanks, >> Domino >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080819/c4185c6d/attachment.htm From loom at loomiverse.net Tue Aug 19 15:37:59 2008 From: loom at loomiverse.net (Loom) Date: Tue Aug 19 15:38:08 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808190431k46c3d447h1970eb367d820ad0@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> <48A7E26C.6040201@gmail.com> <9e52a8c10808170210x59f50a01na026e7a61c93ac7b@mail.gmail.com> <48A80B04.1070007@gmail.com> <9e52a8c10808170439k6fe28c6di64e72fe4c25fa9b6@mail.gmail.com> <48A86AE6.7020905@gmail.com> <9e52a8c10808171136r461630d1ia15c12e5038566b0@mail.gmail.com> <34cc66250808171232s37e70341g207feedc4b755502@mail.gmail.com> <20080818221450.43c9017c.sldev@free.fr> <1219145034.5349.7.camel@dennis-study.lentil> <61dbdd7d0808190431k46c3d447h1970eb367d820ad0@mail.gmail.com> Message-ID: <1219185479.8997.1.camel@dennis-study.lentil> Gareth, that doesn't include the source for the LiteSim custom viewer which is listed on your downloads page https://www.litesim.com/downloads Loom On Tue, 2008-08-19 at 12:31 +0100, Gareth Nelson wrote: > > So I am formally requesting (in writing) that the owners of LiteSim Pty > > Ltd or their representatives supply me with a full copy of the sources > > for all of the GPL derived works which they offer for download. > > https://www.litesim.com/code > From robla at lindenlab.com Tue Aug 19 16:16:45 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Aug 19 16:17:07 2008 Subject: [sldev] GPL issues.... In-Reply-To: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> References: <61dbdd7d0808150538m18e18d1mabbcbf3817a5bc7e@mail.gmail.com> Message-ID: <48AB545D.3050403@lindenlab.com> On 08/15/2008 05:38 AM, Gareth Nelson wrote: > What's the word on this? Will we see active GPL enforcement from LL? > We will actively enforce the GPL. Our legal strategy for doing this is something we'd prefer not to discuss on a public mailing list. As Gigs pointed out, we have a lot of code from third-party contributors. Since contributors retain joint copyright, they retain the right to enforce copyright in their work, though they can't stop us from licensing their contribution (since we also own copyright in it). A licensee who has a valid license from Linden Lab for a given piece of code has a license for all of that code, regardless of whether or not that code was originally contributed to us by a third party. So, people who comply with the GPL attached to Linden Lab-published code don't need to get a separate license from third party contributors. I'm not a lawyer, so I can't say what rights contributors have to pursue those that violate the GPL attached to the source code published by Linden Lab. However, it doesn't seem smart to me to assume Linden Lab is the only party that can pursue you for a GPL violation. Talk to your lawyer. As Teravus pointed out, this isn't the best topic to discuss indefinitely on this mailing list. If you suspect a licensing violation in the future, please send mail to licensing@lindenlab.com. If you feel you have a licensing issue that is of community-wide interest to discuss on this mailing list (including a reply on this thread), please send a note to me first. I'll try to give you guidance on whether or not it is appropriate to raise on this list, and suggest ways of keeping that conversation from dominating the list traffic like this one has. Thanks Rob From robin.cornelius at gmail.com Thu Aug 21 01:00:35 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 21 01:00:38 2008 Subject: [sldev] Open source meeting - Thursday, 2pm PT, call for items In-Reply-To: References: Message-ID: Hi everyone, The usual Thursday routine, Open source meeting - Thursday, 2pm PT (10pm BST/11pm Europe) in Hippotropolis http://slurl.com/secondlife/Hippotropolis/239/28/24 As usual, any items for discussion please add to :- https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda I'm going to add a point about progress on 1.21 release for general discussion so we can also catch up on anyones build issues on the Head of this branch and generally catch up again. See you in Hippotropolis later. Robin From johnniecarling at gmail.com Thu Aug 21 02:33:30 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu Aug 21 02:33:32 2008 Subject: [sldev] -Werror problem in trunk Message-ID: Hey all, With 1.21 on the way i thought it would be a good time to see how this cmake stuff works. The good news: I got trunk to work with cmake 2.4.8 (the 2.6.0 package in Debin sid, and the 2.6.1 from the cmake website both failed when trying to create the tar.bz file) The bad news: gcc is exiting with to many errors because of the -Werror flag. I really have no idea what i'm doing ;) but indra/cmake/00-Common.cmake on line 108 if (${CXX_VERSION} MATCHES "4.3") add_definitions(-Wno-deprecated -Wno-parentheses) endif (${CXX_VERSION} MATCHES "4.3") is failing because Debin sid currently has gcc version 4.3.1 and it doesn't match "4.3" I changed it to 4.3.1 and it worked, but I don't have a clue how to make it match 4.3 and any later version as it should probably be. Other than that, it worked great... and it's gonna be fun to poke at the code in KDevelop. :-) P.S. I used the instructions here http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake From johnniecarling at gmail.com Thu Aug 21 02:54:15 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu Aug 21 02:54:17 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: Message-ID: On 8/21/08, Johnnie Carling wrote: > indra/cmake/00-Common.cmake on line 108 > > if (${CXX_VERSION} MATCHES "4.3") > add_definitions(-Wno-deprecated -Wno-parentheses) > endif (${CXX_VERSION} MATCHES "4.3") > > is failing because Debin sid currently has gcc version 4.3.1 and it doesn't > match "4.3" > > I changed it to 4.3.1 and it worked, but I don't have a clue how to make it > match 4.3 and any later version as it should probably be. oops a quick correction Changing to 4.3.1 did not help... I commented out if (NOT GCC_DISABLE_FATAL_WARNINGS) set(GCC_WARNINGS "${GCC_WARNINGS} -Werror") endif (NOT GCC_DISABLE_FATAL_WARNINGS) on line 177 of indra/cmake/00-Common.cmake to get it to work. I mentioned I don't know what I'm doing didn't I? :) From gigstaggart at gmail.com Thu Aug 21 02:58:35 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 21 02:58:38 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: Message-ID: <48AD3C4B.7090309@gmail.com> Johnnie Carling wrote: > On 8/21/08, Johnnie Carling wrote: > >> indra/cmake/00-Common.cmake on line 108 >> >> if (${CXX_VERSION} MATCHES "4.3") >> add_definitions(-Wno-deprecated -Wno-parentheses) >> endif (${CXX_VERSION} MATCHES "4.3") >> >> is failing because Debin sid currently has gcc version 4.3.1 and it doesn't >> match "4.3" >> >> I changed it to 4.3.1 and it worked, but I don't have a clue how to make it >> match 4.3 and any later version as it should probably be. > I commented out > > if (NOT GCC_DISABLE_FATAL_WARNINGS) > set(GCC_WARNINGS "${GCC_WARNINGS} -Werror") > endif (NOT GCC_DISABLE_FATAL_WARNINGS) > > on line 177 of indra/cmake/00-Common.cmake to get it to work. > You really don't want to do that in the long run. Are you getting the string const correctness warning? -Wno-write-strings -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080821/d0b1ec6b/smime.bin From gareth at litesim.com Thu Aug 21 03:11:04 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Aug 21 03:11:07 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: Message-ID: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Looks like you've got 2 seperate issues here: 1 - the gcc version (which you know the fix for) 2 - "something" generating a warning and thus triggering -Werror to kill the build Find out what that "something" is On Thu, Aug 21, 2008 at 10:54 AM, Johnnie Carling wrote: > On 8/21/08, Johnnie Carling wrote: > >> indra/cmake/00-Common.cmake on line 108 >> >> if (${CXX_VERSION} MATCHES "4.3") >> add_definitions(-Wno-deprecated -Wno-parentheses) >> endif (${CXX_VERSION} MATCHES "4.3") >> >> is failing because Debin sid currently has gcc version 4.3.1 and it doesn't >> match "4.3" >> >> I changed it to 4.3.1 and it worked, but I don't have a clue how to make it >> match 4.3 and any later version as it should probably be. > > > oops a quick correction > > Changing to 4.3.1 did not help... > > I commented out > > if (NOT GCC_DISABLE_FATAL_WARNINGS) > set(GCC_WARNINGS "${GCC_WARNINGS} -Werror") > endif (NOT GCC_DISABLE_FATAL_WARNINGS) > > on line 177 of indra/cmake/00-Common.cmake to get it to work. > > I mentioned I don't know what I'm doing didn't I? :) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From johnniecarling at gmail.com Thu Aug 21 03:52:34 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu Aug 21 03:52:36 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: On 8/21/08, Gareth Nelson wrote: > Looks like you've got 2 seperate issues here: > 1 - the gcc version (which you know the fix for) > 2 - "something" generating a warning and thus triggering -Werror to > kill the build > > Find out what that "something" is OK after a careful look the if (${CXX_VERSION} MATCHES "4.3") statement does work as I can see the flags it sets, so ignore that bit of my post :-) And it's not the string const error, every error is this one... /home/johnnie/projects/secondlife/trunk/indra/llrender/llrender.h:221: error: 'typedef' was ignored in this declaration I'll try the cmake 2.6.2-RC, thanks Robin From chaosstar at gmail.com Thu Aug 21 04:20:22 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Aug 21 04:20:25 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: <9bb32d430808210420n3b9e6ca2j2bf0270eba4187c6@mail.gmail.com> cmake 2.6* is not officially supported by LL in terms of the new build process., AFAIK. But yes, I'm getting the error: 'typedef' was ignored in this declaration messages en masse when building myself. Debian, GCC 4.* On Thu, Aug 21, 2008 at 12:52, Johnnie Carling wrote: > On 8/21/08, Gareth Nelson wrote: >> Looks like you've got 2 seperate issues here: >> 1 - the gcc version (which you know the fix for) >> 2 - "something" generating a warning and thus triggering -Werror to >> kill the build >> >> Find out what that "something" is > > OK after a careful look the if (${CXX_VERSION} MATCHES "4.3") > statement does work as I can see the flags it sets, so ignore that bit > of my post :-) > > And it's not the string const error, every error is this one... > > /home/johnnie/projects/secondlife/trunk/indra/llrender/llrender.h:221: > error: 'typedef' was ignored in this declaration > > > I'll try the cmake 2.6.2-RC, thanks Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robin.cornelius at gmail.com Thu Aug 21 04:46:13 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 21 04:46:16 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: On Thu, Aug 21, 2008 at 11:52 AM, Johnnie Carling wrote: > /home/johnnie/projects/secondlife/trunk/indra/llrender/llrender.h:221: > error: 'typedef' was ignored in this declaration Ah that one, look at the definition of the struct at llrender.h 221; the name of the struct is not in the "correct" place :- typedef struct Vertex { GLfloat v[3]; GLubyte c[4]; GLfloat uv[2]; }; should be :- typedef struct { GLfloat v[3]; GLubyte c[4]; GLfloat uv[2]; } Vertex; gcc 4.3 is a lot more fussy about syntax. That should fix it. Robin From soft at lindenlab.com Thu Aug 21 05:18:16 2008 From: soft at lindenlab.com (Soft) Date: Thu Aug 21 05:18:20 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: On Thu, Aug 21, 2008 at 6:46 AM, Robin Cornelius wrote: > On Thu, Aug 21, 2008 at 11:52 AM, Johnnie Carling > wrote: > >> /home/johnnie/projects/secondlife/trunk/indra/llrender/llrender.h:221: >> error: 'typedef' was ignored in this declaration > > Ah that one, > > look at the definition of the struct at llrender.h 221; > > the name of the struct is not in the "correct" place :- > > typedef struct Vertex > { > GLfloat v[3]; > GLubyte c[4]; > GLfloat uv[2]; > }; > > should be :- > > typedef struct > { > GLfloat v[3]; > GLubyte c[4]; > GLfloat uv[2]; > } Vertex; > > > gcc 4.3 is a lot more fussy about syntax. That should fix it. Thank you on this - I'll pitch a fix directly into trunk/. From gigstaggart at gmail.com Thu Aug 21 08:37:03 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 21 08:37:08 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: <48AD8B9F.2070401@gmail.com> Soft wrote: >> look at the definition of the struct at llrender.h 221; >> >> the name of the struct is not in the "correct" place :- >> >> typedef struct Vertex >> { >> GLfloat v[3]; >> GLubyte c[4]; >> GLfloat uv[2]; >> }; >> >> should be :- >> >> typedef struct >> { >> GLfloat v[3]; >> GLubyte c[4]; >> GLfloat uv[2]; >> } Vertex; >> >> >> gcc 4.3 is a lot more fussy about syntax. That should fix it. Is this actually the right way to go? Isn't the preferred syntax to actually just say "struct Vertex { ... };". -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080821/8cc50917/smime.bin From robin.cornelius at gmail.com Thu Aug 21 08:47:16 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 21 08:47:21 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> <48AD8B9F.2070401@gmail.com> Message-ID: On Thu, Aug 21, 2008 at 4:37 PM, Jason Giglio wrote: > Is this actually the right way to go? Isn't the preferred syntax to > actually just say "struct Vertex { ... };". > I don't think so on a typedef, if you are just declaring a struct then yes, but in this case not. Robin From mana.janus at web.de Thu Aug 21 09:28:29 2008 From: mana.janus at web.de (Mana Janus) Date: Thu Aug 21 09:28:37 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: <48AD8B9F.2070401@gmail.com> References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> <48AD8B9F.2070401@gmail.com> Message-ID: <48AD97AD.6000403@web.de> Jason Giglio wrote: > Soft wrote: > >>> look at the definition of the struct at llrender.h 221; >>> >>> the name of the struct is not in the "correct" place :- >>> >>> typedef struct Vertex >>> { >>> GLfloat v[3]; >>> GLubyte c[4]; >>> GLfloat uv[2]; >>> }; >>> >>> should be :- >>> >>> typedef struct >>> { >>> GLfloat v[3]; >>> GLubyte c[4]; >>> GLfloat uv[2]; >>> } Vertex; >>> >>> >>> gcc 4.3 is a lot more fussy about syntax. That should fix it. >>> > > Is this actually the right way to go? Isn't the preferred syntax to > actually just say "struct Vertex { ... };". > > -Jason > Absolutely, Jason, if you are using C++ only. "typedef struct { ... } Vertex" is the old C way of doing it. In C++ the simple "struct Vertex { ... }" has the exact same effect and should be preferred, when the header is never included from C. After all, you are not doing "typedef class { ... } Name", are you? ;-) Best regards, Mana From soft at lindenlab.com Thu Aug 21 09:38:28 2008 From: soft at lindenlab.com (Soft) Date: Thu Aug 21 09:38:31 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: <48AD8B9F.2070401@gmail.com> References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> <48AD8B9F.2070401@gmail.com> Message-ID: On Thu, Aug 21, 2008 at 10:37 AM, Jason Giglio wrote: > Soft wrote: >>> look at the definition of the struct at llrender.h 221; >>> >>> the name of the struct is not in the "correct" place :- >>> >>> typedef struct Vertex >>> { >>> GLfloat v[3]; >>> GLubyte c[4]; >>> GLfloat uv[2]; >>> }; >>> >>> should be :- >>> >>> typedef struct >>> { >>> GLfloat v[3]; >>> GLubyte c[4]; >>> GLfloat uv[2]; >>> } Vertex; >>> >>> >>> gcc 4.3 is a lot more fussy about syntax. That should fix it. > > Is this actually the right way to go? Isn't the preferred syntax to > actually just say "struct Vertex { ... };". As per the comments - either will work, but Gigs is right. This would be more orthogonal to the rest of our code, so I'll flip it over to this style. From robin.cornelius at gmail.com Thu Aug 21 09:49:29 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Aug 21 09:49:32 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: <48AD97AD.6000403@web.de> References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> <48AD8B9F.2070401@gmail.com> <48AD97AD.6000403@web.de> Message-ID: On Thu, Aug 21, 2008 at 5:28 PM, Mana Janus wrote: Jason >> > > Absolutely, Jason, if you are using C++ only. "typedef struct { ... } > Vertex" is the old C way of doing it. > In C++ the simple "struct Vertex { ... }" has the exact same effect and > should be preferred, when the header is never included from C. > After all, you are not doing "typedef class { ... } Name", are you? ;-) > Now i'm really confused ;-) but would like to understand this fully. Sorry to be stupid here.. Are you saying that simply saying struct Vertex { ... } is all that is needed ? and this is the C++ equivalent of typedef struct { ... } Vertex , which is still valid but deprecated unless the header is to be used as a general purpose header (eg C may use it) and typedef struct Vertex {...} is actually wrong but many compilers accept it but gcc 4.3.1 now rejects it as invalid? Thanks Robin From mana.janus at web.de Thu Aug 21 10:13:11 2008 From: mana.janus at web.de (Mana Janus) Date: Thu Aug 21 10:14:13 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> <48AD8B9F.2070401@gmail.com> <48AD97AD.6000403@web.de> Message-ID: <48ADA227.6020900@web.de> Robin Cornelius wrote: > On Thu, Aug 21, 2008 at 5:28 PM, Mana Janus wrote: > Jason > >> Absolutely, Jason, if you are using C++ only. "typedef struct { ... } >> Vertex" is the old C way of doing it. >> In C++ the simple "struct Vertex { ... }" has the exact same effect and >> should be preferred, when the header is never included from C. >> After all, you are not doing "typedef class { ... } Name", are you? ;-) >> >> > > Now i'm really confused ;-) but would like to understand this fully. > Sorry to be stupid here.. > > Are you saying that simply saying struct Vertex { ... } is all that is needed ? > > and this is the C++ equivalent of typedef struct { ... } Vertex , > which is still valid but deprecated unless the header is to be used as > a general purpose header (eg C may use it) > > and typedef struct Vertex {...} is actually wrong but many compilers > accept it but gcc 4.3.1 now rejects it as invalid? > > Thanks > > Robi Well, in C "struct Vertex" and "Vertex" are two different types. struct Vertex { ... }; // C: defines type "struct Vertex" typedef int Vertex; // C: defines different type "Vertex" This is perfectly legal and meaningful in C. So, if you do not want to write "struct Vertex" each time, you need to use a typedef. In C you could even do: typedef struct Vertex { ... } Vertex; // C: defines two types "struct Vertex" and "Vertex". Now, in C++ "struct Vertex" and "Vertex" are the same type, as "class Vertex2" and "Vertex2" are. So the examples above are illegal in C++, as they define type Vertex twice. The preferred way in C++ is simply: struct Vertex { ... }; // C++: defines both "struct Vertex" and "Vertex" as one type. To be compatible between C and C++, so you can use the header in both, you can use the typedef with a different name after "struct": typedef struct sVertex { ... } Vertex; // C/C++: defines "struct sVertex" and "Vertex" Or, if you don't need the "struct sVertex", you can just drop the name after "struct": typedef struct { ... } Vertex; // C/C++: defines "Vertex" Hope this is not more confusing than it helps. :-) Best regards, Mana From johnniecarling at gmail.com Thu Aug 21 15:58:14 2008 From: johnniecarling at gmail.com (Johnnie Carling) Date: Thu Aug 21 15:58:17 2008 Subject: [sldev] Re: -Werror problem in trunk In-Reply-To: References: <61dbdd7d0808210311u5e055b28q4abfa57cb92bb8e2@mail.gmail.com> Message-ID: On 8/21/08, Robin Cornelius wrote: > gcc 4.3 is a lot more fussy about syntax. That should fix it. That indeed fixed it.. and cmake 2.6.2RC works fine as well. Thanks for the help everyone :-) From fire at eslteacherlink.co.kr Thu Aug 21 16:42:40 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Thu Aug 21 16:42:51 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article Message-ID: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> Hey everyone, So coming this October is software from Japan where you point your webcam at your desk, place a real life special coded cube in the web cam's field of view, and it gets replaced on your screen with an animated character. place another cube on the desk, and you can interact with the Character! Imagine this way of interacting with SL avatars... http://www.pcworld.com/businesscenter/article/148924/augmented_reality_coming_to_your_desktop_soon.html -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/61491402/attachment.htm From gigstaggart at gmail.com Thu Aug 21 17:09:57 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 21 17:10:02 2008 Subject: [sldev] mismatched llviewerwindow? Message-ID: <48AE03D5.2040804@gmail.com> trunk/indra/newview/llviewermenu.cpp:2195: error: ?class LLViewerWindow? has no member named ?lastObjectHit? Looks like llviewerwindow didn't get updated in trunk? -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080821/8a3f9453/smime.bin From aimee at ama-zing.co.uk Thu Aug 21 19:39:41 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Thu Aug 21 19:39:56 2008 Subject: [sldev] [Mac] Info.plist and CrashReporter.nib missing from trunk Message-ID: <94718CCE-0BB3-4EE4-B057-440DF81CD014@ama-zing.co.uk> mac_updater/Info.plist mac_crash_logger/Info.plist mac_crash_logger/CrashReporter.nib/* ... are all missing from trunk. Looks like they should have been moved from newview to the more appropriate locations ... but didn't quite make it :) Aimee. From mumismo at gmail.com Thu Aug 21 22:27:08 2008 From: mumismo at gmail.com (Jordi Polo) Date: Thu Aug 21 22:27:12 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> Message-ID: Know technology BTW. Look for artoolkit on youtube, I guess several similar things can be found, if not, look on google or in scholar.google.com Being special coded makes the recognition easy and fast. The research on that field is in recognize non-coded objects. Anyway, it is a very good idea to use it for real life programs (there is a game on PS3 using it already) On Fri, Aug 22, 2008 at 8:42 AM, Fire in Korea wrote: > Hey everyone, > > So coming this October is software from Japan where you point your webcam > at your desk, place a real life special coded cube in the web cam's field of > view, and it gets replaced on your screen with an animated character. > place another cube on the desk, and you can interact with the Character! > Imagine this way of interacting with SL avatars... > > > > http://www.pcworld.com/businesscenter/article/148924/augmented_reality_coming_to_your_desktop_soon.html > > -- > Paul Preibisch > Creative Director > > B3D Media Labs Ltd. > Seoul, South Korea > Facebook Second Life Link Application: > http://www.facebook.com/applications/Second_Life_Link/10242435556 > Skype: eslteacherlink.com > Second Life Id: Fire Centaur > English Village SLURL: > http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& > > Facebook Groups: > Second Life for Educators: > http://www.f8.facebook.com/group.php?gid=2387164946 > Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/1328fb12/attachment.htm From mrfrans at gmail.com Fri Aug 22 00:15:05 2008 From: mrfrans at gmail.com (Frans) Date: Fri Aug 22 00:15:18 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> Message-ID: <7765f2c60808220015x56a91a83i2b9a6bd22ee23c1b@mail.gmail.com> Here is a on the fly user demo of something similar. http://api.seesmic.com/#/video/wYrbbltV1H/watch And this is a augemented reality game, where you have to walk a guy though maze by moving/rotating cubes on your desk. I have actually played this at a Art exhibit that was focused around Augmented reality. http://www.youtube.com/watch?v=5ks1u0A8xdU On Fri, Aug 22, 2008 at 1:27 AM, Jordi Polo wrote: > > Know technology BTW. > Look for artoolkit on youtube, I guess several similar things can be found, > if not, look on google or in scholar.google.com > > Being special coded makes the recognition easy and fast. The research on > that field is in recognize non-coded objects. > Anyway, it is a very good idea to use it for real life programs (there is a > game on PS3 using it already) > > -- Jeroen Frans Executive Director The Vesuvius Group SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/9d4868e8/attachment.htm From nivardus at gmail.com Fri Aug 22 00:27:41 2008 From: nivardus at gmail.com (Gonta) Date: Fri Aug 22 00:27:43 2008 Subject: [sldev] [VWR] Viewer Performance Issues, CMAKE Builds Message-ID: <71d0a1670808220027p50813cc3j5a275db8e3197ef0@mail.gmail.com> I built the latest public SVN releases of the shadow-draft-2 and trunk viewers with release configuration, (94570 and 94834.) I'm getting absolutely terrible performance out of both, and while that's par for the course with the shadow-draft-2 viewer, I was wondering if anyone else is getting really awful performance out of trunk in comparison to official builds. Whether it's just the release or specific to me. WinXP, using VS2005 Pro FPS 5- compared to 20+ on official, (Sluggish performance all-over) -gonta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/9bec5a68/attachment-0001.htm From chaosstar at gmail.com Fri Aug 22 00:34:06 2008 From: chaosstar at gmail.com (Ambrosia) Date: Fri Aug 22 00:34:09 2008 Subject: [sldev] Tools menu autohiding fix in the 1.21 branch reverted? Message-ID: <9bb32d430808220034n4c533048tf345f015a8442035@mail.gmail.com> Greetings, According to the 1.21 Nightly Build release notes at http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Public_Nightly/1.21 , build 94534 and onward have a fix of Fixed: VWR-6328: Request for "Tools" menu to not auto-hide. However, when looking at the 1.21 build 94834 on the svn, llFloaterTools.cpp clearly has gMenuBarView->setItemVisible(std::string("Tools"), FALSE); gMenuBarView->arrange(); in onClose, lines 815 and 816, and gMenuBarView->setItemVisible(std::string("Tools"), TRUE); gMenuBarView->arrange(); in onOpen, lines 781 and 782. The same goes for llViewerMenu.cpp, gMenuBarView->setItemVisible("Tools", FALSE); gMenuBarView->arrange(); on lines 705 and 706. Did the fix get reverted by accident? There are seemingly no if() conditions that control this behavor, which makes me guess there is no 'do not hide the tools menu' option implemented either. --Chalice Yao From secondloop at gmail.com Fri Aug 22 01:57:58 2008 From: secondloop at gmail.com (second loop) Date: Fri Aug 22 01:58:01 2008 Subject: [sldev] building with cmake Message-ID: <1e0ce1090808220157m162f787i28a238c937a98290@mail.gmail.com> hi, i tried building the maint-render-7 branch tonight, to begin working on updating the umich stereoscopic patches found here: http://jira.secondlife.com/browse/VWR-2972 i was wondering, what does triage mean exactly? i'm using Visual C++ Express 2005, the version which is free for students to download. So I had to change develop.py to recognize that version first. I've attached a patch for that change, but I'm compiling now, so I'm not sure if it compiles yet. also, to get develop.py to work, i had to download and install putty and copy pscp.exe to c:\program files\scp.exe. then, i followed these lovely directions to dl the libs and artwork: http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake#Get_the_source but for some reason cygwin's unzip wouldn't unzip the files. so i used winrar to unzip them, which worked. also, to get develop.py to configure, i had to comment out a few source files which hve apparently been removed from svn. this was a bit disconcerting, and i'm wondering if this is going to cause problems. i attached the CMakeLists.txt.diff file for the llrender directory with the list of the missing source files. oh, i also took out the QUICKTIME_LIBRARY requirement from newview/CMakeLists.txt because i didn't feel like downloading another sdk, but you don't need a patch for that. develop.py gave an error still, which i'm assuming was related to the note about how the expres version doesn't allow you to change some project variables from the command line, but the sln file was still generated and it compiled mostly, but now that it's done compiling, I think there must be a lot missing from the sln file. am I wrong? are there a few settings I can add to get it to compile in VC++Express? Here is the error I'm currently getting, after compiling everything and then compiling again so I only get the output of what isn't working... ------ Build started: Project: copy_win_libs, Configuration: Debug Win32 ------ Copying llkdu.dll C:/src/maint-render-7/indra/build-vc80/newview/RelWithDebInfo Error copying file (if different) from "C:/src/maint-render-7/indra/../libraries/i686-win32/lib/release/llkdu.dll" to "C:/src/maint-render-7/indra/build-vc80/newview/RelWithDebInfo/llkdu.dll". Project : error PRJ0019: A tool returned an error code from "Copying llkdu.dll C:/src/maint-render-7/indra/build-vc80/newview/RelWithDebInfo" Build log was saved at "file://c:\src\maint-render-7\indra\build-vc80\newview\copy_win_libs.dir\Debug\BuildLog.htm" copy_win_libs - 1 error(s), 0 warning(s) ------ Build started: Project: secondlife-bin, Configuration: Debug Win32 ------ Setting the secondlife-bin working directory for debugging. Editing solution: C:/src/maint-render-7/indra/build-vc80/SecondLife.sln Looking for existing VisualStudio instance... Didn't find open solution, starting new background VisualStudio instance... Reading .sln file version... Using version: VC80... Value cannot be null. Parameter name: type Quitting do to error opening: C:\src\maint-render-7\indra\build-vc80\SecondLife.sln Verifying message template master: http://secondlife.com/app/message_template/master_message_template.msg current: C:\src\maint-render-7\scripts\messages\message_template.msg --- PASS --- Same Linking... LINK : fatal error LNK1104: cannot open file 'fmodvc.lib' Build log was saved at "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\Debug\BuildLog.htm" secondlife-bin - 1 error(s), 0 warning(s) ------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: server, Configuration: Debug Win32 ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: viewer, Configuration: Debug Win32 ------ Project not selected to build for this solution configuration ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== thanks, azdel -------------- next part -------------- A non-text attachment was scrubbed... Name: develop.py.vcexpress Type: application/octet-stream Size: 1618 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080822/957dadb2/develop.py.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: CMakeLists.txt.diff Type: application/octet-stream Size: 569 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080822/957dadb2/CMakeLists.txt.obj From sllists at boroon.dasgupta.ch Fri Aug 22 03:16:07 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri Aug 22 03:16:12 2008 Subject: Bug Triages (was: [sldev] building with cmake) In-Reply-To: <1e0ce1090808220157m162f787i28a238c937a98290@mail.gmail.com> References: <1e0ce1090808220157m162f787i28a238c937a98290@mail.gmail.com> Message-ID: <48AE91E7.9080402@boroon.dasgupta.ch> second loop schrieb: > hi, > > i tried building the maint-render-7 branch tonight, to begin working > on updating the umich stereoscopic patches found here: > http://jira.secondlife.com/browse/VWR-2972 > > i was wondering, what does triage mean exactly? > Bug triages are regular held meetings of Lindens and Users to sort and discuss reported bugs (and sometimes feature requests): https://wiki.secondlife.com/wiki/Bug_Triage cheers Boroondas From aimee at ama-zing.co.uk Fri Aug 22 03:28:36 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Fri Aug 22 03:28:53 2008 Subject: [sldev] Tools menu autohiding fix in the 1.21 branch reverted? In-Reply-To: <9bb32d430808220034n4c533048tf345f015a8442035@mail.gmail.com> References: <9bb32d430808220034n4c533048tf345f015a8442035@mail.gmail.com> Message-ID: <6C31705A-BE66-41FB-97FE-4340757B4398@ama-zing.co.uk> I may be wrong on this, but my impression was the nightly builds are built from the internal release branch, so are ahead of the external trunk on SVN? Aimee. On Aug 22, 2008, at 08:34, Ambrosia wrote: > Greetings, > > According to the 1.21 Nightly Build release notes at > http://wiki.secondlife.com/wiki/Release_Notes/ > Second_Life_Public_Nightly/1.21 > , build 94534 and onward have a fix of > > Fixed: VWR-6328: Request for "Tools" menu to not auto-hide. > > However, when looking at the 1.21 build 94834 on the svn, > llFloaterTools.cpp clearly has > > gMenuBarView->setItemVisible(std::string("Tools"), FALSE); > gMenuBarView->arrange(); > > in onClose, lines 815 and 816, and > > gMenuBarView->setItemVisible(std::string("Tools"), TRUE); > gMenuBarView->arrange(); > > in onOpen, lines 781 and 782. > > The same goes for llViewerMenu.cpp, > > gMenuBarView->setItemVisible("Tools", FALSE); > gMenuBarView->arrange(); > > on lines 705 and 706. > > > Did the fix get reverted by accident? There are seemingly no if() > conditions that control this behavor, which makes me guess there is no > 'do not hide the tools menu' option implemented either. > > --Chalice Yao > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From chaosstar at gmail.com Fri Aug 22 04:05:20 2008 From: chaosstar at gmail.com (Ambrosia) Date: Fri Aug 22 04:05:23 2008 Subject: [sldev] Tools menu autohiding fix in the 1.21 branch reverted? In-Reply-To: <6C31705A-BE66-41FB-97FE-4340757B4398@ama-zing.co.uk> References: <9bb32d430808220034n4c533048tf345f015a8442035@mail.gmail.com> <6C31705A-BE66-41FB-97FE-4340757B4398@ama-zing.co.uk> Message-ID: <9bb32d430808220405i48eb2200rbbf25a947f548783@mail.gmail.com> I think the build numbers on the external svn pretty much match the build numbers on the internal nightly branches. That's why you get such huge jumps of build numbers on the svn. 94829 is the latest nightly build mentioned on the release notes page, and the external svn got updated to 94834 today/yesterday. On Fri, Aug 22, 2008 at 12:28, Aimee Walton wrote: > I may be wrong on this, but my impression was the nightly builds are built > from the internal release branch, so are ahead of the external trunk on SVN? > > Aimee. > > On Aug 22, 2008, at 08:34, Ambrosia wrote: > >> Greetings, >> >> According to the 1.21 Nightly Build release notes at >> >> http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Public_Nightly/1.21 >> , build 94534 and onward have a fix of >> >> Fixed: VWR-6328: Request for "Tools" menu to not auto-hide. >> >> However, when looking at the 1.21 build 94834 on the svn, >> llFloaterTools.cpp clearly has >> >> gMenuBarView->setItemVisible(std::string("Tools"), FALSE); >> gMenuBarView->arrange(); >> >> in onClose, lines 815 and 816, and >> >> gMenuBarView->setItemVisible(std::string("Tools"), TRUE); >> gMenuBarView->arrange(); >> >> in onOpen, lines 781 and 782. >> >> The same goes for llViewerMenu.cpp, >> >> gMenuBarView->setItemVisible("Tools", FALSE); >> gMenuBarView->arrange(); >> >> on lines 705 and 706. >> >> >> Did the fix get reverted by accident? There are seemingly no if() >> conditions that control this behavor, which makes me guess there is no >> 'do not hide the tools menu' option implemented either. >> >> --Chalice Yao >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Fri Aug 22 04:49:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 22 04:49:31 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> Message-ID: Damn, I was hoping that this was something that would control an avatar by tracking your movements. I want augmented reality, too, but it's when I'm *not* at my desk that I need it. I'd love to have SL-like nametags hovering over people's heads in my semitransparent digital sunglasses, and even getting people in RL replaced by their avatars... but I don't see anything tied to my desktop as augmented reality. From gareth at litesim.com Fri Aug 22 05:23:03 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 22 05:23:05 2008 Subject: [sldev] RequestTextureDownload cap Message-ID: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> Any sims on either the main grid or beta grid running this? I ask because i've been debugging the HTTP texture fetching code and have it compiling cleanly now, but have nowhere to test it. From jpirkola at gmail.com Fri Aug 22 07:01:35 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Fri Aug 22 07:01:39 2008 Subject: [sldev] realXtend Global inventory tests successful Message-ID: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> FYI ---------- Forwarded message ---------- From: Antti Ilom?ki Date: 2008/8/22 Subject: Global inventory tests successful To: realxtend@googlegroups.com We took another step towards the 3D Internet today, as we managed to transport objects from one site to another. These were just initial tests and only prims were tested, but it's sort of a historical moment. You've all probably already read the story on the realXtend blog, but here's the link: http://realxtend.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "realXtend" group. To post to this group, send email to realxtend@googlegroups.com To unsubscribe from this group, send email to realxtend+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/realxtend?hl=en -~----------~----~----~----~------~----~------~--~--- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/2edb2fae/attachment-0001.htm From gigstaggart at gmail.com Fri Aug 22 07:12:58 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Aug 22 07:13:02 2008 Subject: [sldev] mismatched llviewerwindow? In-Reply-To: <48AE03D5.2040804@gmail.com> References: <48AE03D5.2040804@gmail.com> Message-ID: <48AEC96A.8090707@gmail.com> Jason Giglio wrote: > trunk/indra/newview/llviewermenu.cpp:2195: error: ?class LLViewerWindow? > has no member named ?lastObjectHit? > > Looks like llviewerwindow didn't get updated in trunk? > > -Jason Sorry I think this problem is on my end. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080822/eb9a31be/smime.bin From missannotoole at yahoo.com Fri Aug 22 08:01:47 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri Aug 22 08:01:53 2008 Subject: [sldev] realXtend Global inventory tests successful Message-ID: <895749.67981.qm@web59106.mail.re1.yahoo.com> These people have no license to take content licensed for use in Secondlife as per the Secondlife TOS. Not even a plywood cube is authorized for taking from SL. Linden lab needs to deal with this one way or another even if it means immediate deletion of all accounts that engage in this behavior until such time as a proper content licensing scheme is in place. ----- Original Message ---- From: Jani Pirkola To: Second Life Developer Mailing List Sent: Friday, August 22, 2008 10:01:35 AM Subject: [sldev] realXtend Global inventory tests successful FYI ---------- Forwarded message ---------- From: Antti Ilom?ki Date: 2008/8/22 Subject: Global inventory tests successful To: realxtend@googlegroups.com We took another step towards the 3D Internet today, as we managed to transport objects from one site to another. These were just initial tests and only prims were tested, but it's sort of a historical moment. You've all probably already read the story on the realXtend blog, but here's the link: http://realxtend.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "realXtend" group. To post to this group, send email to realxtend@googlegroups.com To unsubscribe from this group, send email to realxtend+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/realxtend?hl=en -~----------~----~----~----~------~----~------~--~--- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/ad4207a2/attachment.htm From nik at terminaldischarge.net Fri Aug 22 08:04:20 2008 From: nik at terminaldischarge.net (Nik Radford) Date: Fri Aug 22 08:04:04 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <895749.67981.qm@web59106.mail.re1.yahoo.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> Message-ID: <55200.213.106.235.26.1219417460.squirrel@webmail.terminaldischarge.net> I didn't see that it said they had moved an object from SL to RealExtend, just that it moved an object from one site to another. > These people have no license to take content licensed for use in > Secondlife as per the Secondlife TOS. > Not even a plywood cube is authorized for taking from SL. > Linden lab needs to deal with this one way or another even if it means > immediate deletion of all accounts that engage in this behavior until such > time as a proper content licensing scheme is in place. > > > > ----- Original Message ---- > From: Jani Pirkola > To: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 10:01:35 AM > Subject: [sldev] realXtend Global inventory tests successful > > > FYI > > > ---------- Forwarded message ---------- > From: Antti Ilom?ki > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "realXtend" group. > To post to this group, send email to realxtend@googlegroups.com > To unsubscribe from this group, send email to > realxtend+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/realxtend?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges Nik. ------------------------------------------ E-Mail: Nik@Terminaldischarge.net (We)Blog: http://blog.terminaldischarge.net From gareth at litesim.com Fri Aug 22 08:04:20 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 22 08:04:25 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <895749.67981.qm@web59106.mail.re1.yahoo.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> Message-ID: <61dbdd7d0808220804i6e493dd4h8e411137edf11958@mail.gmail.com> > These people have no license to take content licensed for use in Secondlife > as per the Secondlife TOS. That depends on the content of course > Not even a plywood cube is authorized for taking from SL. A plywood cube is not sufficiently creative to get copyright protection, if you could own copyright on a plywood cube then there'd be major issues for all builders > Linden lab needs to deal with this one way or another even if it means > immediate deletion of all accounts that engage in this behavior until such > time as a proper content licensing scheme is in place. That's rather harsh, especially as you don't even know if this test even involved SL at all. From sean at lindenlab.com Fri Aug 22 08:17:37 2008 From: sean at lindenlab.com (Sean Linden) Date: Fri Aug 22 08:17:42 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <895749.67981.qm@web59106.mail.re1.yahoo.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> Message-ID: <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> Errr, you own the stuff you create, so if you make something in SL you can take it with you to another grid. I have no idea how the rights work for anything else, even fullperm objects created by someone else, or any texture not created by you (including the "default" textures like plywood), but anything made by you belongs to you. So you can take the plywood cube if you made it, I'm just not sure you can take the plywood :) On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole wrote: > These people have no license to take content licensed for use in Secondlife > as per the Secondlife TOS. > Not even a plywood cube is authorized for taking from SL. > Linden lab needs to deal with this one way or another even if it means > immediate deletion of all accounts that engage in this behavior until such > time as a proper content licensing scheme is in place. > > ----- Original Message ---- > From: Jani Pirkola > To: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 10:01:35 AM > Subject: [sldev] realXtend Global inventory tests successful > > FYI > > ---------- Forwarded message ---------- > From: Antti Ilom?ki > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "realXtend" group. > To post to this group, send email to realxtend@googlegroups.com > To unsubscribe from this group, send email to > realxtend+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/realxtend?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/ab736896/attachment-0001.htm From missannotoole at yahoo.com Fri Aug 22 08:26:12 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Fri Aug 22 08:26:16 2008 Subject: [sldev] realXtend Global inventory tests successful Message-ID: <447887.90800.qm@web59104.mail.re1.yahoo.com> Sean, last time I checked you are not the Linden Lab General Council so let's hear from the Linden Lab General Council on this before a LL employee causes damage. The problem is there are no mechanisms in place to prevent removal of content from Secondlife that is not licensed to be taken from Secondlife. All that exists is an inadequate c/m/t permissions structure that many of us want changed. So Linden lab needs to step up, hire some more IP lawyer consultants, and set this framework up right. Why do I get upset over this? Because I do not want to see LL/SL get slammed shut by lawyers. Do it right. Do it right up front. Stop trying to be techies and do the code part before requirements. Build the requirements up properly and then build the code to meet the requirements. c/m/t does not cut it. ----- Original Message ---- From: Sean Linden To: Ann Otoole Cc: Second Life Developer Mailing List Sent: Friday, August 22, 2008 11:17:37 AM Subject: Re: [sldev] realXtend Global inventory tests successful Errr, you own the stuff you create, so if you make something in SL you can take it with you to another grid. I have no idea how the rights work for anything else, even fullperm objects created by someone else, or any texture not created by you (including the "default" textures like plywood), but anything made by you belongs to you. So you can take the plywood cube if you made it, I'm just not sure you can take the plywood :) On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole wrote: These people have no license to take content licensed for use in Secondlife as per the Secondlife TOS. Not even a plywood cube is authorized for taking from SL. Linden lab needs to deal with this one way or another even if it means immediate deletion of all accounts that engage in this behavior until such time as a proper content licensing scheme is in place. ----- Original Message ---- From: Jani Pirkola To: Second Life Developer Mailing List Sent: Friday, August 22, 2008 10:01:35 AM Subject: [sldev] realXtend Global inventory tests successful FYI ---------- Forwarded message ---------- From: Antti Ilom?ki Date: 2008/8/22 Subject: Global inventory tests successful To: realxtend@googlegroups.com We took another step towards the 3D Internet today, as we managed to transport objects from one site to another. These were just initial tests and only prims were tested, but it's sort of a historical moment. You've all probably already read the story on the realXtend blog, but here's the link: http://realxtend.blogspot.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "realXtend" group. To post to this group, send email to realxtend@googlegroups.com To unsubscribe from this group, send email to realxtend+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/realxtend?hl=en -~----------~----~----~----~------~----~------~--~--- _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/9626eb83/attachment.htm From robin.cornelius at gmail.com Fri Aug 22 08:48:34 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Aug 22 08:48:37 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> Message-ID: On Fri, Aug 22, 2008 at 4:17 PM, Sean Linden wrote: > Errr, you own the stuff you create, so if you make something in SL you can > take it with you to another grid. I have no idea how the rights work for > anything else, even fullperm objects created by someone else, or any texture > not created by you (including the "default" textures like plywood), but > anything made by you belongs to you. So you can take the plywood cube if you > made it, I'm just not sure you can take the plywood :) > Well currently anything at all you have not created has no license attached so it cannot be assumed to be anything other than no distribution rights. I would say that goes for linden default textures too as although the artwork with the viewer source is licensed nothing that is downloaded when connected has any kind of license so one cannot be assumed. Now what would be good if you could start to attach licenses to asset ID's. Now i know that everyone has there own favorite licenses but there must be a sane finite number you could get to ranging from no permissions to fully permissive, incorporating various Artistic type licenses and options for scripts, various no commercial /allow everything options, to cover a wide range. Then if the license ID is sent with the asset info, its easy to know if you may use that asset (with an appropriate viewer to look at asset id). Yes some one could hack a viewer to ignore this but thats no different to now, what would be different is that content would have a very clear licence and it will be 100% clear if you may reuse this within SL or take it outside, or just do nothing with it etc. Lets not turn this into a security by obscurity discussion this is about licenses. At texture/sound etc upload appropriate license could be selected by content creator. This should even be able to be added to the existing system without breaking anything, just assume ALL existing assets have no license specified and treat this as a special case. May be allow content creators to set the license on existing assets they have rather than re-upload. Robin From sean at lindenlab.com Fri Aug 22 08:51:05 2008 From: sean at lindenlab.com (Sean Linden) Date: Fri Aug 22 08:51:09 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <447887.90800.qm@web59104.mail.re1.yahoo.com> References: <447887.90800.qm@web59104.mail.re1.yahoo.com> Message-ID: <3736d47a0808220851pab460fdrc37c6531bfb4f37b@mail.gmail.com> There are no Linden Lab lawyers on this list that I'm aware of. And the ownership of content in Second Life is already well established; it does not require a lawyer to discuss it. What the permissions mean in the context of multiple grids and what license they imply (if any) is a completely different matter and not one I can discuss. On Fri, Aug 22, 2008 at 8:26 AM, Ann Otoole wrote: > Sean, last time I checked you are not the Linden Lab General Council so > let's hear from the Linden Lab General Council on this before a LL employee > causes damage. > > The problem is there are no mechanisms in place to prevent removal of > content from Secondlife that is not licensed to be taken from Secondlife. > > All that exists is an inadequate c/m/t permissions structure that many of > us want changed. > So Linden lab needs to step up, hire some more IP lawyer consultants, and > set this framework up right. > > Why do I get upset over this? Because I do not want to see LL/SL get > slammed shut by lawyers. > > Do it right. Do it right up front. Stop trying to be techies and do the > code part before requirements. > > Build the requirements up properly and then build the code to meet the > requirements. > > c/m/t does not cut it. > > ----- Original Message ---- > From: Sean Linden > To: Ann Otoole > Cc: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 11:17:37 AM > Subject: Re: [sldev] realXtend Global inventory tests successful > > Errr, you own the stuff you create, so if you make something in SL you can > take it with you to another grid. I have no idea how the rights work for > anything else, even fullperm objects created by someone else, or any texture > not created by you (including the "default" textures like plywood), but > anything made by you belongs to you. So you can take the plywood cube if you > made it, I'm just not sure you can take the plywood :) > > On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole wrote: > >> These people have no license to take content licensed for use in >> Secondlife as per the Secondlife TOS. >> Not even a plywood cube is authorized for taking from SL. >> Linden lab needs to deal with this one way or another even if it means >> immediate deletion of all accounts that engage in this behavior until such >> time as a proper content licensing scheme is in place. >> >> ----- Original Message ---- >> From: Jani Pirkola >> To: Second Life Developer Mailing List >> Sent: Friday, August 22, 2008 10:01:35 AM >> Subject: [sldev] realXtend Global inventory tests successful >> >> FYI >> >> ---------- Forwarded message ---------- >> From: Antti Ilom?ki >> Date: 2008/8/22 >> Subject: Global inventory tests successful >> To: realxtend@googlegroups.com >> >> >> >> We took another step towards the 3D Internet today, as we managed to >> transport objects from one site to another. These were just initial >> tests and only prims were tested, but it's sort of a historical >> moment. >> >> You've all probably already read the story on the realXtend blog, but >> here's the link: http://realxtend.blogspot.com/ >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google Groups >> "realXtend" group. >> To post to this group, send email to realxtend@googlegroups.com >> To unsubscribe from this group, send email to >> realxtend+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/realxtend?hl=en >> -~----------~----~----~----~------~----~------~--~--- >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/ed7c204b/attachment-0001.htm From thordain at thordain.com Fri Aug 22 08:54:55 2008 From: thordain at thordain.com (Thordain Curtis) Date: Fri Aug 22 08:54:58 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <895749.67981.qm@web59106.mail.re1.yahoo.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> Message-ID: If you had bothered to read the article you'd have noticed that they obviously were not copying anything from the LL Grid. Speaking of things that need immediate action, perhaps you should consider reading things immediately prior to criticizing them. On Fri, Aug 22, 2008 at 11:01 AM, Ann Otoole wrote: > These people have no license to take content licensed for use in Secondlife > as per the Secondlife TOS. > Not even a plywood cube is authorized for taking from SL. > Linden lab needs to deal with this one way or another even if it means > immediate deletion of all accounts that engage in this behavior until such > time as a proper content licensing scheme is in place. > > ----- Original Message ---- > From: Jani Pirkola > To: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 10:01:35 AM > Subject: [sldev] realXtend Global inventory tests successful > > FYI > > ---------- Forwarded message ---------- > From: Antti Ilom?ki > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "realXtend" group. > To post to this group, send email to realxtend@googlegroups.com > To unsubscribe from this group, send email to > realxtend+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/realxtend?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/9d07c775/attachment.htm From sean at lindenlab.com Fri Aug 22 09:14:46 2008 From: sean at lindenlab.com (Sean Linden) Date: Fri Aug 22 09:14:49 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> Message-ID: <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> On Fri, Aug 22, 2008 at 8:48 AM, Robin Cornelius wrote: > > Well currently anything at all you have not created has no license > attached so it cannot be assumed to be anything other than no > distribution rights. I would say that goes for linden default textures > too as although the artwork with the viewer source is licensed nothing > that is downloaded when connected has any kind of license so one > cannot be assumed. > > Now what would be good if you could start to attach licenses to asset > ID's. Now i know that everyone has there own favorite licenses but > there must be a sane finite number you could get to ranging from no > permissions to fully permissive, incorporating various Artistic type > licenses and options for scripts, various no commercial /allow > everything options, to cover a wide range. Then if the license ID is > sent with the asset info, its easy to know if you may use that asset > (with an appropriate viewer to look at asset id). > > Yes some one could hack a viewer to ignore this but thats no different > to now, what would be different is that content would have a very > clear licence and it will be 100% clear if you may reuse this within > SL or take it outside, or just do nothing with it etc. Lets not turn > this into a security by obscurity discussion this is about licenses. > > At texture/sound etc upload appropriate license could be selected by > content creator. > > This should even be able to be added to the existing system without > breaking anything, just assume ALL existing assets have no license > specified and treat this as a special case. May be allow content > creators to set the license on existing assets they have rather than > re-upload. > This sounds really interesting to me, Robin. Right now changing any metadata associated with an asset requires creating a new asset, so it would be impossible to change the license on something you've already distributed after the fact, but this is not necessarily a bad thing for stuff you've already applied a license to. It may, however, be useful to be able to apply a license to something that has no license. This would be kind of difficult to implement, however, because the current system assumes assets are immutable. People have talked about different ways to handle asset metadata but the most "obvious" way to do that is with a separate metadata file since it would require a different format for each asset type to embed the metadata (and I'm not even sure you could for, say, sounds), but the asset system doesn't like lots of little files (it has a large block size) and we have ~2 billion assets. Not that they'd all get metadata applied. Then, if you make that file mutable, you're either dealing with locks or just doing best-effort attempts to make sure updates don't clobber one another. Actually, come to think of it, the asset servers probably support a way to say "update this file but only if its old content is still x". -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/f5a36a8f/attachment.htm From gareth at litesim.com Fri Aug 22 09:21:50 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 22 09:21:53 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> Message-ID: <61dbdd7d0808220921y1bd7f138p71308e70814399fc@mail.gmail.com> Surely the permissions flags constitute a form of license? Aside from this, what's wrong with a new "transfer to other grids" flag? On Fri, Aug 22, 2008 at 5:14 PM, Sean Linden wrote: > On Fri, Aug 22, 2008 at 8:48 AM, Robin Cornelius > wrote: >> >> Well currently anything at all you have not created has no license >> attached so it cannot be assumed to be anything other than no >> distribution rights. I would say that goes for linden default textures >> too as although the artwork with the viewer source is licensed nothing >> that is downloaded when connected has any kind of license so one >> cannot be assumed. >> >> Now what would be good if you could start to attach licenses to asset >> ID's. Now i know that everyone has there own favorite licenses but >> there must be a sane finite number you could get to ranging from no >> permissions to fully permissive, incorporating various Artistic type >> licenses and options for scripts, various no commercial /allow >> everything options, to cover a wide range. Then if the license ID is >> sent with the asset info, its easy to know if you may use that asset >> (with an appropriate viewer to look at asset id). >> >> Yes some one could hack a viewer to ignore this but thats no different >> to now, what would be different is that content would have a very >> clear licence and it will be 100% clear if you may reuse this within >> SL or take it outside, or just do nothing with it etc. Lets not turn >> this into a security by obscurity discussion this is about licenses. >> >> At texture/sound etc upload appropriate license could be selected by >> content creator. >> >> This should even be able to be added to the existing system without >> breaking anything, just assume ALL existing assets have no license >> specified and treat this as a special case. May be allow content >> creators to set the license on existing assets they have rather than >> re-upload. > > This sounds really interesting to me, Robin. Right now changing any metadata > associated with an asset requires creating a new asset, so it would be > impossible to change the license on something you've already distributed > after the fact, but this is not necessarily a bad thing for stuff you've > already applied a license to. It may, however, be useful to be able to apply > a license to something that has no license. This would be kind of difficult > to implement, however, because the current system assumes assets are > immutable. > > People have talked about different ways to handle asset metadata but the > most "obvious" way to do that is with a separate metadata file since it > would require a different format for each asset type to embed the metadata > (and I'm not even sure you could for, say, sounds), but the asset system > doesn't like lots of little files (it has a large block size) and we have ~2 > billion assets. Not that they'd all get metadata applied. Then, if you make > that file mutable, you're either dealing with locks or just doing > best-effort attempts to make sure updates don't clobber one another. > Actually, come to think of it, the asset servers probably support a way to > say "update this file but only if its old content is still x". > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From soft at lindenlab.com Fri Aug 22 10:47:41 2008 From: soft at lindenlab.com (Soft) Date: Fri Aug 22 10:47:44 2008 Subject: [sldev] [Mac] Info.plist and CrashReporter.nib missing from trunk In-Reply-To: <94718CCE-0BB3-4EE4-B057-440DF81CD014@ama-zing.co.uk> References: <94718CCE-0BB3-4EE4-B057-440DF81CD014@ama-zing.co.uk> Message-ID: Thanks, Aimee - I'll look into this for the 1.21 and trunk/ drops On Thu, Aug 21, 2008 at 9:39 PM, Aimee Walton wrote: > mac_updater/Info.plist > mac_crash_logger/Info.plist > mac_crash_logger/CrashReporter.nib/* > > ... are all missing from trunk. Looks like they should have been moved from > newview to the more appropriate locations ... but didn't quite make it :) > > Aimee. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robla at lindenlab.com Fri Aug 22 11:12:03 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Aug 22 11:12:29 2008 Subject: [sldev] "What does triage mean exactly?" (Re: building with cmake) In-Reply-To: <1e0ce1090808220157m162f787i28a238c937a98290@mail.gmail.com> References: <1e0ce1090808220157m162f787i28a238c937a98290@mail.gmail.com> Message-ID: <48AF0173.3010401@lindenlab.com> On 8/22/08 1:57 AM, second loop wrote: > i tried building the maint-render-7 branch tonight, to begin working > on updating the umich stereoscopic patches found here: > http://jira.secondlife.com/browse/VWR-2972 > > i was wondering, what does triage mean exactly? > I'm going to zero in on this part of your question and retitle, since this could result in a pretty big tangent. I'm assuming you're referring to that "Last triaged" field that keeps getting touched. When dealing with a huge list of bugs, a typical function in any project/company/whatever is to have a triage meeting to decide priorities of issues. The metaphor is borrowed from the medical field, and the (literally) gory details are here: http://en.wikipedia.org/wiki/Triage The field was originally put there to flag when issues were discussed in one of the public bug triage meetings here: https://wiki.secondlife.com/wiki/Bug_triage What we've been using this for lately is "when was the last time Lindens got together and talked about this issue?". We try to comment and be as helpful as we can, but we're often trying to deal with dozens of issues in a single meeting, so often you'll see us bump the date without comment. If you see one of us do that, and wonder what we discussed, feel free to IM the person who did that in-world. No guarantees we'll have anything useful to say about it, but we're more inclined to respond if we know that someone is interested. Rob From TammyNowotny at mac.com Fri Aug 22 11:34:22 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Fri Aug 22 11:34:44 2008 Subject: [sldev] realXtend Global inventory tests successful Message-ID: <48AF06AE.9050307@mac.com> Sean Linden wrote: > There are no Linden Lab lawyers on this list that I'm aware of. And > the ownership of content in Second Life is already well established; > it does not require a lawyer to discuss it. What the permissions mean > in the context of multiple grids and what license they imply (if any) > is a completely different matter and not one I can discuss. > I am not a lawyer, I don't even play one on TV. My understanding of the fine print is that I own the rights to anything I create in Second Life, which includes the right to export it outside SL, including to other SL-like grids. Also, if I make content available in SL, I am giving Linden Lab the right to use it in-world as part of the enviromnet which anyone can see... for example, I have to let them make my textures available to anyone who flies within sight of them. Where it does get a little tricky is when someone tries to take it to another grid. But there definitely ARE legitimate reasons for moving content from one grid to another, and I think Ann's suggestion (i.e., as I understand it at least, she wants LL to banish anyone who even tries to do such a thing) is unwise. And I also would be shocked to learn that such behavior is a violation of my existing agrrements with LL. From noemail at landbot.info Fri Aug 22 12:01:41 2008 From: noemail at landbot.info (Noemail) Date: Fri Aug 22 12:02:08 2008 Subject: Gpl was Re: [sldev] realXtend Global inventory tests successful In-Reply-To: <447887.90800.qm@web59104.mail.re1.yahoo.com> References: <447887.90800.qm@web59104.mail.re1.yahoo.com> Message-ID: <261A9F77-DAAE-48DC-A8DE-6EC7A37673F0@landbot.info> Plywood cubes r covered under the gpl iirc afaik On Aug 22, 2008, at 11:26 AM, Ann Otoole wrote: > Sean, last time I checked you are not the Linden Lab General Council > so let's hear from the Linden Lab General Council on this before a > LL employee causes damage. > > The problem is there are no mechanisms in place to prevent removal > of content from Secondlife that is not licensed to be taken from > Secondlife. > > All that exists is an inadequate c/m/t permissions structure that > many of us want changed. > So Linden lab needs to step up, hire some more IP lawyer > consultants, and set this framework up right. > > Why do I get upset over this? Because I do not want to see LL/SL get > slammed shut by lawyers. > > Do it right. Do it right up front. Stop trying to be techies and do > the code part before requirements. > > Build the requirements up properly and then build the code to meet > the requirements. > > c/m/t does not cut it. > > ----- Original Message ---- > From: Sean Linden > To: Ann Otoole > Cc: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 11:17:37 AM > Subject: Re: [sldev] realXtend Global inventory tests successful > > Errr, you own the stuff you create, so if you make something in SL > you can take it with you to another grid. I have no idea how the > rights work for anything else, even fullperm objects created by > someone else, or any texture not created by you (including the > "default" textures like plywood), but anything made by you belongs > to you. So you can take the plywood cube if you made it, I'm just > not sure you can take the plywood :) > > On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole > wrote: > These people have no license to take content licensed for use in > Secondlife as per the Secondlife TOS. > Not even a plywood cube is authorized for taking from SL. > Linden lab needs to deal with this one way or another even if it > means immediate deletion of all accounts that engage in this > behavior until such time as a proper content licensing scheme is in > place. > > ----- Original Message ---- > From: Jani Pirkola > To: Second Life Developer Mailing List > Sent: Friday, August 22, 2008 10:01:35 AM > Subject: [sldev] realXtend Global inventory tests successful > > FYI > > ---------- Forwarded message ---------- > From: Antti Ilom?ki > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "realXtend" group. > To post to this group, send email to realxtend@googlegroups.com > To unsubscribe from this group, send email to realxtend+unsubscribe@googlegroups.com > For more options, visit this group at http://groups.google.com/group/realxtend?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/efdf5479/attachment.htm From ramzi at lindenlab.com Fri Aug 22 12:52:55 2008 From: ramzi at lindenlab.com (Ramzi) Date: Fri Aug 22 12:53:02 2008 Subject: [sldev] Tools menu autohiding fix in the 1.21 branch reverted? In-Reply-To: <9bb32d430808220405i48eb2200rbbf25a947f548783@mail.gmail.com> References: <9bb32d430808220034n4c533048tf345f015a8442035@mail.gmail.com><6C31705A-BE66-41FB-97FE-4340757B4398@ama-zing.co.uk> <9bb32d430808220405i48eb2200rbbf25a947f548783@mail.gmail.com> Message-ID: <48AF1917.5050208@lindenlab.com> Aimee is correct here-- the Public Nightly viewers are being built from an internal side-branch. Thus, some public bugs are fixed in the side branch, outside the trunk. We try to address all the regressions, plus stabilize the viewer's crash performance, in a side branch before propagating the fixes back to the trunk. In this case, the fix for VWR-6328 is in the internal branch for now, and is still waiting to be verified A-OK by our Quality team, before it's allowed to propagate back to the trunk. PS: are you interested in receiving these Public Nightly builds? We have a small group of amazing residents who are helping to test them; usually about 2 builds per week. This is in direct response to Residents who asked us to implement a more standard "beta" cycle before nominating a "Release Candidate". We're making progress there, and the group has already identified some 10 gnarly bugs that no one else will ever have to see in RC0. If you'd like to join the effort, there is more info at https://wiki.secondlife.com/wiki/Public_Nightly ! best! Ramzi Ambrosia wrote: > I think the build numbers on the external svn pretty much match the > build numbers on the internal nightly branches. That's why you get > such huge jumps of build numbers on the svn. > > 94829 is the latest nightly build mentioned on the release notes page, > and the external svn got updated to 94834 today/yesterday. > > On Fri, Aug 22, 2008 at 12:28, Aimee Walton wrote: > >> I may be wrong on this, but my impression was the nightly builds are built >> from the internal release branch, so are ahead of the external trunk on SVN? >> >> Aimee. >> >> On Aug 22, 2008, at 08:34, Ambrosia wrote: >> >> >>> Greetings, >>> >>> According to the 1.21 Nightly Build release notes at >>> >>> http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Public_Nightly/1.21 >>> , build 94534 and onward have a fix of >>> >>> Fixed: VWR-6328: Request for "Tools" menu to not auto-hide. >>> >>> However, when looking at the 1.21 build 94834 on the svn, >>> llFloaterTools.cpp clearly has >>> >>> gMenuBarView->setItemVisible(std::string("Tools"), FALSE); >>> gMenuBarView->arrange(); >>> >>> in onClose, lines 815 and 816, and >>> >>> gMenuBarView->setItemVisible(std::string("Tools"), TRUE); >>> gMenuBarView->arrange(); >>> >>> in onOpen, lines 781 and 782. >>> >>> The same goes for llViewerMenu.cpp, >>> >>> gMenuBarView->setItemVisible("Tools", FALSE); >>> gMenuBarView->arrange(); >>> >>> on lines 705 and 706. >>> >>> >>> Did the fix get reverted by accident? There are seemingly no if() >>> conditions that control this behavor, which makes me guess there is no >>> 'do not hide the tools menu' option implemented either. >>> >>> --Chalice Yao >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- Ramzi Ramey ramzi@lindenlab.com :: www.secondlife.com Linden Lab :: 415.243.9000 x7321 -- From secondloop at gmail.com Fri Aug 22 14:16:29 2008 From: secondloop at gmail.com (azdel slade) Date: Fri Aug 22 14:16:34 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> Message-ID: <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> Sean is right here. This is how copyright works IRL. If you create an artwork, say a photograph, you own the copyright, even if you haven't legally filed it yet. And you should be upset, because if we don't get interoperability between grids, then we can be sure that the future of the metaverse will be as short lived as any corporation, in this case linden labs. I am very much looking forward to being able to move inventory between grids and having it work. All this draconian IP control that people are demanding is so 18th century. Get with it folks. If you can see it in SL, then it's already in memory on your machine and people will do what they want with it. Its inevitable. Of all places, SL is a wonderful place to find new models beyond copy restriction. The last thing I want is the SLAA to replace the RIAA, so stop asking for it, please. If you want to see SL continue to grow (and exist) than we need working interoperability between grids. Of all places, the open source developer's list should understand this. azdel On Fri, Aug 22, 2008 at 8:17 AM, Sean Linden wrote: > Errr, you own the stuff you create, so if you make something in SL you can > take it with you to another grid. I have no idea how the rights work for > anything else, even fullperm objects created by someone else, or any texture > not created by you (including the "default" textures like plywood), but > anything made by you belongs to you. So you can take the plywood cube if you > made it, I'm just not sure you can take the plywood :) > > On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole wrote: >> >> These people have no license to take content licensed for use in >> Secondlife as per the Secondlife TOS. >> Not even a plywood cube is authorized for taking from SL. >> Linden lab needs to deal with this one way or another even if it means >> immediate deletion of all accounts that engage in this behavior until such >> time as a proper content licensing scheme is in place. >> >> ----- Original Message ---- >> From: Jani Pirkola >> To: Second Life Developer Mailing List >> Sent: Friday, August 22, 2008 10:01:35 AM >> Subject: [sldev] realXtend Global inventory tests successful >> >> FYI >> >> ---------- Forwarded message ---------- >> From: Antti Ilom?ki >> Date: 2008/8/22 >> Subject: Global inventory tests successful >> To: realxtend@googlegroups.com >> >> >> >> We took another step towards the 3D Internet today, as we managed to >> transport objects from one site to another. These were just initial >> tests and only prims were tested, but it's sort of a historical >> moment. >> >> You've all probably already read the story on the realXtend blog, but >> here's the link: http://realxtend.blogspot.com/ >> >> --~--~---------~--~----~------------~-------~--~----~ >> You received this message because you are subscribed to the Google Groups >> "realXtend" group. >> To post to this group, send email to realxtend@googlegroups.com >> To unsubscribe from this group, send email to >> realxtend+unsubscribe@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/realxtend?hl=en >> -~----------~----~----~----~------~----~------~--~--- >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From mark at identityserver.net Fri Aug 22 14:18:20 2008 From: mark at identityserver.net (Domino Marama) Date: Fri Aug 22 14:18:27 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <447887.90800.qm@web59104.mail.re1.yahoo.com> References: <447887.90800.qm@web59104.mail.re1.yahoo.com> Message-ID: <1219439900.8512.30.camel@domino-laptop> On Fri, 2008-08-22 at 08:26 -0700, Ann Otoole wrote: > c/m/t does not cut it. My thought is that it's just missing a group of permissions for the "owner after next" that's only settable by the creator. Just having that would sort out a lot of issues, at least for new content. It'd also be pretty easy to retro fit as Owner After = Next Owner is in effect the current behaviour. Each avatar could even have a default "Owner After" setting added, so their existing content could be protected.. if prim.hasOwnerAfterFlags: use them else if creator.hasOwnerAfterFlags: use them else: use next owner flags Next Owner = CMT and Owner After = CMT could equal export rights to a offline editor or to another grid as it's basically do what you want with it. The creator could either use more restrictive settings on Owner After if they are providing bits for builders, or less restrictive ones to make sure the freedoms granted are passed along. I'd much prefer to see a reworking of the permissions to allow the spirit of various licenses rather than adding support for the licenses themselves. Can you imagine if every vendor asked you to accept the licenses before it would sell you something? Maybe that's why LSL is gaining the get avatars language thing, so licenses can be presented in the right language ;) From gigstaggart at gmail.com Fri Aug 22 14:25:23 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Aug 22 14:25:27 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <1219439900.8512.30.camel@domino-laptop> References: <447887.90800.qm@web59104.mail.re1.yahoo.com> <1219439900.8512.30.camel@domino-laptop> Message-ID: <48AF2EC3.2070805@gmail.com> Domino Marama wrote: > Can you imagine if every vendor asked you to accept the licenses before > it would sell you something? Maybe that's why LSL is gaining the get > avatars language thing, so licenses can be presented in the right > language ;) Copyright licenses do not need to be "agreed to" to be in force. They are legally distinct from contracts. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080822/678d9e80/smime-0001.bin From ordinal.malaprop at fastmail.fm Fri Aug 22 15:21:53 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Aug 22 15:21:58 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> Message-ID: <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> I really don't think this while "omg we live in the digital age now copyright is so in the past" stuff is useful here, and neither do I think it's appropriate - we had a huge argument about permissions etc on sldev not too long ago which came to nothing. On 22 Aug 2008, at 22:16, azdel slade wrote: > Sean is right here. This is how copyright works IRL. If you create an > artwork, say a photograph, you own the copyright, even if you haven't > legally filed it yet. And you should be upset, because if we don't get > interoperability between grids, then we can be sure that the future of > the metaverse will be as short lived as any corporation, in this case > linden labs. I am very much looking forward to being able to move > inventory between grids and having it work. > > All this draconian IP control that people are demanding is so 18th > century. Get with it folks. If you can see it in SL, then it's already > in memory on your machine and people will do what they want with it. > Its inevitable. Of all places, SL is a wonderful place to find new > models beyond copy restriction. The last thing I want is the SLAA to > replace the RIAA, so stop asking for it, please. If you want to see SL > continue to grow (and exist) than we need working interoperability > between grids. Of all places, the open source developer's list should > understand this. > > azdel > > > On Fri, Aug 22, 2008 at 8:17 AM, Sean Linden > wrote: >> Errr, you own the stuff you create, so if you make something in SL >> you can >> take it with you to another grid. I have no idea how the rights >> work for >> anything else, even fullperm objects created by someone else, or >> any texture >> not created by you (including the "default" textures like plywood), >> but >> anything made by you belongs to you. So you can take the plywood >> cube if you >> made it, I'm just not sure you can take the plywood :) >> >> On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole >> wrote: >>> >>> These people have no license to take content licensed for use in >>> Secondlife as per the Secondlife TOS. >>> Not even a plywood cube is authorized for taking from SL. >>> Linden lab needs to deal with this one way or another even if it >>> means >>> immediate deletion of all accounts that engage in this behavior >>> until such >>> time as a proper content licensing scheme is in place. >>> >>> ----- Original Message ---- >>> From: Jani Pirkola >>> To: Second Life Developer Mailing List >>> Sent: Friday, August 22, 2008 10:01:35 AM >>> Subject: [sldev] realXtend Global inventory tests successful >>> >>> FYI >>> >>> ---------- Forwarded message ---------- >>> From: Antti Ilom?ki >>> Date: 2008/8/22 >>> Subject: Global inventory tests successful >>> To: realxtend@googlegroups.com >>> >>> >>> >>> We took another step towards the 3D Internet today, as we managed to >>> transport objects from one site to another. These were just initial >>> tests and only prims were tested, but it's sort of a historical >>> moment. >>> >>> You've all probably already read the story on the realXtend blog, >>> but >>> here's the link: http://realxtend.blogspot.com/ >>> >>> --~--~---------~--~----~------------~-------~--~----~ >>> You received this message because you are subscribed to the Google >>> Groups >>> "realXtend" group. >>> To post to this group, send email to realxtend@googlegroups.com >>> To unsubscribe from this group, send email to >>> realxtend+unsubscribe@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/realxtend?hl=en >>> -~----------~----~----~----~------~----~------~--~--- >>> >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From tshephard at gmail.com Fri Aug 22 15:34:08 2008 From: tshephard at gmail.com (Tim Shephard) Date: Fri Aug 22 15:34:10 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> Message-ID: <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> I just wanted to bump this, it's been awhile. I've been doing a lot of work with Apple stuff lately and this model has been very successful for the iPhone which is doing precisely what I talk about here. Admittedly, it's somewhat revenue neutral, but in terms of pushing platform adoption it has done extremely well. I think with the virtual currency a lot of money Apple is paying to Credit Cards, would go to Linden Lab. It also creates a demand for the currency itself, which is another area for profit. Finally, it's a marketplace which can be built upon GPL / Open Standard software, because what you're paying for is the credibility of the marketplace itself, not the proprietary code. Hopefully the powers that be at LL are paying attention. Cheers, Tim. On Mon, Sep 17, 2007 at 12:27 AM, Tim Shephard wrote: > Simply - buy out SLExchange. > > Get out of the hosting biz (a profound strategical error) and enter > into the marketplace biz. > > Enforce a license such that anyone who wants to develop assets for SL > and use SL IP must either sell their assets through your marketplace > or use advertising partnerships via your marketplace if they're going > to use advertising as their source of revenue. > > Enable a plugin architecture for both the client and server. Let > people sell plugins through your marketplace and take 10% off all > revenue and more if it is advertising based. > > Not only will your marketplace be a great revenue generator, it will > provide a great service for the community by vetting all assets for > copyright infringement, quality, and viruses. Both buyers and > legitimate seller alike will flock to your marketplace as an efficient > place to do business. > > It's really the best model to make money off Open Source. We have > all the freedom of IP with a way to make money for those who are > shepherding the community. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/b0a4ab31/attachment.htm From sean at lindenlab.com Fri Aug 22 16:12:35 2008 From: sean at lindenlab.com (Sean Linden) Date: Fri Aug 22 16:12:38 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> Message-ID: <3736d47a0808221612x48adca45i54d90c6296e98d3a@mail.gmail.com> It's hard to think of something more closed than the iPhone, so calling Apple's revenue model "a way to make money off of open source" just makes no sense. Any license requiring you to sell something via a specific site is not open source, or at least not the kind of "open source" I personally have any interest in. On Fri, Aug 22, 2008 at 3:34 PM, Tim Shephard wrote: > I just wanted to bump this, it's been awhile. I've been doing a lot of > work with Apple stuff lately and this model has been very successful for the > iPhone which is doing precisely what I talk about here. > > Admittedly, it's somewhat revenue neutral, but in terms of pushing platform > adoption it has done extremely well. > > I think with the virtual currency a lot of money Apple is paying to Credit > Cards, would go to Linden Lab. It also creates a demand for the currency > itself, which is another area for profit. Finally, it's a marketplace > which can be built upon GPL / Open Standard software, because what you're > paying for is the credibility of the marketplace itself, not the proprietary > code. > > Hopefully the powers that be at LL are paying attention. > > Cheers, > > Tim. > > On Mon, Sep 17, 2007 at 12:27 AM, Tim Shephard wrote: > >> Simply - buy out SLExchange. >> >> Get out of the hosting biz (a profound strategical error) and enter >> into the marketplace biz. >> >> Enforce a license such that anyone who wants to develop assets for SL >> and use SL IP must either sell their assets through your marketplace >> or use advertising partnerships via your marketplace if they're going >> to use advertising as their source of revenue. >> >> Enable a plugin architecture for both the client and server. Let >> people sell plugins through your marketplace and take 10% off all >> revenue and more if it is advertising based. >> >> Not only will your marketplace be a great revenue generator, it will >> provide a great service for the community by vetting all assets for >> copyright infringement, quality, and viruses. Both buyers and >> legitimate seller alike will flock to your marketplace as an efficient >> place to do business. >> >> It's really the best model to make money off Open Source. We have >> all the freedom of IP with a way to make money for those who are >> shepherding the community. >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/589f8025/attachment.htm From sean at lindenlab.com Fri Aug 22 16:28:14 2008 From: sean at lindenlab.com (Sean Linden) Date: Fri Aug 22 16:28:21 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> Message-ID: <3736d47a0808221628j1fe34414m916e42a68ca2067d@mail.gmail.com> While I don't agree with the "it can all be copied anyway so just get over it" philosophy, I do think that there *are* limits to what is feasible to protect with technology. Attempts to, say, encrypt everything sent to the viewer with some black box that needs to be put into even open source builds are completely worthless because it imposes a high cost on development and use in favor of something that only needs to be broken once. Obfuscation of, say, the cache, only needs to be broken once too, but at least it costs less to have it. And in both cases the hurdle for everyone but the one person who has to break it is the same: you have to find and download some extra piece of software that extracts stuff for you. But at least then you know you're being naughty. Even the cleverest DRM schemes to date that have hit the open market have turned into no higher a hurdle than obfuscation within weeks of their release. On Fri, Aug 22, 2008 at 3:21 PM, wrote: > I really don't think this while "omg we live in the digital age now > copyright is so in the past" stuff is useful here, and neither do I think > it's appropriate - we had a huge argument about permissions etc on sldev not > too long ago which came to nothing. > > > On 22 Aug 2008, at 22:16, azdel slade wrote: > > Sean is right here. This is how copyright works IRL. If you create an >> artwork, say a photograph, you own the copyright, even if you haven't >> legally filed it yet. And you should be upset, because if we don't get >> interoperability between grids, then we can be sure that the future of >> the metaverse will be as short lived as any corporation, in this case >> linden labs. I am very much looking forward to being able to move >> inventory between grids and having it work. >> >> All this draconian IP control that people are demanding is so 18th >> century. Get with it folks. If you can see it in SL, then it's already >> in memory on your machine and people will do what they want with it. >> Its inevitable. Of all places, SL is a wonderful place to find new >> models beyond copy restriction. The last thing I want is the SLAA to >> replace the RIAA, so stop asking for it, please. If you want to see SL >> continue to grow (and exist) than we need working interoperability >> between grids. Of all places, the open source developer's list should >> understand this. >> >> azdel >> >> >> On Fri, Aug 22, 2008 at 8:17 AM, Sean Linden wrote: >> >>> Errr, you own the stuff you create, so if you make something in SL you >>> can >>> take it with you to another grid. I have no idea how the rights work for >>> anything else, even fullperm objects created by someone else, or any >>> texture >>> not created by you (including the "default" textures like plywood), but >>> anything made by you belongs to you. So you can take the plywood cube if >>> you >>> made it, I'm just not sure you can take the plywood :) >>> >>> On Fri, Aug 22, 2008 at 8:01 AM, Ann Otoole >>> wrote: >>> >>>> >>>> These people have no license to take content licensed for use in >>>> Secondlife as per the Secondlife TOS. >>>> Not even a plywood cube is authorized for taking from SL. >>>> Linden lab needs to deal with this one way or another even if it means >>>> immediate deletion of all accounts that engage in this behavior until >>>> such >>>> time as a proper content licensing scheme is in place. >>>> >>>> ----- Original Message ---- >>>> From: Jani Pirkola >>>> To: Second Life Developer Mailing List >>>> Sent: Friday, August 22, 2008 10:01:35 AM >>>> Subject: [sldev] realXtend Global inventory tests successful >>>> >>>> FYI >>>> >>>> ---------- Forwarded message ---------- >>>> From: Antti Ilom?ki >>>> Date: 2008/8/22 >>>> Subject: Global inventory tests successful >>>> To: realxtend@googlegroups.com >>>> >>>> >>>> >>>> We took another step towards the 3D Internet today, as we managed to >>>> transport objects from one site to another. These were just initial >>>> tests and only prims were tested, but it's sort of a historical >>>> moment. >>>> >>>> You've all probably already read the story on the realXtend blog, but >>>> here's the link: http://realxtend.blogspot.com/ >>>> >>>> --~--~---------~--~----~------------~-------~--~----~ >>>> You received this message because you are subscribed to the Google >>>> Groups >>>> "realXtend" group. >>>> To post to this group, send email to realxtend@googlegroups.com >>>> To unsubscribe from this group, send email to >>>> realxtend+unsubscribe@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/realxtend?hl=en >>>> -~----------~----~----~----~------~----~------~--~--- >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080822/6ca8772a/attachment-0001.htm From anthonyrbundy at gmail.com Fri Aug 22 16:53:25 2008 From: anthonyrbundy at gmail.com (Tony) Date: Fri Aug 22 16:53:31 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> References: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> Message-ID: <48AF5175.2050908@gmail.com> Totally awesome work! I applaud your pioneering the great inter-virtual world frontier!. Tony Jani Pirkola wrote: > FYI > > ---------- Forwarded message ---------- > From: *Antti Ilom?ki* > > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google > Groups "realXtend" group. > To post to this group, send email to realxtend@googlegroups.com > > To unsubscribe from this group, send email to > realxtend+unsubscribe@googlegroups.com > > For more options, visit this group at > http://groups.google.com/group/realxtend?hl=en > -~----------~----~----~----~------~----~------~--~--- > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From fire at eslteacherlink.co.kr Sat Aug 23 01:31:18 2008 From: fire at eslteacherlink.co.kr (Fire in Korea) Date: Sat Aug 23 01:31:22 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> Message-ID: <1dabc2a30808230131h703c5abbmfee0d1ff07a9b647@mail.gmail.com> Nice one Argent, I'm totally on the same page as you... don't worry, it's coming, most probably the first thing we'll see is that through or cellphones... On Fri, Aug 22, 2008 at 8:49 PM, Argent Stonecutter wrote: > Damn, I was hoping that this was something that would control an avatar by > tracking your movements. > > I want augmented reality, too, but it's when I'm *not* at my desk that I > need it. I'd love to have SL-like nametags hovering over people's heads in > my semitransparent digital sunglasses, and even getting people in RL > replaced by their avatars... but I don't see anything tied to my desktop as > augmented reality. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Paul Preibisch Creative Director B3D Media Labs Ltd. Seoul, South Korea Facebook Second Life Link Application: http://www.facebook.com/applications/Second_Life_Link/10242435556 Skype: eslteacherlink.com Second Life Id: Fire Centaur English Village SLURL: http://slurl.com/secondlife/English%20Village/131/162/126/?x=500&y=500&img=http%3A//eslteacherlink.com/ev.jpg&title=English%20Village& Facebook Groups: Second Life for Educators: http://www.f8.facebook.com/group.php?gid=2387164946 Profile Page: http://www.f8.facebook.com/profile.php?id=627331676 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080823/52722176/attachment.htm From secondloop at gmail.com Sat Aug 23 02:44:00 2008 From: secondloop at gmail.com (azdel slade) Date: Sat Aug 23 02:44:01 2008 Subject: [sldev] files missing from svn in maint-render-7? Message-ID: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> Ok, take 2 trying to compile with cmake. I got visual studio 2005 pro. I have to correct my staement yesterday, microsoft's "dreamspark" program does allow students to download visual studio 2008 an 2005. I must've tried to use visual C++ express to save download time. So while configuring with develop.py, I got an error about CMakeLists.txt for llrender and newview referring to cpp files that were missing. To be able to continue, I commented them out. But now, I'm getting linker errors, of course. Can folks direct me to where I should get these files from? The problem files are: llcubemap.cpp llpostprocess.cpp llrendersphere.cpp llshadermgr.cpp I double checked, trying to svn update, and still don't have these files. and I get these linker errors, as expected: Linking... llrender.lib(llrender.obj) : error LNK2001: unresolved external symbol "public: static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) llappviewer.obj : error LNK2001: unresolved external symbol "public: static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) lldrawpoolwater.obj : error LNK2001: unresolved external symbol "public: static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) llpaneldisplay.obj : error LNK2001: unresolved external symbol "public: static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) llvosky.obj : error LNK2001: unresolved external symbol "public: static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) llappviewer.obj : error LNK2019: unresolved external symbol "public: static void __cdecl LLPostProcess::cleanupClass(void)" (?cleanupClass@LLPostProcess@@SAXXZ) referenced in function "public: virtual bool __thiscall LLAppViewer::cleanup(void)" (?cleanup@LLAppViewer@@UAE_NXZ) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::enable(int)" (?enable@LLCubeMap@@QAEXH@Z) referenced in function "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) lldrawpoolwater.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLCubeMap::enable(int)" (?enable@LLCubeMap@@QAEXH@Z) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::enableTextureCoords(int)" (?enableTextureCoords@LLCubeMap@@QAEXH@Z) referenced in function "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::enableTexture(int)" (?enableTexture@LLCubeMap@@QAEXH@Z) referenced in function "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) pipeline.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLCubeMap::enableTexture(int)" (?enableTexture@LLCubeMap@@QAEXH@Z) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::setMatrix(int)" (?setMatrix@LLCubeMap@@QAEXH@Z) referenced in function "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::restoreMatrix(void)" (?restoreMatrix@LLCubeMap@@QAEXXZ) referenced in function "public: void __thiscall LLDrawPoolBump::endShiny(bool)" (?endShiny@LLDrawPoolBump@@QAEX_N@Z) lldrawpoolbump.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::disable(void)" (?disable@LLCubeMap@@QAEXXZ) referenced in function "public: void __thiscall LLDrawPoolBump::endShiny(bool)" (?endShiny@LLDrawPoolBump@@QAEX_N@Z) lldrawpoolwater.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLCubeMap::disable(void)" (?disable@LLCubeMap@@QAEXXZ) lldrawpoolwater.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::bind(void)" (?bind@LLCubeMap@@QAEXXZ) referenced in function "public: virtual void __thiscall LLDrawPoolWater::render(int)" (?render@LLDrawPoolWater@@UAEXH@Z) llfloaterpostprocess.obj : error LNK2001: unresolved external symbol "class LLPostProcess * gPostProcess" (?gPostProcess@@3PAVLLPostProcess@@A) llfloaterpostprocess.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLPostProcess::setSelectedEffect(class std::basic_string,class std::allocator > const &)" (?setSelectedEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "public: static void __cdecl LLFloaterPostProcess::onLoadEffect(void *)" (?onLoadEffect@LLFloaterPostProcess@@SAXPAX@Z) llfloaterpostprocess.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLPostProcess::saveEffect(class std::basic_string,class std::allocator > const &)" (?saveEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "public: static void __cdecl LLFloaterPostProcess::onSaveEffect(void *)" (?onSaveEffect@LLFloaterPostProcess@@SAXPAX@Z) llglsandbox.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRenderSphere::render(float)" (?render@LLRenderSphere@@QAEXM@Z) referenced in function "public: void __thiscall LLAgent::renderAutoPilotTarget(void)" (?renderAutoPilotTarget@LLAgent@@QAEXXZ) llhudeffectbeam.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLRenderSphere::render(float)" (?render@LLRenderSphere@@QAEXM@Z) llviewerwindow.obj : error LNK2001: unresolved external symbol "public: void __thiscall LLRenderSphere::render(float)" (?render@LLRenderSphere@@QAEXM@Z) llglsandbox.obj : error LNK2001: unresolved external symbol "class LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) llhudeffectbeam.obj : error LNK2019: unresolved external symbol "class LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) referenced in function __ehhandler$?unpackData@LLHUDEffectBeam@@MAEXPAVLLMessageSystem@@H@Z llviewerjoint.obj : error LNK2001: unresolved external symbol "class LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) llviewerwindow.obj : error LNK2001: unresolved external symbol "class LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) llstartup.obj : error LNK2019: unresolved external symbol "public: static void __cdecl LLPostProcess::initClass(void)" (?initClass@LLPostProcess@@SAXXZ) referenced in function "int __cdecl idle_startup(void)" (?idle_startup@@YAHXZ) llviewerjoint.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRenderSphere::render(void)" (?render@LLRenderSphere@@QAEXXZ) referenced in function "public: void __thiscall LLViewerJointCollisionVolume::renderCollision(void)" (?renderCollision@LLViewerJointCollisionVolume@@QAEXXZ) llviewershadermgr.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall LLShaderMgr::~LLShaderMgr(void)" (??1LLShaderMgr@@UAE@XZ) referenced in function "public: virtual __thiscall LLViewerShaderMgr::~LLViewerShaderMgr(void)" (??1LLViewerShaderMgr@@UAE@XZ) llviewershadermgr.obj : error LNK2019: unresolved external symbol "public: __thiscall LLShaderMgr::LLShaderMgr(void)" (??0LLShaderMgr@@QAE@XZ) referenced in function "public: __thiscall LLViewerShaderMgr::LLViewerShaderMgr(void)" (??0LLViewerShaderMgr@@QAE@XZ) llviewershadermgr.obj : error LNK2001: unresolved external symbol "protected: static class LLShaderMgr * LLShaderMgr::sInstance" (?sInstance@LLShaderMgr@@1PAV1@A) llviewershadermgr.obj : error LNK2019: unresolved external symbol "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class std::basic_string,class std::allocator > const &,int &,unsigned int)" (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) referenced in function "public: int __thiscall LLViewerShaderMgr::loadBasicShaders(void)" (?loadBasicShaders@LLViewerShaderMgr@@QAEHXZ) llrender.lib(llglslshader.obj) : error LNK2001: unresolved external symbol "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class std::basic_string,class std::allocator > const &,int &,unsigned int)" (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) llviewerwindow.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRenderSphere::prerender(void)" (?prerender@LLRenderSphere@@QAEXXZ) referenced in function "public: void __thiscall LLViewerWindow::initGLDefaults(void)" (?initGLDefaults@LLViewerWindow@@QAEXXZ) llviewerwindow.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLRenderSphere::cleanupGL(void)" (?cleanupGL@LLRenderSphere@@QAEXXZ) referenced in function "private: void __thiscall LLViewerWindow::stopGL(int)" (?stopGL@LLViewerWindow@@AAEXH@Z) llvosky.obj : error LNK2019: unresolved external symbol "public: __thiscall LLCubeMap::LLCubeMap(void)" (??0LLCubeMap@@QAE@XZ) referenced in function "public: void __thiscall LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) llvosky.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::init(class std::vector,class std::allocator > > const &)" (?init@LLCubeMap@@QAEXABV?$vector@V?$LLPointer@VLLImageRaw@@@@V?$allocator@V?$LLPointer@VLLImageRaw@@@@@std@@@std@@@Z) referenced in function "public: void __thiscall LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) llvosky.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::destroyGL(void)" (?destroyGL@LLCubeMap@@QAEXXZ) referenced in function "public: void __thiscall LLVOSky::cleanupGL(void)" (?cleanupGL@LLVOSky@@QAEXXZ) pipeline.obj : error LNK2019: unresolved external symbol "public: unsigned int __thiscall LLCubeMap::getGLName(void)" (?getGLName@LLCubeMap@@QAEIXZ) referenced in function "public: void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) pipeline.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLCubeMap::setReflection(void)" (?setReflection@LLCubeMap@@QAEXXZ) referenced in function "public: void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) llrender.lib(llglslshader.obj) : error LNK2019: unresolved external symbol "public: int __thiscall LLShaderMgr::attachShaderFeatures(class LLGLSLShader *)" (?attachShaderFeatures@LLShaderMgr@@QAEHPAVLLGLSLShader@@@Z) referenced in function "public: int __thiscall LLGLSLShader::createShader(class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > *,class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > *)" (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) llrender.lib(llglslshader.obj) : error LNK2019: unresolved external symbol "public: static class LLShaderMgr * __cdecl LLShaderMgr::instance(void)" (?instance@LLShaderMgr@@SAPAV1@XZ) referenced in function "public: int __thiscall LLGLSLShader::createShader(class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > *,class std::vector,class std::allocator >,class std::allocator,class std::allocator > > > *)" (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) llrender.lib(llglslshader.obj) : error LNK2019: unresolved external symbol "public: int __thiscall LLShaderMgr::linkProgramObject(unsigned int,int)" (?linkProgramObject@LLShaderMgr@@QAEHIH@Z) referenced in function "public: int __thiscall LLGLSLShader::link(int)" (?link@LLGLSLShader@@QAEHH@Z) C:\src\maint-render-7\indra\build-vc80\newview\RelWithDebInfo\secondlife-bin.exe : fatal error LNK1120: 30 unresolved externals Build log was saved at "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" secondlife-bin - 44 error(s), 0 warning(s) ------ Skipped Build: Project: ALL_BUILD, Configuration: RelWithDebInfo Win32 ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: server, Configuration: RelWithDebInfo Win32 ------ Project not selected to build for this solution configuration ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo Win32 ------ Project not selected to build for this solution configuration ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== Any suggestions here would be greatly appreciated... thanks, azdel From soft at lindenlab.com Sat Aug 23 04:19:03 2008 From: soft at lindenlab.com (Soft) Date: Sat Aug 23 04:19:07 2008 Subject: [sldev] files missing from svn in maint-render-7? In-Reply-To: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> References: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> Message-ID: maint-render-10 is out and most current. (Yes, there was no maint-render-9.) You might try against that branch. If you have specific need of the -7 branch, I remember that some other branches were affected by missing exports on these files. I could track down the fixes. On Sat, Aug 23, 2008 at 4:44 AM, azdel slade wrote: > Ok, take 2 trying to compile with cmake. > > I got visual studio 2005 pro. I have to correct my staement yesterday, > microsoft's "dreamspark" program does allow students to download > visual studio 2008 an 2005. I must've tried to use visual C++ express > to save download time. > > So while configuring with develop.py, I got an error about > CMakeLists.txt for llrender and newview referring to cpp files that > were missing. To be able to continue, I commented them out. But now, > I'm getting linker errors, of course. Can folks direct me to where I > should get these files from? > > The problem files are: > > llcubemap.cpp > llpostprocess.cpp > llrendersphere.cpp > llshadermgr.cpp > > I double checked, trying to svn update, and still don't have these files. > > and I get these linker errors, as expected: > > Linking... > llrender.lib(llrender.obj) : error LNK2001: unresolved external symbol > "public: static bool LLCubeMap::sUseCubeMaps" > (?sUseCubeMaps@LLCubeMap@@2_NA) > llappviewer.obj : error LNK2001: unresolved external symbol "public: > static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) > lldrawpoolwater.obj : error LNK2001: unresolved external symbol > "public: static bool LLCubeMap::sUseCubeMaps" > (?sUseCubeMaps@LLCubeMap@@2_NA) > llpaneldisplay.obj : error LNK2001: unresolved external symbol > "public: static bool LLCubeMap::sUseCubeMaps" > (?sUseCubeMaps@LLCubeMap@@2_NA) > llvosky.obj : error LNK2001: unresolved external symbol "public: > static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) > llappviewer.obj : error LNK2019: unresolved external symbol "public: > static void __cdecl LLPostProcess::cleanupClass(void)" > (?cleanupClass@LLPostProcess@@SAXXZ) referenced in function "public: > virtual bool __thiscall LLAppViewer::cleanup(void)" > (?cleanup@LLAppViewer@@UAE_NXZ) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::enable(int)" > (?enable@LLCubeMap@@QAEXH@Z) referenced in function "public: void > __thiscall LLDrawPoolBump::beginShiny(bool)" > (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) > lldrawpoolwater.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLCubeMap::enable(int)" > (?enable@LLCubeMap@@QAEXH@Z) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::enableTextureCoords(int)" > (?enableTextureCoords@LLCubeMap@@QAEXH@Z) referenced in function > "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" > (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::enableTexture(int)" > (?enableTexture@LLCubeMap@@QAEXH@Z) referenced in function "public: > void __thiscall LLDrawPoolBump::beginShiny(bool)" > (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) > pipeline.obj : error LNK2001: unresolved external symbol "public: void > __thiscall LLCubeMap::enableTexture(int)" > (?enableTexture@LLCubeMap@@QAEXH@Z) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::setMatrix(int)" > (?setMatrix@LLCubeMap@@QAEXH@Z) referenced in function "public: void > __thiscall LLDrawPoolBump::beginShiny(bool)" > (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::restoreMatrix(void)" > (?restoreMatrix@LLCubeMap@@QAEXXZ) referenced in function "public: > void __thiscall LLDrawPoolBump::endShiny(bool)" > (?endShiny@LLDrawPoolBump@@QAEX_N@Z) > lldrawpoolbump.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::disable(void)" > (?disable@LLCubeMap@@QAEXXZ) referenced in function "public: void > __thiscall LLDrawPoolBump::endShiny(bool)" > (?endShiny@LLDrawPoolBump@@QAEX_N@Z) > lldrawpoolwater.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLCubeMap::disable(void)" > (?disable@LLCubeMap@@QAEXXZ) > lldrawpoolwater.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLCubeMap::bind(void)" > (?bind@LLCubeMap@@QAEXXZ) referenced in function "public: virtual void > __thiscall LLDrawPoolWater::render(int)" > (?render@LLDrawPoolWater@@UAEXH@Z) > llfloaterpostprocess.obj : error LNK2001: unresolved external symbol > "class LLPostProcess * gPostProcess" > (?gPostProcess@@3PAVLLPostProcess@@A) > llfloaterpostprocess.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLPostProcess::setSelectedEffect(class > std::basic_string,class > std::allocator > const &)" > (?setSelectedEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) > referenced in function "public: static void __cdecl > LLFloaterPostProcess::onLoadEffect(void *)" > (?onLoadEffect@LLFloaterPostProcess@@SAXPAX@Z) > llfloaterpostprocess.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLPostProcess::saveEffect(class > std::basic_string,class > std::allocator > const &)" > (?saveEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) > referenced in function "public: static void __cdecl > LLFloaterPostProcess::onSaveEffect(void *)" > (?onSaveEffect@LLFloaterPostProcess@@SAXPAX@Z) > llglsandbox.obj : error LNK2019: unresolved external symbol "public: > void __thiscall LLRenderSphere::render(float)" > (?render@LLRenderSphere@@QAEXM@Z) referenced in function "public: void > __thiscall LLAgent::renderAutoPilotTarget(void)" > (?renderAutoPilotTarget@LLAgent@@QAEXXZ) > llhudeffectbeam.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLRenderSphere::render(float)" > (?render@LLRenderSphere@@QAEXM@Z) > llviewerwindow.obj : error LNK2001: unresolved external symbol > "public: void __thiscall LLRenderSphere::render(float)" > (?render@LLRenderSphere@@QAEXM@Z) > llglsandbox.obj : error LNK2001: unresolved external symbol "class > LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) > llhudeffectbeam.obj : error LNK2019: unresolved external symbol "class > LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) referenced in > function __ehhandler$?unpackData@LLHUDEffectBeam@@MAEXPAVLLMessageSystem@@H@Z > llviewerjoint.obj : error LNK2001: unresolved external symbol "class > LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) > llviewerwindow.obj : error LNK2001: unresolved external symbol "class > LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) > llstartup.obj : error LNK2019: unresolved external symbol "public: > static void __cdecl LLPostProcess::initClass(void)" > (?initClass@LLPostProcess@@SAXXZ) referenced in function "int __cdecl > idle_startup(void)" (?idle_startup@@YAHXZ) > llviewerjoint.obj : error LNK2019: unresolved external symbol "public: > void __thiscall LLRenderSphere::render(void)" > (?render@LLRenderSphere@@QAEXXZ) referenced in function "public: void > __thiscall LLViewerJointCollisionVolume::renderCollision(void)" > (?renderCollision@LLViewerJointCollisionVolume@@QAEXXZ) > llviewershadermgr.obj : error LNK2019: unresolved external symbol > "public: virtual __thiscall LLShaderMgr::~LLShaderMgr(void)" > (??1LLShaderMgr@@UAE@XZ) referenced in function "public: virtual > __thiscall LLViewerShaderMgr::~LLViewerShaderMgr(void)" > (??1LLViewerShaderMgr@@UAE@XZ) > llviewershadermgr.obj : error LNK2019: unresolved external symbol > "public: __thiscall LLShaderMgr::LLShaderMgr(void)" > (??0LLShaderMgr@@QAE@XZ) referenced in function "public: __thiscall > LLViewerShaderMgr::LLViewerShaderMgr(void)" > (??0LLViewerShaderMgr@@QAE@XZ) > llviewershadermgr.obj : error LNK2001: unresolved external symbol > "protected: static class LLShaderMgr * LLShaderMgr::sInstance" > (?sInstance@LLShaderMgr@@1PAV1@A) > llviewershadermgr.obj : error LNK2019: unresolved external symbol > "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class > std::basic_string,class > std::allocator > const &,int &,unsigned int)" > (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) > referenced in function "public: int __thiscall > LLViewerShaderMgr::loadBasicShaders(void)" > (?loadBasicShaders@LLViewerShaderMgr@@QAEHXZ) > llrender.lib(llglslshader.obj) : error LNK2001: unresolved external > symbol "public: unsigned int __thiscall > LLShaderMgr::loadShaderFile(class std::basic_string std::char_traits,class std::allocator > const &,int > &,unsigned int)" > (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) > llviewerwindow.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLRenderSphere::prerender(void)" > (?prerender@LLRenderSphere@@QAEXXZ) referenced in function "public: > void __thiscall LLViewerWindow::initGLDefaults(void)" > (?initGLDefaults@LLViewerWindow@@QAEXXZ) > llviewerwindow.obj : error LNK2019: unresolved external symbol > "public: void __thiscall LLRenderSphere::cleanupGL(void)" > (?cleanupGL@LLRenderSphere@@QAEXXZ) referenced in function "private: > void __thiscall LLViewerWindow::stopGL(int)" > (?stopGL@LLViewerWindow@@AAEXH@Z) > llvosky.obj : error LNK2019: unresolved external symbol "public: > __thiscall LLCubeMap::LLCubeMap(void)" (??0LLCubeMap@@QAE@XZ) > referenced in function "public: void __thiscall > LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) > llvosky.obj : error LNK2019: unresolved external symbol "public: void > __thiscall LLCubeMap::init(class std::vector LLImageRaw>,class std::allocator > > > const &)" (?init@LLCubeMap@@QAEXABV?$vector@V?$LLPointer@VLLImageRaw@@@@V?$allocator@V?$LLPointer@VLLImageRaw@@@@@std@@@std@@@Z) > referenced in function "public: void __thiscall > LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) > llvosky.obj : error LNK2019: unresolved external symbol "public: void > __thiscall LLCubeMap::destroyGL(void)" (?destroyGL@LLCubeMap@@QAEXXZ) > referenced in function "public: void __thiscall > LLVOSky::cleanupGL(void)" (?cleanupGL@LLVOSky@@QAEXXZ) > pipeline.obj : error LNK2019: unresolved external symbol "public: > unsigned int __thiscall LLCubeMap::getGLName(void)" > (?getGLName@LLCubeMap@@QAEIXZ) referenced in function "public: void > __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class > LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) > pipeline.obj : error LNK2019: unresolved external symbol "public: void > __thiscall LLCubeMap::setReflection(void)" > (?setReflection@LLCubeMap@@QAEXXZ) referenced in function "public: > void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap > *,class LLCamera &)" > (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) > llrender.lib(llglslshader.obj) : error LNK2019: unresolved external > symbol "public: int __thiscall LLShaderMgr::attachShaderFeatures(class > LLGLSLShader *)" > (?attachShaderFeatures@LLShaderMgr@@QAEHPAVLLGLSLShader@@@Z) > referenced in function "public: int __thiscall > LLGLSLShader::createShader(class std::vector std::basic_string,class > std::allocator >,class std::allocator std::basic_string,class > std::allocator > > > *,class std::vector std::basic_string,class > std::allocator >,class std::allocator std::basic_string,class > std::allocator > > > *)" > (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) > llrender.lib(llglslshader.obj) : error LNK2019: unresolved external > symbol "public: static class LLShaderMgr * __cdecl > LLShaderMgr::instance(void)" (?instance@LLShaderMgr@@SAPAV1@XZ) > referenced in function "public: int __thiscall > LLGLSLShader::createShader(class std::vector std::basic_string,class > std::allocator >,class std::allocator std::basic_string,class > std::allocator > > > *,class std::vector std::basic_string,class > std::allocator >,class std::allocator std::basic_string,class > std::allocator > > > *)" > (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) > llrender.lib(llglslshader.obj) : error LNK2019: unresolved external > symbol "public: int __thiscall LLShaderMgr::linkProgramObject(unsigned > int,int)" (?linkProgramObject@LLShaderMgr@@QAEHIH@Z) referenced in > function "public: int __thiscall LLGLSLShader::link(int)" > (?link@LLGLSLShader@@QAEHH@Z) > C:\src\maint-render-7\indra\build-vc80\newview\RelWithDebInfo\secondlife-bin.exe > : fatal error LNK1120: 30 unresolved externals > Build log was saved at > "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" > secondlife-bin - 44 error(s), 0 warning(s) > ------ Skipped Build: Project: ALL_BUILD, Configuration: > RelWithDebInfo Win32 ------ > Project not selected to build for this solution configuration > ------ Skipped Build: Project: server, Configuration: RelWithDebInfo > Win32 ------ > Project not selected to build for this solution configuration > ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo > Win32 ------ > Project not selected to build for this solution configuration > ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== > > > Any suggestions here would be greatly appreciated... > > thanks, > > azdel > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From secret.argent at gmail.com Sat Aug 23 09:28:01 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 23 09:27:35 2008 Subject: [sldev] Useful GPL license guide. In-Reply-To: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> References: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> Message-ID: <97CAB6A4-3E22-4B68-972F-3FFDA5DB90C7@gmail.com> I don't want to start a new long thread about this, but this recently published guide to GPL compliance is probably worth reviewing. http://www.softwarefreedom.org/resources/2008/compliance-guide.html From secret.argent at gmail.com Sat Aug 23 09:30:36 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 23 09:30:12 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> Message-ID: > Now what would be good if you could start to attach licenses to asset > ID's. http://jira.secondlife.com/browse/SVC-701 From secret.argent at gmail.com Sat Aug 23 09:36:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 23 09:35:44 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> Message-ID: <50016BE8-A940-4704-B7AC-FAE0FD48DF62@gmail.com> Where was this originally posted? I don't recall seeing this... if it was posted here it must have been a long time ago. > Enforce a license such that anyone who wants to develop assets for SL > and use SL IP must either sell their assets through your marketplace > or use advertising partnerships via your marketplace if they're going > to use advertising as their source of revenue. What on earth does this have to do with open source? Nothing with that kind of limitation on it can be described as "open source" in any sense. From mrfrans at gmail.com Sat Aug 23 10:43:27 2008 From: mrfrans at gmail.com (Frans) Date: Sat Aug 23 10:43:31 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: <1dabc2a30808230131h703c5abbmfee0d1ff07a9b647@mail.gmail.com> References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> <1dabc2a30808230131h703c5abbmfee0d1ff07a9b647@mail.gmail.com> Message-ID: <7765f2c60808231043s38232675p1b20b9fcdd313df6@mail.gmail.com> Exactly Paul. In that regards there is already Enkin. http://www.enkin.net/ ""Enkin" introduces a new handheld navigation concept. It displays location-based content in a unique way that bridges the gap between reality and classic map-like representations. It combines GPS, orientation sensors, 3D graphics, live video, several web services, and a novel user interface into an intuitive and light navigation system for mobile devices." Basically it overlays google map data over live video from a phone camera. On Sat, Aug 23, 2008 at 4:31 AM, Fire in Korea wrote: > Nice one Argent, I'm totally on the same page as you... don't worry, it's > coming, most probably the first thing we'll see is that through or > cellphones... > > -- Jeroen Frans Executive Director The Vesuvius Group SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080823/cdf714a5/attachment.htm From tateru.nino at gmail.com Sat Aug 23 11:14:53 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Aug 23 11:14:59 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <50016BE8-A940-4704-B7AC-FAE0FD48DF62@gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> <50016BE8-A940-4704-B7AC-FAE0FD48DF62@gmail.com> Message-ID: <48B0539D.2060807@gmail.com> Thread started by Tim Shephard on or about September 2007 - if memory serves (I'd have to look it up) it was a proposal to monetize sales of closed-source viewer plugins. Argent Stonecutter wrote: > Where was this originally posted? I don't recall seeing this... if it > was posted here it must have been a long time ago. > >> Enforce a license such that anyone who wants to develop assets for SL >> and use SL IP must either sell their assets through your marketplace >> or use advertising partnerships via your marketplace if they're going >> to use advertising as their source of revenue. > > What on earth does this have to do with open source? Nothing with that > kind of limitation on it can be described as "open source" in any sense. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Sat Aug 23 11:43:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 23 11:43:33 2008 Subject: [sldev] Just to tantalize SL enthusiasts and developers imaginations a little more.... check out this augmented reality article In-Reply-To: <7765f2c60808231043s38232675p1b20b9fcdd313df6@mail.gmail.com> References: <1dabc2a30808211642r33b12655tdfa2176793540257@mail.gmail.com> <1dabc2a30808230131h703c5abbmfee0d1ff07a9b647@mail.gmail.com> <7765f2c60808231043s38232675p1b20b9fcdd313df6@mail.gmail.com> Message-ID: <3E130364-C4DC-48B1-A841-4215B378BFD9@gmail.com> On 2008-08-23, at 12:43, Frans wrote: > Exactly Paul. In that regards there is already Enkin. http:// > www.enkin.net/ Now *that* is cool. Just having the "life mode" distance and direction (like the original SL 'beam', before it was limited to only showing the destination and distance when you were 'close enough') available would be wonderful. From gigstaggart at gmail.com Sat Aug 23 13:42:15 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Aug 23 13:42:20 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> Message-ID: <48B07627.3010902@gmail.com> Tim Shephard wrote: > I just wanted to bump this, it's been awhile. I've been doing a lot of > work with Apple stuff lately and this model has been very successful for the > iPhone which is doing precisely what I talk about here. Do you have any idea how far back I had to scroll in my email client to see what was causing my "unread count" to be non-zero? Please don't "bump" year-old email threads. Just post a link to the web version of the old thread in a new thread. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080823/537226d7/smime.bin From nivardus at gmail.com Sat Aug 23 17:30:03 2008 From: nivardus at gmail.com (Gonta) Date: Sat Aug 23 17:30:09 2008 Subject: [sldev] [VWR] Viewer Performance Issues, VertexShaderEnable not found on feature list Message-ID: <71d0a1670808231730p963fabbpe4e03809ac697d34@mail.gmail.com> I've been getting terrible performance on builds of the latest SVN releases of the trunk and viewer_1-21 with release configurations. Is anyone else is getting dismal performance out of these in comparison to official builds; Whether it's just the release or specific to me? llfeaturemanager.ccp's "LLFeatureList::isFeatureAvailable Feature VertexShaderEnable not on feature list!" WinXP, using VS2005 Pro FPS 5- compared to 20+ on official, (Sluggish performance all-over) -gonta -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080823/e2f5ea0e/attachment.htm From lenglish5 at cox.net Sat Aug 23 20:16:07 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:16:09 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> References: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> Message-ID: <48B0D277.2060100@cox.net> Jani Pirkola wrote: > FYI > > ---------- Forwarded message ---------- > From: *Antti Ilom?ki* > > Date: 2008/8/22 > Subject: Global inventory tests successful > To: realxtend@googlegroups.com > > > > We took another step towards the 3D Internet today, as we managed to > transport objects from one site to another. These were just initial > tests and only prims were tested, but it's sort of a historical > moment. > > You've all probably already read the story on the realXtend blog, but > here's the link: http://realxtend.blogspot.com/ > Great stuff. I hope you're keeping track of the gridnauts/Open Grid Public Beta and will be willing to give advice on how to make the OGP work as well with realXtend worlds as it does with OpenSim... ...well, better, we hope, since even with OpenSim, the OGP still needs a lot of work. In the next week or so, us Pythonistas hope to have the pyogp library refactored and functioning to work with the currently defined protocols of the OGP. and Tao Takashi hopes to get his python agent domain handling teleport soon as well. At that point, perhaps you guys can start making sure it works with realkXtend worlds, and give us input on where the OGP and pyogp should be going next. And I know we are never sure if any of the realXtend folk are attending AWG meetings or the Linden office hours. I think we all would love to hear more about what you're doing if you want to speak up at the meetings. Lawson (Saijanai Kuhn) From lenglish5 at cox.net Sat Aug 23 20:21:12 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:21:14 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> Message-ID: <48B0D3A8.9040806@cox.net> Sean Linden wrote: > On Fri, Aug 22, 2008 at 8:48 AM, Robin Cornelius > > wrote: > > > Well currently anything at all you have not created has no license > attached so it cannot be assumed to be anything other than no > distribution rights. I would say that goes for linden default textures > too as although the artwork with the viewer source is licensed nothing > that is downloaded when connected has any kind of license so one > cannot be assumed. > > Now what would be good if you could start to attach licenses to asset > ID's. Now i know that everyone has there own favorite licenses but > there must be a sane finite number you could get to ranging from no > permissions to fully permissive, incorporating various Artistic type > licenses and options for scripts, various no commercial /allow > everything options, to cover a wide range. Then if the license ID is > sent with the asset info, its easy to know if you may use that asset > (with an appropriate viewer to look at asset id). > > Yes some one could hack a viewer to ignore this but thats no different > to now, what would be different is that content would have a very > clear licence and it will be 100% clear if you may reuse this within > SL or take it outside, or just do nothing with it etc. Lets not turn > this into a security by obscurity discussion this is about licenses. > > At texture/sound etc upload appropriate license could be selected by > content creator. > > This should even be able to be added to the existing system without > breaking anything, just assume ALL existing assets have no license > specified and treat this as a special case. May be allow content > creators to set the license on existing assets they have rather than > re-upload. > > > This sounds really interesting to me, Robin. Right now changing any > metadata associated with an asset requires creating a new asset, so it > would be impossible to change the license on something you've already > distributed after the fact, but this is not necessarily a bad thing > for stuff you've already applied a license to. It may, however, be > useful to be able to apply a license to something that has no license. > This would be kind of difficult to implement, however, because the > current system assumes assets are immutable. > > People have talked about different ways to handle asset metadata but > the most "obvious" way to do that is with a separate metadata file > since it would require a different format for each asset type to embed > the metadata (and I'm not even sure you could for, say, sounds), but > the asset system doesn't like lots of little files (it has a large > block size) and we have ~2 billion assets. Not that they'd all get > metadata applied. Then, if you make that file mutable, you're either > dealing with locks or just doing best-effort attempts to make sure > updates don't clobber one another. Actually, come to think of it, the > asset servers probably support a way to say "update this file but only > if its old content is still x". > The technical details of how LL servers will handle these issues are interesting. I jsut hope we can come up with a reasonably universal way to handle the issues for both LL assets and NON LL assets. I think that we should start testing alternative ways of describing the intellectual properties system(s) on the open grid as soon as possible. Tao Takashi's AD website shows we can make an Agent Domain in python. It might be good to start fashioning a test asset server or servers that people can work with to test these different ideas. Obviously, only specially created items can be allowed on such a server for the foreseeable future. Lawson L From lenglish5 at cox.net Sat Aug 23 20:23:51 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:23:55 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <61dbdd7d0808220921y1bd7f138p71308e70814399fc@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <3736d47a0808220914u500cff92k59347b0e87be39a0@mail.gmail.com> <61dbdd7d0808220921y1bd7f138p71308e70814399fc@mail.gmail.com> Message-ID: <48B0D447.60809@cox.net> Gareth Nelson wrote: > Surely the permissions flags constitute a form of license? > > Aside from this, what's wrong with a new "transfer to other grids" flag? > > Many of us want to see that. Problem is that neither Zero or any other technical Linden can speak for LInden Lab about what they're going to do until the lawyers are consulted, etc. BUT, before LL comes to a decision about how LL will handle its own database of user-created assets, we can still experiment with a dedicated server or two, to see what makes sense, both tethnically and from a user's point off view. Lawson From lenglish5 at cox.net Sat Aug 23 20:33:04 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:33:06 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> Message-ID: <48B0D670.6060702@cox.net> ordinal.malaprop@fastmail.fm wrote: > I really don't think this while "omg we live in the digital age now > copyright is so in the past" stuff is useful here, and neither do I > think it's appropriate - we had a huge argument about permissions etc > on sldev not too long ago which came to nothing. > And there have been many dozens of hours of discussions on the topic in the AWG and Linden office hours. Here's a few little links to get you started on what really is a very complex issue that virtually no-one comprehends simply by reading a few messages posted on SLDEV: https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases https://wiki.secondlife.com/wiki/Protecting_content_in_an_open_grid 80-ish discussions in AWGroupies meetings and Linden officers, often concerning this topic: https://wiki.secondlife.com/wiki/Category:Grid_Interoperability_Chat_Logs Lawson From lenglish5 at cox.net Sat Aug 23 20:35:15 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:35:18 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <3736d47a0808221628j1fe34414m916e42a68ca2067d@mail.gmail.com> References: <895749.67981.qm@web59106.mail.re1.yahoo.com> <3736d47a0808220817v78fcab5ap974e1fe5a6fd2c7c@mail.gmail.com> <1e0ce1090808221416q5e760e3awa104bb7cbaf75b99@mail.gmail.com> <5C7AB22F-F88D-4672-B8EE-70A306F67287@fastmail.fm> <3736d47a0808221628j1fe34414m916e42a68ca2067d@mail.gmail.com> Message-ID: <48B0D6F3.7090003@cox.net> Sean Linden wrote: > While I don't agree with the "it can all be copied anyway so just get > over it" philosophy, I do think that there *are* limits to what is > feasible to protect with technology. Attempts to, say, encrypt > everything sent to the viewer with some black box that needs to be put > into even open source builds are completely worthless because it > imposes a high cost on development and use in favor of something that > only needs to be broken once. Obfuscation of, say, the cache, only > needs to be broken once too, but at least it costs less to have it. > And in both cases the hurdle for everyone but the one person who has > to break it is the same: you have to find and download some extra > piece of software that extracts stuff for you. But at least then you > know you're being naughty. > > Even the cleverest DRM schemes to date that have hit the open market > have turned into no higher a hurdle than obfuscation within weeks of > their release. Even the cheapest padlock qualifies as a legally admissible deterrent so even a minor bit of obfuscation in the cache is a good thing. Lawson From lenglish5 at cox.net Sat Aug 23 20:37:29 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 23 20:37:33 2008 Subject: [sldev] Re: [META] How LL can profit from open source In-Reply-To: <50016BE8-A940-4704-B7AC-FAE0FD48DF62@gmail.com> References: <3b19a500709170027xd2d51c5yab64f698c7c618e6@mail.gmail.com> <3b19a500808221534k424c8831n470b0edd99c997be@mail.gmail.com> <50016BE8-A940-4704-B7AC-FAE0FD48DF62@gmail.com> Message-ID: <48B0D779.7090900@cox.net> Argent Stonecutter wrote: > Where was this originally posted? I don't recall seeing this... if it > was posted here it must have been a long time ago. > >> Enforce a license such that anyone who wants to develop assets for SL >> and use SL IP must either sell their assets through your marketplace >> or use advertising partnerships via your marketplace if they're going >> to use advertising as their source of revenue. > > What on earth does this have to do with open source? Nothing with that > kind of limitation on it can be described as "open source" in any sense. > Commercial artistic content can be made using opensource or closed source applications. I don't think its a relevant issue, either way. Lawson From carjay at gmx.net Sun Aug 24 05:00:01 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Aug 24 05:00:10 2008 Subject: [sldev] [VWR] Viewer Performance Issues, VertexShaderEnable not found on feature list In-Reply-To: <71d0a1670808231730p963fabbpe4e03809ac697d34@mail.gmail.com> References: <71d0a1670808231730p963fabbpe4e03809ac697d34@mail.gmail.com> Message-ID: <48B14D41.8000005@gmx.net> Hello Gonta, I've been using both release, viewer_1-21 and the previous versions and spot no difference. What graphics card are you using? Carsten Gonta wrote: > I've been getting terrible performance on builds of the latest SVN > releases of the trunk and viewer_1-21 with release configurations. Is > anyone else is getting dismal performance out of these in comparison > to official builds; Whether it's just the release or specific to me? > > llfeaturemanager.ccp's > "LLFeatureList::isFeatureAvailable Feature VertexShaderEnable not on > feature list!" > > WinXP, using VS2005 Pro > FPS 5- compared to 20+ on official, (Sluggish performance all-over) > > -gonta > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From jpirkola at gmail.com Sun Aug 24 09:43:49 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Sun Aug 24 09:43:53 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <48B0D277.2060100@cox.net> References: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> <48B0D277.2060100@cox.net> Message-ID: <9291786d0808240943i7c8665f9t6f7899cea7078ad9@mail.gmail.com> Hi, I have attended a few AWGs myself and people from realXtend some of the others, but I admit that we haven't been around too much. I hope we can change that soonish. For the OGP work, I wonder what is the point for realXtend to join that. If people are using standard SL Viewer, they will see realXtend worlds just as they would see OpenSim - which is not good as realXtend supports 3D meshes and free form avatars. If people use realXtend viewer, they can already teleport between OpenSim, realXtend and Second Life. There is an address bar in the viewer for that. Now people can transfer their assets between realXtend worlds. The next step for AWG (from realXtend point of view) would be to get OGRE rendering support to official SL Viewer. Only then it starts to make sense to use SL Viewer and use it to teleport between realXtend and Second Life. The discussion about licensing content and how it can be transferred from SL to OpenSim/realXtend and back is of course really relevant. Best regards, Jani 2008/8/24 Lawson English > Jani Pirkola wrote: > >> FYI >> >> ---------- Forwarded message ---------- >> From: *Antti Ilom?ki* > antti.ilomaki@gmail.com>> >> Date: 2008/8/22 >> Subject: Global inventory tests successful >> To: realxtend@googlegroups.com >> >> >> >> We took another step towards the 3D Internet today, as we managed to >> transport objects from one site to another. These were just initial >> tests and only prims were tested, but it's sort of a historical >> moment. >> >> You've all probably already read the story on the realXtend blog, but >> here's the link: http://realxtend.blogspot.com/ >> >> Great stuff. I hope you're keeping track of the gridnauts/Open Grid > Public Beta and will be willing to give advice on how to make the OGP work > as well with realXtend worlds as it does with OpenSim... > > ...well, better, we hope, since even with OpenSim, the OGP still needs a > lot of work. > > > In the next week or so, us Pythonistas hope to have the pyogp library > refactored and functioning to work with the currently defined protocols of > the OGP. and Tao Takashi hopes to get his python agent domain handling > teleport soon as well. At that point, perhaps you guys can start making sure > it works with realkXtend worlds, and give us input on where the OGP and > pyogp should be going next. > > And I know we are never sure if any of the realXtend folk are attending AWG > meetings or the Linden office hours. I think we all would love to hear more > about what you're doing if you want to speak up at the meetings. > > Lawson (Saijanai Kuhn) > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080824/272acd49/attachment.htm From lenglish5 at cox.net Sun Aug 24 10:20:32 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 10:20:34 2008 Subject: [sldev] realXtend Global inventory tests successful In-Reply-To: <9291786d0808240943i7c8665f9t6f7899cea7078ad9@mail.gmail.com> References: <9291786d0808220701x666dc09bq508b8851a133794e@mail.gmail.com> <48B0D277.2060100@cox.net> <9291786d0808240943i7c8665f9t6f7899cea7078ad9@mail.gmail.com> Message-ID: <48B19860.6010104@cox.net> Jani Pirkola wrote: > Hi, > > I have attended a few AWGs myself and people from realXtend some of > the others, but I admit that we haven't been around too much. > I hope we can change that soonish. > > For the OGP work, I wonder what is the point for realXtend to join > that. If people are using standard SL Viewer, they will see realXtend > worlds just as they would see OpenSim - which is not good as realXtend > supports 3D meshes and free form avatars. > If people use realXtend viewer, they can already teleport between > OpenSim, realXtend and Second Life. There is an address bar in the > viewer for that. Now people can transfer their assets between > realXtend worlds. > > The next step for AWG (from realXtend point of view) would be to get > OGRE rendering support to official SL Viewer. Only then it starts to > make sense to use SL Viewer and use it to teleport between realXtend > and Second Life. > > The discussion about licensing content and how it can be transferred > from SL to OpenSim/realXtend and back is of course really relevant. > > Best regards, > Jani So you're not planning on using the Agent Domain model for universal logins? Lawson From sean at lindenlab.com Sun Aug 24 10:53:21 2008 From: sean at lindenlab.com (Sean Linden) Date: Sun Aug 24 10:53:23 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) Message-ID: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> On Sat, Aug 23, 2008 at 8:23 PM, Lawson English wrote: > Gareth Nelson wrote: > >> Surely the permissions flags constitute a form of license? >> >> Aside from this, what's wrong with a new "transfer to other grids" flag? >> >> >> > > Many of us want to see that. Problem is that neither Zero or any other > technical Linden can speak for LInden Lab about what they're going to do > until the lawyers are consulted, etc. > > BUT, before LL comes to a decision about how LL will handle its own > database of user-created assets, we can still experiment with a dedicated > server or two, to see what makes sense, both tethnically and from a user's > point off view. > Personally, I think any flag that's not attached to some technological protection mechanism will only result in confusion. For this particular case, the flag could be "exportable" and it could be used to allow the owner to get a cap to be able to download the asset itself directly, perhaps translated to some XML export format by a web service. This is just speculation of course; I'm not working on anything in this particular area (I'm currently testing the new garbage collector -- don't worry we won't delete anything until we KNOW it's not referenced). For everything not directly attached to some technological protection mechanism, it seems like just a URL specifying the license, along with concerted efforts to minimize the number of licenses people use, would a flexible and universal mechanism to tell people what they're allowed to do with stuff. Perhaps there could be a blanket "minimum" license to allow distributing stuff in each grid, though I don't know whether such a thing is necessary. "Minimum" would mean that if something has the copy flag it doesn't matter if the license says they can't have more than one copy; the copy flag trumps. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080824/155708cc/attachment.htm From gareth at litesim.com Sun Aug 24 10:59:16 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 24 10:59:18 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> Message-ID: <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> Here's the thing: A human-readable URL is precisely that - human readable. But a flag is machine-readable, and thus gives a means to automate checking in tools for cross-grid transfer. I know that this would be incredibly useful for my own efforts at least, as my current approach is basically "IM creator with bot, ask consent with a yes/no, upon yes complete export" and this does not scale very well. On Sun, Aug 24, 2008 at 6:53 PM, Sean Linden wrote: > On Sat, Aug 23, 2008 at 8:23 PM, Lawson English wrote: >> >> Gareth Nelson wrote: >>> >>> Surely the permissions flags constitute a form of license? >>> >>> Aside from this, what's wrong with a new "transfer to other grids" flag? >>> >>> >> >> Many of us want to see that. Problem is that neither Zero or any other >> technical Linden can speak for LInden Lab about what they're going to do >> until the lawyers are consulted, etc. >> >> BUT, before LL comes to a decision about how LL will handle its own >> database of user-created assets, we can still experiment with a dedicated >> server or two, to see what makes sense, both tethnically and from a user's >> point off view. > > Personally, I think any flag that's not attached to some technological > protection mechanism will only result in confusion. For this particular > case, the flag could be "exportable" and it could be used to allow the owner > to get a cap to be able to download the asset itself directly, perhaps > translated to some XML export format by a web service. This is just > speculation of course; I'm not working on anything in this particular area > (I'm currently testing the new garbage collector -- don't worry we won't > delete anything until we KNOW it's not referenced). > > For everything not directly attached to some technological protection > mechanism, it seems like just a URL specifying the license, along with > concerted efforts to minimize the number of licenses people use, would a > flexible and universal mechanism to tell people what they're allowed to do > with stuff. Perhaps there could be a blanket "minimum" license to allow > distributing stuff in each grid, though I don't know whether such a thing is > necessary. "Minimum" would mean that if something has the copy flag it > doesn't matter if the license says they can't have more than one copy; the > copy flag trumps. > > > > From GordonWendt at gmail.com Sun Aug 24 11:08:20 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun Aug 24 11:08:25 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> Message-ID: <493033a70808241108q3fcea93ajd137a61e0d6e60f1@mail.gmail.com> Sean, for what you're talking about though you'd probably need a third party (with multiple grids and content coming from each grid no single grid purveyor can be trusted to hold the keys) not to mention a much broader and much more reasonable flag and tag system for content for both permissions but also to make it clear who made it, on which grid, when, what permissions they put on it (slightly ot: I'd really like at least some first sale rights to be implemented since the person who's sold the object has 0 rights now unless the creator gives them which is illogical) and when those rights were put on the object, I'd also like to see a chain of ownership and if any a change of rights over the history of the object implemented and think that would be vital for any cross grid transfers as well. - -G.W. On Sun, Aug 24, 2008 at 1:53 PM, Sean Linden wrote: > > > Personally, I think any flag that's not attached to some technological > protection mechanism will only result in confusion. For this particular > case, the flag could be "exportable" and it could be used to allow the owner > to get a cap to be able to download the asset itself directly, perhaps > translated to some XML export format by a web service. This is just > speculation of course; I'm not working on anything in this particular area > (I'm currently testing the new garbage collector -- don't worry we won't > delete anything until we KNOW it's not referenced). > > For everything not directly attached to some technological protection > mechanism, it seems like just a URL specifying the license, along with > concerted efforts to minimize the number of licenses people use, would a > flexible and universal mechanism to tell people what they're allowed to do > with stuff. Perhaps there could be a blanket "minimum" license to allow > distributing stuff in each grid, though I don't know whether such a thing is > necessary. "Minimum" would mean that if something has the copy flag it > doesn't matter if the license says they can't have more than one copy; the > copy flag trumps. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080824/03f01b54/attachment-0001.htm From lenglish5 at cox.net Sun Aug 24 11:24:36 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 11:24:39 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> Message-ID: <48B1A764.8030707@cox.net> Sean Linden wrote: > On Sat, Aug 23, 2008 at 8:23 PM, Lawson English > wrote: > > Gareth Nelson wrote: > > Surely the permissions flags constitute a form of license? > > Aside from this, what's wrong with a new "transfer to other > grids" flag? > > > > > Many of us want to see that. Problem is that neither Zero or any > other technical Linden can speak for LInden Lab about what they're > going to do until the lawyers are consulted, etc. > > BUT, before LL comes to a decision about how LL will handle its > own database of user-created assets, we can still experiment with > a dedicated server or two, to see what makes sense, both > tethnically and from a user's point off view. > > > Personally, I think any flag that's not attached to some technological > protection mechanism will only result in confusion. For this > particular case, the flag could be "exportable" and it could be used > to allow the owner to get a cap to be able to download the asset > itself directly, perhaps translated to some XML export format by a web > service. At the level where the automated decision is made to release assets to other regions, that form of protection will be built into anything that LL does, I am certain. However, the issues of trust, permissions, licensing, etc., are quite complicated, as I've pointed out, and Zero's stated goal for the AWG is to create a protocol that can accommodate multiple models, including whatever LL decides to go with for assets held in the Second LIfe asset servers. The other part of the equation is how to ensure compliance on the part of regions that accept such protected assets and what to do if they don't follow their own agreements with the source of the protected assets. [...] > For everything not directly attached to some technological protection > mechanism, it seems like just a URL specifying the license, along with > concerted efforts to minimize the number of licenses people use, would > a flexible and universal mechanism to tell people what they're allowed > to do with stuff. Perhaps there could be a blanket "minimum" license > to allow distributing stuff in each grid, though I don't know whether > such a thing is necessary. "Minimum" would mean that if something has > the copy flag it doesn't matter if the license says they can't have > more than one copy; the copy flag trumps. > That goes against the current policy of LL as far as assets currently stored on the LL asset servers are concerned and I suspect, what anyone would expect about new assets (or current ones) designated as available for the open grid (or some specific subset that has agreements/contracts with LL concerning intellectual property). In all cases, as I understand it, copyright law says that the intent of the creator trumps other concerns as far as what is legally allowed for redistribution. Any automated system that LL puts into place will have to automatically enforce creator's intent as far the mechanics of redistribution goes or they will be in big trouble, and any redistribution agreement that LL makes with other grids will need to require that the other grid enforce the automated permission system as well. It may be possible that some expressions of owner's intent will be too complicated to put into the automated distribution system, but that can be accommodated simply by setting a flag saying "don't release to other grids," which would forbid LL's asset servers from redistributing those assets at all. Lawson Lawson From lenglish5 at cox.net Sun Aug 24 11:46:51 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 11:46:53 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> Message-ID: <48B1AC9B.4090700@cox.net> Gareth Nelson wrote: > Here's the thing: A human-readable URL is precisely that - human > readable. But a flag is machine-readable, and thus gives a means to > automate checking in tools for cross-grid transfer. I know that this > would be incredibly useful for my own efforts at least, as my current > approach is basically "IM creator with bot, ask consent with a yes/no, > upon yes complete export" and this does not scale very well. > > I absolutely agree, and I susptect that most Lindens involved in the technical side do as well. But that's the issue: they aren't setting policy, so to even react favorably in public to such a scheme implies that it is what LL policy will look like. Zero said on the Metanomics interview a few weeks ago that there has been enough discussion tin the past year exploring the technical, legal, economic, social, etc ramifications of open grid permissions that they can now start a discussion about the specifics of what LL should do and what a more universal protocol for permissions should look like in order to accommodate LL's needs and the needs of a large subset of the other models for intellectual property permissions that other virtual worlds might choose to use instead. http://metanomics.net/archive080408 http://www.metanomics.net/transcript080408 [...] "MARK LENTCZNER: From Linden?s end, we intend, in the same way in which I have been holding open office hours for the last year, on the technical side of it, to begin to hold a series of forum and a series of conduits for information from people. I?ve been working with some other people inside the community group, inside Linden Lab, to begin to set those up. I know it might have felt like this was a technocracy where we started, but do recognize there was a tremendous amount of technical framework that had to get laid down before we could even get to the point of actually having a rational discussion about what the options were, and we are now approximately at that point. I expect this fall for those forums to begin to open up and to become available, at least ones that Linden will hold, in the same way that Linden started the technical forum, the AWG in my office hours. We highly encourage, just like the AWG existed, that other groups also form forums in which these things can be discussed and looked at. The one thing I will put forth is, remember for us to think about this as a discussion. This is something that needs to be looked at. It isn?t a debate. There aren?t two sides. We need to look at and discuss and explore how to go about doing this as Virtual Worlds grow, and that?s what we want to have. On the one hand, is involving discussion, and I think that?s what we?re going to have to help facilitate." Lawson From darien.caldwell at gmail.com Sun Aug 24 11:55:30 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sun Aug 24 11:55:34 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B1AC9B.4090700@cox.net> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> Message-ID: <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> I don't know how Mark can seriously say 'This isn't a debate." It will be a debate as long as you have one side expounding on having everything full perms because 'it's already stolen anyway", versus those who want reasonable protections in the middle, versus those who want Encrypted Everything in a Black Box extremists. It will cease being a debate when Linden Lab finally outlines exactly what they intend to do and how they intend to do it. That hasn't happened yet. On 8/24/08, Lawson English wrote: > Gareth Nelson wrote: >> Here's the thing: A human-readable URL is precisely that - human >> readable. But a flag is machine-readable, and thus gives a means to >> automate checking in tools for cross-grid transfer. I know that this >> would be incredibly useful for my own efforts at least, as my current >> approach is basically "IM creator with bot, ask consent with a yes/no, >> upon yes complete export" and this does not scale very well. >> >> > > I absolutely agree, and I susptect that most Lindens involved in the > technical side do as well. > > But that's the issue: they aren't setting policy, so to even react > favorably in public to such a scheme implies that it is > what LL policy will look like. > > > Zero said on the Metanomics interview a few weeks ago that there has > been enough discussion tin the past year exploring the technical, legal, > economic, social, etc ramifications of open grid permissions that they > can now start a discussion about the specifics of what LL should do and > what a more universal protocol for permissions should look like in order > to accommodate LL's needs and the needs of a large subset of the other > models for intellectual property permissions that other virtual worlds > might choose to use instead. > > http://metanomics.net/archive080408 > http://www.metanomics.net/transcript080408 > > [...] > > "MARK LENTCZNER: From Linden's end, we intend, in the same way in which > I have been holding open office hours for the last year, on the > technical side of it, to begin to hold a series of forum and a series of > conduits for information from people. I've been working with some other > people inside the community group, inside Linden Lab, to begin to set > those up. I know it might have felt like this was a technocracy where we > started, but do recognize there was a tremendous amount of technical > framework that had to get laid down before we could even get to the > point of actually having a rational discussion about what the options > were, and we are now approximately at that point. > I expect this fall for those forums to begin to open up and to become > available, at least ones that Linden will hold, in the same way that > Linden started the technical forum, the AWG in my office hours. We > highly encourage, just like the AWG existed, that other groups also form > forums in which these things can be discussed and looked at. > The one thing I will put forth is, remember for us to think about this > as a discussion. This is something that needs to be looked at. It isn't > a debate. There aren't two sides. We need to look at and discuss and > explore how to go about doing this as Virtual Worlds grow, and that's > what we want to have. On the one hand, is involving discussion, and I > think that's what we're going to have to help facilitate." > > > > Lawson > > > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From gareth at litesim.com Sun Aug 24 12:15:11 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 24 12:15:15 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> Message-ID: <61dbdd7d0808241215s2c1cded9l92632a9b198e0815@mail.gmail.com> Give this man an orange! It's rather pointless debating this until LL give the official "word". On Sun, Aug 24, 2008 at 7:55 PM, Darien Caldwell wrote: > I don't know how Mark can seriously say 'This isn't a debate." It > will be a debate as long as you have one side expounding on having > everything full perms because 'it's already stolen anyway", versus > those who want reasonable protections in the middle, versus those who > want Encrypted Everything in a Black Box extremists. > > It will cease being a debate when Linden Lab finally outlines exactly > what they intend to do and how they intend to do it. That hasn't > happened yet. > > On 8/24/08, Lawson English wrote: >> Gareth Nelson wrote: >>> Here's the thing: A human-readable URL is precisely that - human >>> readable. But a flag is machine-readable, and thus gives a means to >>> automate checking in tools for cross-grid transfer. I know that this >>> would be incredibly useful for my own efforts at least, as my current >>> approach is basically "IM creator with bot, ask consent with a yes/no, >>> upon yes complete export" and this does not scale very well. >>> >>> >> >> I absolutely agree, and I susptect that most Lindens involved in the >> technical side do as well. >> >> But that's the issue: they aren't setting policy, so to even react >> favorably in public to such a scheme implies that it is >> what LL policy will look like. >> >> >> Zero said on the Metanomics interview a few weeks ago that there has >> been enough discussion tin the past year exploring the technical, legal, >> economic, social, etc ramifications of open grid permissions that they >> can now start a discussion about the specifics of what LL should do and >> what a more universal protocol for permissions should look like in order >> to accommodate LL's needs and the needs of a large subset of the other >> models for intellectual property permissions that other virtual worlds >> might choose to use instead. >> >> http://metanomics.net/archive080408 >> http://www.metanomics.net/transcript080408 >> >> [...] >> >> "MARK LENTCZNER: From Linden's end, we intend, in the same way in which >> I have been holding open office hours for the last year, on the >> technical side of it, to begin to hold a series of forum and a series of >> conduits for information from people. I've been working with some other >> people inside the community group, inside Linden Lab, to begin to set >> those up. I know it might have felt like this was a technocracy where we >> started, but do recognize there was a tremendous amount of technical >> framework that had to get laid down before we could even get to the >> point of actually having a rational discussion about what the options >> were, and we are now approximately at that point. >> I expect this fall for those forums to begin to open up and to become >> available, at least ones that Linden will hold, in the same way that >> Linden started the technical forum, the AWG in my office hours. We >> highly encourage, just like the AWG existed, that other groups also form >> forums in which these things can be discussed and looked at. >> The one thing I will put forth is, remember for us to think about this >> as a discussion. This is something that needs to be looked at. It isn't >> a debate. There aren't two sides. We need to look at and discuss and >> explore how to go about doing this as Virtual Worlds grow, and that's >> what we want to have. On the one hand, is involving discussion, and I >> think that's what we're going to have to help facilitate." >> >> >> >> Lawson >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From ordinal.malaprop at fastmail.fm Sun Aug 24 12:40:00 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sun Aug 24 12:40:03 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B1AC9B.4090700@cox.net> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> Message-ID: <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> On 24 Aug 2008, at 19:46, Lawson English wrote: > I know it might have felt like this was a technocracy where we > started, but do recognize there was a tremendous amount of technical > framework that had to get laid down before we could even get to the > point of actually having a rational discussion about what the > options were, and we are now approximately at that point. The thing is of course that requirements _always_ come before technical specs. Or should do. From lenglish5 at cox.net Sun Aug 24 12:20:17 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 12:43:00 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> Message-ID: <48B1B471.5070704@cox.net> Darien Caldwell wrote: > I don't know how Mark can seriously say 'This isn't a debate." It > will be a debate as long as you have one side expounding on having > everything full perms because 'it's already stolen anyway", versus > those who want reasonable protections in the middle, versus those who > want Encrypted Everything in a Black Box extremists. > > It will cease being a debate when Linden Lab finally outlines exactly > what they intend to do and how they intend to do it. That hasn't > happened yet. > Well, its not a debate because: 1) LL almost certainly isn't going to implement either extreme; 2) the OGP protocols will be designed to ALLOW such extremes if some grid operator wats to implement them. Lawson From lenglish5 at cox.net Sun Aug 24 12:46:22 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 12:46:34 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <61dbdd7d0808241215s2c1cded9l92632a9b198e0815@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <835a5b860808241155h7936262cg35dfc18796c2dd31@mail.gmail.com> <61dbdd7d0808241215s2c1cded9l92632a9b198e0815@mail.gmail.com> Message-ID: <48B1BA8E.4090904@cox.net> Gareth Nelson wrote: > Give this man an orange! > It's rather pointless debating this until LL give the official "word". > > The point is that the OGP will accommodate what LL plans on doing PLUS other solutions (including nothing at all concerning intellectual property protection). Grid implementers and meta-grid implementers will pick and choose what they want to do within the wide range of choices offered by the OGP. Hopefully, we'll cover the most commonly desired cases, not just the extremes and LL's specific solution (whatever it turns out to be). Lawson From lenglish5 at cox.net Sun Aug 24 12:56:05 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 12:56:09 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> Message-ID: <48B1BCD5.5070803@cox.net> ordinal.malaprop@fastmail.fm wrote: > > On 24 Aug 2008, at 19:46, Lawson English wrote: > >> I know it might have felt like this was a technocracy where we >> started, but do recognize there was a tremendous amount of technical >> framework that had to get laid down before we could even get to the >> point of actually having a rational discussion about what the options >> were, and we are now approximately at that point. > > The thing is of course that requirements _always_ come before > technical specs. Or should do. > Sure. But in this case, the problem space wasn't even remotely well-defined, so trying to determine the "requirements" was like putting the horse before the cart when you didn't even know what a cart looked like, or the horse, for that matter. Lawson From secret.argent at gmail.com Sun Aug 24 13:04:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 24 13:04:20 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> Message-ID: On 2008-08-24, at 12:53, Sean Linden wrote: > For everything not directly attached to some technological > protection mechanism, it seems like just a URL specifying the > license, along with concerted efforts to minimize the number of > licenses people use, would a flexible and universal mechanism to > tell people what they're allowed to do with stuff. There's been content in SL broken already when someone quit maintaining the website serving it, so I don't think that any mechanism that involves storing the license outside SL is a good idea. From ordinal.malaprop at fastmail.fm Sun Aug 24 13:13:55 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sun Aug 24 13:14:00 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B1BCD5.5070803@cox.net> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> <48B1BCD5.5070803@cox.net> Message-ID: <531185BE-2938-4EF3-8FEA-D6A6B10222A1@fastmail.fm> On 24 Aug 2008, at 20:56, Lawson English wrote: > ordinal.malaprop@fastmail.fm wrote: >> >> On 24 Aug 2008, at 19:46, Lawson English wrote: >> >>> I know it might have felt like this was a technocracy where we >>> started, but do recognize there was a tremendous amount of >>> technical framework that had to get laid down before we could even >>> get to the point of actually having a rational discussion about >>> what the options were, and we are now approximately at that point. >> >> The thing is of course that requirements _always_ come before >> technical specs. Or should do. >> > Sure. But in this case, the problem space wasn't even remotely well- > defined, so trying to determine the "requirements" > was like putting the horse before the cart when you didn't even know > what a cart looked like, or the horse, for that matter. I think that we did all know what the cart and horse looked like. Well, I don't want to stretch the metaphor too far - we knew what the desired outcome was, or at least, we were quite capable of coming to what the desired outcome was without reference to anything technical, because the desired outcome was not a technical one, rather concerned with how and when assets were distributed. Technical frameworks are what one develops _after_ the desired outcome has been decided on; technology is the slave of desire. Perhaps it might turn out that the desired outcome is technically impossible, in which case the specifications need to be revised. But they always need to come first. From lenglish5 at cox.net Sun Aug 24 13:21:48 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 24 13:21:50 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <531185BE-2938-4EF3-8FEA-D6A6B10222A1@fastmail.fm> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> <48B1BCD5.5070803@cox.net> <531185BE-2938-4EF3-8FEA-D6A6B10222A1@fastmail.fm> Message-ID: <48B1C2DC.80106@cox.net> ordinal.malaprop@fastmail.fm wrote: > > On 24 Aug 2008, at 20:56, Lawson English wrote: > >> ordinal.malaprop@fastmail.fm wrote: >>> >>> On 24 Aug 2008, at 19:46, Lawson English wrote: >>> >>>> I know it might have felt like this was a technocracy where we >>>> started, but do recognize there was a tremendous amount of >>>> technical framework that had to get laid down before we could even >>>> get to the point of actually having a rational discussion about >>>> what the options were, and we are now approximately at that point. >>> >>> The thing is of course that requirements _always_ come before >>> technical specs. Or should do. >>> >> Sure. But in this case, the problem space wasn't even remotely >> well-defined, so trying to determine the "requirements" >> was like putting the horse before the cart when you didn't even know >> what a cart looked like, or the horse, for that matter. > > I think that we did all know what the cart and horse looked like. > Well, I don't want to stretch the metaphor too far - we knew what the > desired outcome was, or at least, we were quite capable of coming to > what the desired outcome was without reference to anything technical, > because the desired outcome was not a technical one, rather concerned > with how and when assets were distributed. > > Technical frameworks are what one develops _after_ the desired outcome > has been decided on; technology is the slave of desire. Perhaps it > might turn out that the desired outcome is technically impossible, in > which case the specifications need to be revised. But they always need > to come first. > At best, we knew what *A* cart and *A* horse looked like, but the OGP is supposed to accommodate a number of different carts and horses, if you want to continue with this, and we weren't even sure if the current cart and horse would work in the larger metaverse. We're still not sure, but at last we've discussed discussed more fully the terrain that our favorite cart and horse might need to face... Lawson From ordinal.malaprop at fastmail.fm Sun Aug 24 13:39:25 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Sun Aug 24 13:39:32 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B1C2DC.80106@cox.net> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> <48B1BCD5.5070803@cox.net> <531185BE-2938-4EF3-8FEA-D6A6B10222A1@fastmail.fm> <48B1C2DC.80106@cox.net> Message-ID: <6637C9CC-B31E-489F-B972-66C551CE5626@fastmail.fm> On 24 Aug 2008, at 21:21, Lawson English wrote: > ordinal.malaprop@fastmail.fm wrote: >> >> On 24 Aug 2008, at 20:56, Lawson English wrote: >> >>> ordinal.malaprop@fastmail.fm wrote: >>>> >>>> On 24 Aug 2008, at 19:46, Lawson English wrote: >>>> >>>>> I know it might have felt like this was a technocracy where we >>>>> started, but do recognize there was a tremendous amount of >>>>> technical framework that had to get laid down before we could >>>>> even get to the point of actually having a rational discussion >>>>> about what the options were, and we are now approximately at >>>>> that point. >>>> >>>> The thing is of course that requirements _always_ come before >>>> technical specs. Or should do. >>>> >>> Sure. But in this case, the problem space wasn't even remotely >>> well-defined, so trying to determine the "requirements" >>> was like putting the horse before the cart when you didn't even >>> know what a cart looked like, or the horse, for that matter. >> >> I think that we did all know what the cart and horse looked like. >> Well, I don't want to stretch the metaphor too far - we knew what >> the desired outcome was, or at least, we were quite capable of >> coming to what the desired outcome was without reference to >> anything technical, because the desired outcome was not a technical >> one, rather concerned with how and when assets were distributed. >> >> Technical frameworks are what one develops _after_ the desired >> outcome has been decided on; technology is the slave of desire. >> Perhaps it might turn out that the desired outcome is technically >> impossible, in which case the specifications need to be revised. >> But they always need to come first. >> > At best, we knew what *A* cart and *A* horse looked like, but the > OGP is supposed to accommodate a number of different carts and > horses, if you want to continue with this, and we weren't even sure > if the current cart and horse would work in the larger metaverse. > We're still not sure, but at last we've discussed discussed more > fully the terrain that our favorite cart and horse might need to > face... > Well, why not, it is entertaining enough. What I see is a lot of cart-makers and horse-breeders discussing what sort of carts and horses they think are appropriate, and then, once they've decided on that, presenting their models and breeds to the wider cart/horse-using community. Who may well then say "hold on a second, that cart won't haul turnips at all, and I want to move turnips from one place to another". (Or, in this instance, perhaps "that cart will haul any sort of turnip, and I only want my turnips going to certain people".) This is the wrong way around. Functional specifications (merchant turnip-moving desires) should always, always, under every circumstance ever no matter what, be developed before technical ones (cart + horse turnip-moving solutions) and the latter should come from the former. Unless one is developing both functional and technical specs as the same person, which is still relatively rare, it just can't work otherwise. From secret.argent at gmail.com Sun Aug 24 14:07:05 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 24 14:06:43 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <6637C9CC-B31E-489F-B972-66C551CE5626@fastmail.fm> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B1AC9B.4090700@cox.net> <160AF674-91B6-40F2-AFB7-BBBC2731E176@fastmail.fm> <48B1BCD5.5070803@cox.net> <531185BE-2938-4EF3-8FEA-D6A6B10222A1@fastmail.fm> <48B1C2DC.80106@cox.net> <6637C9CC-B31E-489F-B972-66C551CE5626@fastmail.fm> Message-ID: <0DA8F3E5-C28A-44AF-AEBD-0F93CDB8D662@gmail.com> On 2008-08-24, at 15:39, ordinal.malaprop@fastmail.fm wrote: > This is the wrong way around. Functional specifications (merchant > turnip-moving desires) should always, always, under every > circumstance ever no matter what, be developed before technical > ones (cart + horse turnip-moving solutions) and the latter should > come from the former. Unless one is developing both functional and > technical specs as the same person, which is still relatively rare, > it just can't work otherwise. The problem is there's multiple groups of turnip-makers, and some of them want things that can't be made and don't want to listen to anyone who's trying to tell them that, and others don't want anyone to have anything but the rocket-powered unrestricted sports-cart even if they happen to think stop signs and speed bumps are kinda useful. So there's a lot of folks going "hey, you know, if we take this cart we already have, you can kind of make it work...". From gigstaggart at gmail.com Sun Aug 24 18:05:15 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 24 18:05:19 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> Message-ID: <48B2054B.5000306@gmail.com> Gareth Nelson wrote: > Here's the thing: A human-readable URL is precisely that - human > readable. But a flag is machine-readable, and thus gives a means to > automate checking in tools for cross-grid transfer. I know that this > would be incredibly useful for my own efforts at least, as my current > approach is basically "IM creator with bot, ask consent with a yes/no, > upon yes complete export" and this does not scale very well. > There is no possible way for a computer to correctly enforce something as complex as a copyright license and the nuances of fair use, even if DRM did work. The human brain is a much better tool for doing that, and should be used instead of computers. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080824/8f41d0b4/smime.bin From gareth at litesim.com Sun Aug 24 18:27:37 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 24 18:27:40 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B2054B.5000306@gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B2054B.5000306@gmail.com> Message-ID: <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> That was precisely my point, a computer can't parse a license expressed as natural language (at least this side of the singularity ;)), but it can parse single flags. As for whether it actually enforces anything: no, it doesn't at all. However, it would be nice to have a much clearer way to determine author intent which automated tools can use. I still haven't contacted the person who made my glorious flexiprim hair to confirm whether I can export it, and a simple flag would make this task much easier. (The flexiprim hair is of course but one thing i'd dearly love to export). On Mon, Aug 25, 2008 at 2:05 AM, Jason Giglio wrote: > Gareth Nelson wrote: >> Here's the thing: A human-readable URL is precisely that - human >> readable. But a flag is machine-readable, and thus gives a means to >> automate checking in tools for cross-grid transfer. I know that this >> would be incredibly useful for my own efforts at least, as my current >> approach is basically "IM creator with bot, ask consent with a yes/no, >> upon yes complete export" and this does not scale very well. >> > > There is no possible way for a computer to correctly enforce something > as complex as a copyright license and the nuances of fair use, even if > DRM did work. > > The human brain is a much better tool for doing that, and should be used > instead of computers. > > -Jason > From gigstaggart at gmail.com Sun Aug 24 21:15:12 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 24 21:15:17 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B2054B.5000306@gmail.com> <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> Message-ID: <48B231D0.60901@gmail.com> Gareth Nelson wrote: > can export it, and a simple flag would make this task much easier. > (The flexiprim hair is of course but one thing i'd dearly love to > export). A flag that the creator sets does not take into account what rights the user has. There are fair use rights, compulsory licensing rights, or the original source material might be in the public domain. The user might even live in a place where there are no copyright laws. A flag that the creator/uploader sets can never express the rights of the user accurately. Only the user can decide what they have the right to do, and how much legal risk they want to take, just like in every other medium in existence. Sean is saying that if you create such a flag, but then don't put a technological measure behind it, people won't get it. I think so too. It's silly to pretend that this issue can be simplified down to a flag, That people want a flag created that has no technological weight behind it proves that the flag is inadequate. Just as the current permissions communicate the wrong thing about what is possible, a new "export" flag would continue down the path of miscommunication with users, pretending that copyright law can be boiled down to a few check boxes. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080825/e04eefd5/smime.bin From gbrandon at gmail.com Mon Aug 25 00:34:28 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Aug 25 00:34:30 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B231D0.60901@gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B2054B.5000306@gmail.com> <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> <48B231D0.60901@gmail.com> Message-ID: I am really glad to see talk of attaching real licenses to content. And can you imagine how great it would be if the browser software had a wizard or something, to assist users with generating a license? Just a few checkboxes or something, so people won't have to feel like they need to do a ton of research... what do you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/4398a36f/attachment.htm From gareth at litesim.com Mon Aug 25 01:56:35 2008 From: gareth at litesim.com (Gareth Nelson) Date: Mon Aug 25 01:56:38 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory tests successful) In-Reply-To: <48B231D0.60901@gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail.com> <48B2054B.5000306@gmail.com> <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> <48B231D0.60901@gmail.com> Message-ID: <61dbdd7d0808250156i78d147ecp4f5d87d46d32baf1@mail.gmail.com> > Just as the current permissions communicate the wrong thing about what > is possible, a new "export" flag would continue down the path of > miscommunication with users, pretending that copyright law can be boiled > down to a few check boxes. Following that chain of logic of course, one would need to scrap the permissions system completely and thus satisfy the paranoid stereotypes of us "evil techies" a certain blogger likes to spread. From ravenglassrentals at yahoo.com Mon Aug 25 02:13:08 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Mon Aug 25 02:13:11 2008 Subject: [sldev] Re: SLDev Digest, Vol 20, Issue 53 In-Reply-To: <20080825085642.8AE7D41AFC8@stupor.lindenlab.com> Message-ID: <437089.66152.qm@web55604.mail.re4.yahoo.com> Attaching written licenses, in the form of notecards, or links to URLs, is totally inadequate, especially of the Creative Commons type, that do not provide a substantial foundation for commerce, because they do not enable copying through *purchase* but only allow copying *through attribution only* -- a big drag on commerce, frankly. The flags have to be implemented in a mechanical way, so that they provide at least as much of an obstacle to raw copying as the current copy/mod/transfer regime does on objects. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/b94a85cf/attachment.htm From gareth at litesim.com Mon Aug 25 02:19:15 2008 From: gareth at litesim.com (Gareth Nelson) Date: Mon Aug 25 02:19:17 2008 Subject: [sldev] Re: SLDev Digest, Vol 20, Issue 53 In-Reply-To: <437089.66152.qm@web55604.mail.re4.yahoo.com> References: <20080825085642.8AE7D41AFC8@stupor.lindenlab.com> <437089.66152.qm@web55604.mail.re4.yahoo.com> Message-ID: <61dbdd7d0808250219s7fff1b44w1da7cad6389128c7@mail.gmail.com> Hi prok :) > Attaching written licenses, in the form of notecards, or links to URLs, is > totally inadequate I totally agree with this part..... >, especially of the Creative Commons type, that do not > provide a substantial foundation for commerce, because they do not enable > copying through *purchase* but only allow copying *through attribution only* > -- a big drag on commerce, frankly. CC licenses are not meant for commercial content, that should be obvious. They don't however form a "big drag on commerce" for various reasons. > The flags have to be implemented in a mechanical way, so that they provide > at least as much of an obstacle to raw copying as the current > copy/mod/transfer regime does on objects. What precisely does a "mechanical way" mean? By this I presume you mean simply "enforced by the code", in which case I don't think anyone's ever actually proposed permissions flags which are not enforced - indeed such a scheme would be rather pointless. From P.McEwan at sms.ed.ac.uk Mon Aug 25 09:26:54 2008 From: P.McEwan at sms.ed.ac.uk (P Mcewan) Date: Mon Aug 25 09:26:57 2008 Subject: [sldev] [help] TCP and Sockets: connecting to SL with another application Message-ID: <20080825172654.0yx9v75k4k0s0wg0@www.sms.ed.ac.uk> Hello there, After many searches through the Second Life viewer source code and the archived mailing list to no avail, I hope someone here would be able to guide me in the right direction :). I am attempting to have motion capture devices interface with SL to allow real-time movement of a user's agent through the players own movement. To do this, I am planning to use the "Puppeteering" version of the Viewer and, by manipulating the physical avatar joints, have the agent move with the player. In order to do this, I need to communicate with our group's program (MotionViewer or MV) which calculates the positions. To communicate with the motion capture program, I planned to do the following: - create a class which carries out the communication between SL and MV - have the class create a TCP socket and connect to a socket server run by MV on the localhost (and a specific port) - then, receive byte packets over the TCP connection from MV to SL specifying joint positions My attempts to do this so far have lead to dead-ends. Using a "LLSocket" object, I have been able to have SL connect to MV's server socket, but have no idea how to then receive packets (I had assumed using "LLSocketReader", but this does not seem quite right). I also tried using "net.h", but could not connect and feel this isn't quite right either. Searching through the source file seems to get me no further forward, so I was wondering if anyone knows a clean way I can do this? I had hoped there was some for of library Linden Labs used, as I really don't want to have to use "socket.h" and have to worry about platform and such. Sorry for the long message, but any help you could give would be greatly appreciated! Thank you, Paul McEwan -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From dahliatrimble at gmail.com Mon Aug 25 09:38:21 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon Aug 25 09:38:25 2008 Subject: [sldev] [help] TCP and Sockets: connecting to SL with another application In-Reply-To: <20080825172654.0yx9v75k4k0s0wg0@www.sms.ed.ac.uk> References: <20080825172654.0yx9v75k4k0s0wg0@www.sms.ed.ac.uk> Message-ID: Have you considered the (in the process of being renamed) libsecondlife? http://www.libsecondlife.org/wiki/Main_Page On Mon, Aug 25, 2008 at 9:26 AM, P Mcewan wrote: > Hello there, > > After many searches through the Second Life viewer source code and the > archived mailing > list to no avail, I hope someone here would be able to guide me in the > right direction :). > > I am attempting to have motion capture devices interface with SL to allow > real-time > movement of a user's agent through the players own movement. To do this, I > am planning to > use the "Puppeteering" version of the Viewer and, by manipulating the > physical avatar > joints, have the agent move with the player. In order to do this, I need to > communicate > with our group's program (MotionViewer or MV) which calculates the > positions. > > To communicate with the motion capture program, I planned to do the > following: > - create a class which carries out the communication between SL and MV > - have the class create a TCP socket and connect to a socket server run by > MV on the > localhost (and a specific port) > - then, receive byte packets over the TCP connection from MV to SL > specifying joint > positions > > My attempts to do this so far have lead to dead-ends. Using a "LLSocket" > object, I have > been able to have SL connect to MV's server socket, but have no idea how to > then receive > packets (I had assumed using "LLSocketReader", but this does not seem quite > right). I > also tried using "net.h", but could not connect and feel this isn't quite > right either. > > Searching through the source file seems to get me no further forward, so I > was wondering > if anyone knows a clean way I can do this? I had hoped there was some for > of library > Linden Labs used, as I really don't want to have to use "socket.h" and have > to worry > about platform and such. > > Sorry for the long message, but any help you could give would be greatly > appreciated! > > Thank you, > > Paul McEwan > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/e057be0f/attachment.htm From soft at lindenlab.com Mon Aug 25 09:41:30 2008 From: soft at lindenlab.com (Soft) Date: Mon Aug 25 09:41:33 2008 Subject: [sldev] files missing from svn in maint-render-7? In-Reply-To: References: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> Message-ID: Hang tight - I'm told there's been a mistake in creating the current maint-viewer branch. I'm pinging to find out which really is the current development branch, and I'll update this thread after ensuring the correct one exports. On Sat, Aug 23, 2008 at 6:19 AM, Soft wrote: > maint-render-10 is out and most current. (Yes, there was no > maint-render-9.) You might try against that branch. If you have > specific need of the -7 branch, I remember that some other branches > were affected by missing exports on these files. I could track down > the fixes. > > On Sat, Aug 23, 2008 at 4:44 AM, azdel slade wrote: >> Ok, take 2 trying to compile with cmake. >> >> I got visual studio 2005 pro. I have to correct my staement yesterday, >> microsoft's "dreamspark" program does allow students to download >> visual studio 2008 an 2005. I must've tried to use visual C++ express >> to save download time. >> >> So while configuring with develop.py, I got an error about >> CMakeLists.txt for llrender and newview referring to cpp files that >> were missing. To be able to continue, I commented them out. But now, >> I'm getting linker errors, of course. Can folks direct me to where I >> should get these files from? >> >> The problem files are: >> >> llcubemap.cpp >> llpostprocess.cpp >> llrendersphere.cpp >> llshadermgr.cpp >> >> I double checked, trying to svn update, and still don't have these files. >> >> and I get these linker errors, as expected: >> >> Linking... >> llrender.lib(llrender.obj) : error LNK2001: unresolved external symbol >> "public: static bool LLCubeMap::sUseCubeMaps" >> (?sUseCubeMaps@LLCubeMap@@2_NA) >> llappviewer.obj : error LNK2001: unresolved external symbol "public: >> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >> "public: static bool LLCubeMap::sUseCubeMaps" >> (?sUseCubeMaps@LLCubeMap@@2_NA) >> llpaneldisplay.obj : error LNK2001: unresolved external symbol >> "public: static bool LLCubeMap::sUseCubeMaps" >> (?sUseCubeMaps@LLCubeMap@@2_NA) >> llvosky.obj : error LNK2001: unresolved external symbol "public: >> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >> llappviewer.obj : error LNK2019: unresolved external symbol "public: >> static void __cdecl LLPostProcess::cleanupClass(void)" >> (?cleanupClass@LLPostProcess@@SAXXZ) referenced in function "public: >> virtual bool __thiscall LLAppViewer::cleanup(void)" >> (?cleanup@LLAppViewer@@UAE_NXZ) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::enable(int)" >> (?enable@LLCubeMap@@QAEXH@Z) referenced in function "public: void >> __thiscall LLDrawPoolBump::beginShiny(bool)" >> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLCubeMap::enable(int)" >> (?enable@LLCubeMap@@QAEXH@Z) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::enableTextureCoords(int)" >> (?enableTextureCoords@LLCubeMap@@QAEXH@Z) referenced in function >> "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" >> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::enableTexture(int)" >> (?enableTexture@LLCubeMap@@QAEXH@Z) referenced in function "public: >> void __thiscall LLDrawPoolBump::beginShiny(bool)" >> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >> pipeline.obj : error LNK2001: unresolved external symbol "public: void >> __thiscall LLCubeMap::enableTexture(int)" >> (?enableTexture@LLCubeMap@@QAEXH@Z) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::setMatrix(int)" >> (?setMatrix@LLCubeMap@@QAEXH@Z) referenced in function "public: void >> __thiscall LLDrawPoolBump::beginShiny(bool)" >> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::restoreMatrix(void)" >> (?restoreMatrix@LLCubeMap@@QAEXXZ) referenced in function "public: >> void __thiscall LLDrawPoolBump::endShiny(bool)" >> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::disable(void)" >> (?disable@LLCubeMap@@QAEXXZ) referenced in function "public: void >> __thiscall LLDrawPoolBump::endShiny(bool)" >> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLCubeMap::disable(void)" >> (?disable@LLCubeMap@@QAEXXZ) >> lldrawpoolwater.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLCubeMap::bind(void)" >> (?bind@LLCubeMap@@QAEXXZ) referenced in function "public: virtual void >> __thiscall LLDrawPoolWater::render(int)" >> (?render@LLDrawPoolWater@@UAEXH@Z) >> llfloaterpostprocess.obj : error LNK2001: unresolved external symbol >> "class LLPostProcess * gPostProcess" >> (?gPostProcess@@3PAVLLPostProcess@@A) >> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLPostProcess::setSelectedEffect(class >> std::basic_string,class >> std::allocator > const &)" >> (?setSelectedEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >> referenced in function "public: static void __cdecl >> LLFloaterPostProcess::onLoadEffect(void *)" >> (?onLoadEffect@LLFloaterPostProcess@@SAXPAX@Z) >> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLPostProcess::saveEffect(class >> std::basic_string,class >> std::allocator > const &)" >> (?saveEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >> referenced in function "public: static void __cdecl >> LLFloaterPostProcess::onSaveEffect(void *)" >> (?onSaveEffect@LLFloaterPostProcess@@SAXPAX@Z) >> llglsandbox.obj : error LNK2019: unresolved external symbol "public: >> void __thiscall LLRenderSphere::render(float)" >> (?render@LLRenderSphere@@QAEXM@Z) referenced in function "public: void >> __thiscall LLAgent::renderAutoPilotTarget(void)" >> (?renderAutoPilotTarget@LLAgent@@QAEXXZ) >> llhudeffectbeam.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLRenderSphere::render(float)" >> (?render@LLRenderSphere@@QAEXM@Z) >> llviewerwindow.obj : error LNK2001: unresolved external symbol >> "public: void __thiscall LLRenderSphere::render(float)" >> (?render@LLRenderSphere@@QAEXM@Z) >> llglsandbox.obj : error LNK2001: unresolved external symbol "class >> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >> llhudeffectbeam.obj : error LNK2019: unresolved external symbol "class >> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) referenced in >> function __ehhandler$?unpackData@LLHUDEffectBeam@@MAEXPAVLLMessageSystem@@H@Z >> llviewerjoint.obj : error LNK2001: unresolved external symbol "class >> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >> llviewerwindow.obj : error LNK2001: unresolved external symbol "class >> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >> llstartup.obj : error LNK2019: unresolved external symbol "public: >> static void __cdecl LLPostProcess::initClass(void)" >> (?initClass@LLPostProcess@@SAXXZ) referenced in function "int __cdecl >> idle_startup(void)" (?idle_startup@@YAHXZ) >> llviewerjoint.obj : error LNK2019: unresolved external symbol "public: >> void __thiscall LLRenderSphere::render(void)" >> (?render@LLRenderSphere@@QAEXXZ) referenced in function "public: void >> __thiscall LLViewerJointCollisionVolume::renderCollision(void)" >> (?renderCollision@LLViewerJointCollisionVolume@@QAEXXZ) >> llviewershadermgr.obj : error LNK2019: unresolved external symbol >> "public: virtual __thiscall LLShaderMgr::~LLShaderMgr(void)" >> (??1LLShaderMgr@@UAE@XZ) referenced in function "public: virtual >> __thiscall LLViewerShaderMgr::~LLViewerShaderMgr(void)" >> (??1LLViewerShaderMgr@@UAE@XZ) >> llviewershadermgr.obj : error LNK2019: unresolved external symbol >> "public: __thiscall LLShaderMgr::LLShaderMgr(void)" >> (??0LLShaderMgr@@QAE@XZ) referenced in function "public: __thiscall >> LLViewerShaderMgr::LLViewerShaderMgr(void)" >> (??0LLViewerShaderMgr@@QAE@XZ) >> llviewershadermgr.obj : error LNK2001: unresolved external symbol >> "protected: static class LLShaderMgr * LLShaderMgr::sInstance" >> (?sInstance@LLShaderMgr@@1PAV1@A) >> llviewershadermgr.obj : error LNK2019: unresolved external symbol >> "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class >> std::basic_string,class >> std::allocator > const &,int &,unsigned int)" >> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >> referenced in function "public: int __thiscall >> LLViewerShaderMgr::loadBasicShaders(void)" >> (?loadBasicShaders@LLViewerShaderMgr@@QAEHXZ) >> llrender.lib(llglslshader.obj) : error LNK2001: unresolved external >> symbol "public: unsigned int __thiscall >> LLShaderMgr::loadShaderFile(class std::basic_string> std::char_traits,class std::allocator > const &,int >> &,unsigned int)" >> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >> llviewerwindow.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLRenderSphere::prerender(void)" >> (?prerender@LLRenderSphere@@QAEXXZ) referenced in function "public: >> void __thiscall LLViewerWindow::initGLDefaults(void)" >> (?initGLDefaults@LLViewerWindow@@QAEXXZ) >> llviewerwindow.obj : error LNK2019: unresolved external symbol >> "public: void __thiscall LLRenderSphere::cleanupGL(void)" >> (?cleanupGL@LLRenderSphere@@QAEXXZ) referenced in function "private: >> void __thiscall LLViewerWindow::stopGL(int)" >> (?stopGL@LLViewerWindow@@AAEXH@Z) >> llvosky.obj : error LNK2019: unresolved external symbol "public: >> __thiscall LLCubeMap::LLCubeMap(void)" (??0LLCubeMap@@QAE@XZ) >> referenced in function "public: void __thiscall >> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >> llvosky.obj : error LNK2019: unresolved external symbol "public: void >> __thiscall LLCubeMap::init(class std::vector> LLImageRaw>,class std::allocator > > >> const &)" (?init@LLCubeMap@@QAEXABV?$vector@V?$LLPointer@VLLImageRaw@@@@V?$allocator@V?$LLPointer@VLLImageRaw@@@@@std@@@std@@@Z) >> referenced in function "public: void __thiscall >> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >> llvosky.obj : error LNK2019: unresolved external symbol "public: void >> __thiscall LLCubeMap::destroyGL(void)" (?destroyGL@LLCubeMap@@QAEXXZ) >> referenced in function "public: void __thiscall >> LLVOSky::cleanupGL(void)" (?cleanupGL@LLVOSky@@QAEXXZ) >> pipeline.obj : error LNK2019: unresolved external symbol "public: >> unsigned int __thiscall LLCubeMap::getGLName(void)" >> (?getGLName@LLCubeMap@@QAEIXZ) referenced in function "public: void >> __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class >> LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >> pipeline.obj : error LNK2019: unresolved external symbol "public: void >> __thiscall LLCubeMap::setReflection(void)" >> (?setReflection@LLCubeMap@@QAEXXZ) referenced in function "public: >> void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap >> *,class LLCamera &)" >> (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >> symbol "public: int __thiscall LLShaderMgr::attachShaderFeatures(class >> LLGLSLShader *)" >> (?attachShaderFeatures@LLShaderMgr@@QAEHPAVLLGLSLShader@@@Z) >> referenced in function "public: int __thiscall >> LLGLSLShader::createShader(class std::vector> std::basic_string,class >> std::allocator >,class std::allocator> std::basic_string,class >> std::allocator > > > *,class std::vector> std::basic_string,class >> std::allocator >,class std::allocator> std::basic_string,class >> std::allocator > > > *)" >> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >> symbol "public: static class LLShaderMgr * __cdecl >> LLShaderMgr::instance(void)" (?instance@LLShaderMgr@@SAPAV1@XZ) >> referenced in function "public: int __thiscall >> LLGLSLShader::createShader(class std::vector> std::basic_string,class >> std::allocator >,class std::allocator> std::basic_string,class >> std::allocator > > > *,class std::vector> std::basic_string,class >> std::allocator >,class std::allocator> std::basic_string,class >> std::allocator > > > *)" >> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >> symbol "public: int __thiscall LLShaderMgr::linkProgramObject(unsigned >> int,int)" (?linkProgramObject@LLShaderMgr@@QAEHIH@Z) referenced in >> function "public: int __thiscall LLGLSLShader::link(int)" >> (?link@LLGLSLShader@@QAEHH@Z) >> C:\src\maint-render-7\indra\build-vc80\newview\RelWithDebInfo\secondlife-bin.exe >> : fatal error LNK1120: 30 unresolved externals >> Build log was saved at >> "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" >> secondlife-bin - 44 error(s), 0 warning(s) >> ------ Skipped Build: Project: ALL_BUILD, Configuration: >> RelWithDebInfo Win32 ------ >> Project not selected to build for this solution configuration >> ------ Skipped Build: Project: server, Configuration: RelWithDebInfo >> Win32 ------ >> Project not selected to build for this solution configuration >> ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo >> Win32 ------ >> Project not selected to build for this solution configuration >> ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== >> >> >> Any suggestions here would be greatly appreciated... >> >> thanks, >> >> azdel >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > From robin.cornelius at gmail.com Mon Aug 25 09:53:03 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Aug 25 09:53:10 2008 Subject: [sldev] [help] TCP and Sockets: connecting to SL with another application In-Reply-To: <20080825172654.0yx9v75k4k0s0wg0@www.sms.ed.ac.uk> References: <20080825172654.0yx9v75k4k0s0wg0@www.sms.ed.ac.uk> Message-ID: <48B2E36F.10403@gmail.com> P Mcewan wrote: > Hello there, > > After many searches through the Second Life viewer source code and the > archived mailing > list to no avail, I hope someone here would be able to guide me in the > right direction :). > Searching through the source file seems to get me no further forward, so > I was wondering > if anyone knows a clean way I can do this? I had hoped there was some > for of library > Linden Labs used, as I really don't want to have to use "socket.h" and > have to worry > about platform and such. SLVoice is communicated to via a socket, I'm not familiar with that code but its a TCP (local) socket so it might be worth a peek at the viewer code to see what it does there. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080825/a0ef7ae2/signature.pgp From gigstaggart at gmail.com Mon Aug 25 10:53:20 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Aug 25 10:53:24 2008 Subject: [sldev] Re: SLDev Digest, Vol 20, Issue 53 In-Reply-To: <437089.66152.qm@web55604.mail.re4.yahoo.com> References: <437089.66152.qm@web55604.mail.re4.yahoo.com> Message-ID: <48B2F190.20809@gmail.com> No one is proposing that all content be forced to choose a creative commons or freely distributable license. I fully expect that under a license attaching system, many people would just choose "All Rights Reserved". Regarding mechanical enforcement, this is absolutely impossible. No computer can judge the nuances of copyright law, many of which are not even addressed in common or statutory law yet. Only humans have the power to judge what is and what isn't an infringing use, not a computer. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080825/aa50a417/smime.bin From ravenglassrentals at yahoo.com Mon Aug 25 12:12:15 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Mon Aug 25 12:12:18 2008 Subject: [sldev] Re: SLDev Digest, Vol 20, Issue 53 In-Reply-To: <48B2F190.20809@gmail.com> Message-ID: <705329.76664.qm@web55606.mail.re4.yahoo.com> As has been noted before the business -- and public -- requirements for Second Life involve making a *framework for copyright to be easily followed and respected* not a replacement for copyright, which is already existing as a system in real life. A request for mechanical, i.e. coded obstacles, to right-clicking and copying, is not a) any sort of uninformed pie-in-the-sky belief that such code can't be hacked or b) any substitute for RL legal framework. But it *is* required as the basics. Copy/transfer/modify -- and now /crossgrid are just four basic values that need flags for 'yes/no' to make the substrate for commerce. Creative Commons is not about commerce; it's a about a big giveaway and a big grab. Whatever its merits, it only serves as a "business model" for a minority who add something like obfuscation-through-consulting on top of it. A separate -- but equal -- group to discuss with the Lindens the business requirements for open-sourcing and interoperability should be created, that is not overlapping with the AWG, as these debates will simply hobble the discussion that the Lindens need to have with their paying customers. People should not be endlessly heckled at office meetings and told they are stupid because "if you can see it/you can copy it". A framework needs to be designed that is not "call your lawyer" or "join the Freetard Republic". Prokofy Neva -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/6d4ab8f1/attachment.htm From jan.ciger at gmail.com Mon Aug 25 13:04:43 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Mon Aug 25 13:04:57 2008 Subject: [sldev] New version of libndofdev for Linux Message-ID: <48B3105B.9050404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have released version 0.2 of libndofdev for Linux, supporting both SDL joysticks and the SpaceNavigator. Main changes compared to the original 0.1: - - Fixed buttons on the SpaceNavigator (oops!) - - Added control of the LED on the SpaceNavigator. You can find the download and instructions at the usual place: http://www.aaue.dk/~janoc/index.php?n=Personal.Downloads http://www.aaue.dk/~janoc/index.php?n=Personal.3DConnexionSpaceNavigatorSupport Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFIsxBXn11XseNj94gRArjnAJ9CVAIy6ds7r7Y/tN4enYXhUN1NewCeJIFr GbASpsRYlBoRa30G5qyyp1M= =37to -----END PGP SIGNATURE----- From robla at lindenlab.com Mon Aug 25 13:41:41 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Aug 25 13:42:13 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory testssuccessful) In-Reply-To: <61dbdd7d0808250156i78d147ecp4f5d87d46d32baf1@mail.gmail.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com><61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail. com><48B2054B.5000306@gmail.com><61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com><48B231D0.60901@gmail.com> <61dbdd7d0808250156i78d147ecp4f5d87d46d32baf1@mail.gmail.com> Message-ID: <48B31905.9000500@lindenlab.com> This thread has been going on a really long time, on a policy rather than strictly technical matter, without finding some constructive outlet (e.g. JIRA feature request or specification on the wiki). Linden Lab doesn't have any plans to add a new flag at this time. While this mailing list is ok to raise the question of whether we should, having the debate exclusively on this list (again) isn't terribly effective or constructive. Since this is a feature request (and one that has already been filed if memory serves me correctly), the discussion is probably best moved to JIRA. If someone could find and post the appropriate JIRA links, that would be much appreciated. Thanks Rob From secondloop at gmail.com Mon Aug 25 14:30:45 2008 From: secondloop at gmail.com (azdel slade) Date: Mon Aug 25 14:30:48 2008 Subject: [sldev] files missing from svn in maint-render-7? In-Reply-To: References: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> Message-ID: <1e0ce1090808251430p23b222bnad9be9b261117e19@mail.gmail.com> Actually, I got this to build successfully. It just seems like a branching error to have the cmakelists.txt be out of sync with the rest of the files. You should be able to co and then build. azdel On Mon, Aug 25, 2008 at 9:41 AM, Soft wrote: > Hang tight - I'm told there's been a mistake in creating the current > maint-viewer branch. I'm pinging to find out which really is the > current development branch, and I'll update this thread after ensuring > the correct one exports. > > On Sat, Aug 23, 2008 at 6:19 AM, Soft wrote: >> maint-render-10 is out and most current. (Yes, there was no >> maint-render-9.) You might try against that branch. If you have >> specific need of the -7 branch, I remember that some other branches >> were affected by missing exports on these files. I could track down >> the fixes. >> >> On Sat, Aug 23, 2008 at 4:44 AM, azdel slade wrote: >>> Ok, take 2 trying to compile with cmake. >>> >>> I got visual studio 2005 pro. I have to correct my staement yesterday, >>> microsoft's "dreamspark" program does allow students to download >>> visual studio 2008 an 2005. I must've tried to use visual C++ express >>> to save download time. >>> >>> So while configuring with develop.py, I got an error about >>> CMakeLists.txt for llrender and newview referring to cpp files that >>> were missing. To be able to continue, I commented them out. But now, >>> I'm getting linker errors, of course. Can folks direct me to where I >>> should get these files from? >>> >>> The problem files are: >>> >>> llcubemap.cpp >>> llpostprocess.cpp >>> llrendersphere.cpp >>> llshadermgr.cpp >>> >>> I double checked, trying to svn update, and still don't have these files. >>> >>> and I get these linker errors, as expected: >>> >>> Linking... >>> llrender.lib(llrender.obj) : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llappviewer.obj : error LNK2001: unresolved external symbol "public: >>> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llpaneldisplay.obj : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llvosky.obj : error LNK2001: unresolved external symbol "public: >>> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llappviewer.obj : error LNK2019: unresolved external symbol "public: >>> static void __cdecl LLPostProcess::cleanupClass(void)" >>> (?cleanupClass@LLPostProcess@@SAXXZ) referenced in function "public: >>> virtual bool __thiscall LLAppViewer::cleanup(void)" >>> (?cleanup@LLAppViewer@@UAE_NXZ) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enable(int)" >>> (?enable@LLCubeMap@@QAEXH@Z) referenced in function "public: void >>> __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enable(int)" >>> (?enable@LLCubeMap@@QAEXH@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enableTextureCoords(int)" >>> (?enableTextureCoords@LLCubeMap@@QAEXH@Z) referenced in function >>> "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enableTexture(int)" >>> (?enableTexture@LLCubeMap@@QAEXH@Z) referenced in function "public: >>> void __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> pipeline.obj : error LNK2001: unresolved external symbol "public: void >>> __thiscall LLCubeMap::enableTexture(int)" >>> (?enableTexture@LLCubeMap@@QAEXH@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::setMatrix(int)" >>> (?setMatrix@LLCubeMap@@QAEXH@Z) referenced in function "public: void >>> __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::restoreMatrix(void)" >>> (?restoreMatrix@LLCubeMap@@QAEXXZ) referenced in function "public: >>> void __thiscall LLDrawPoolBump::endShiny(bool)" >>> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::disable(void)" >>> (?disable@LLCubeMap@@QAEXXZ) referenced in function "public: void >>> __thiscall LLDrawPoolBump::endShiny(bool)" >>> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLCubeMap::disable(void)" >>> (?disable@LLCubeMap@@QAEXXZ) >>> lldrawpoolwater.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::bind(void)" >>> (?bind@LLCubeMap@@QAEXXZ) referenced in function "public: virtual void >>> __thiscall LLDrawPoolWater::render(int)" >>> (?render@LLDrawPoolWater@@UAEXH@Z) >>> llfloaterpostprocess.obj : error LNK2001: unresolved external symbol >>> "class LLPostProcess * gPostProcess" >>> (?gPostProcess@@3PAVLLPostProcess@@A) >>> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLPostProcess::setSelectedEffect(class >>> std::basic_string,class >>> std::allocator > const &)" >>> (?setSelectedEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >>> referenced in function "public: static void __cdecl >>> LLFloaterPostProcess::onLoadEffect(void *)" >>> (?onLoadEffect@LLFloaterPostProcess@@SAXPAX@Z) >>> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLPostProcess::saveEffect(class >>> std::basic_string,class >>> std::allocator > const &)" >>> (?saveEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >>> referenced in function "public: static void __cdecl >>> LLFloaterPostProcess::onSaveEffect(void *)" >>> (?onSaveEffect@LLFloaterPostProcess@@SAXPAX@Z) >>> llglsandbox.obj : error LNK2019: unresolved external symbol "public: >>> void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) referenced in function "public: void >>> __thiscall LLAgent::renderAutoPilotTarget(void)" >>> (?renderAutoPilotTarget@LLAgent@@QAEXXZ) >>> llhudeffectbeam.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) >>> llviewerwindow.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) >>> llglsandbox.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llhudeffectbeam.obj : error LNK2019: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) referenced in >>> function __ehhandler$?unpackData@LLHUDEffectBeam@@MAEXPAVLLMessageSystem@@H@Z >>> llviewerjoint.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llviewerwindow.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llstartup.obj : error LNK2019: unresolved external symbol "public: >>> static void __cdecl LLPostProcess::initClass(void)" >>> (?initClass@LLPostProcess@@SAXXZ) referenced in function "int __cdecl >>> idle_startup(void)" (?idle_startup@@YAHXZ) >>> llviewerjoint.obj : error LNK2019: unresolved external symbol "public: >>> void __thiscall LLRenderSphere::render(void)" >>> (?render@LLRenderSphere@@QAEXXZ) referenced in function "public: void >>> __thiscall LLViewerJointCollisionVolume::renderCollision(void)" >>> (?renderCollision@LLViewerJointCollisionVolume@@QAEXXZ) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: virtual __thiscall LLShaderMgr::~LLShaderMgr(void)" >>> (??1LLShaderMgr@@UAE@XZ) referenced in function "public: virtual >>> __thiscall LLViewerShaderMgr::~LLViewerShaderMgr(void)" >>> (??1LLViewerShaderMgr@@UAE@XZ) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: __thiscall LLShaderMgr::LLShaderMgr(void)" >>> (??0LLShaderMgr@@QAE@XZ) referenced in function "public: __thiscall >>> LLViewerShaderMgr::LLViewerShaderMgr(void)" >>> (??0LLViewerShaderMgr@@QAE@XZ) >>> llviewershadermgr.obj : error LNK2001: unresolved external symbol >>> "protected: static class LLShaderMgr * LLShaderMgr::sInstance" >>> (?sInstance@LLShaderMgr@@1PAV1@A) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class >>> std::basic_string,class >>> std::allocator > const &,int &,unsigned int)" >>> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >>> referenced in function "public: int __thiscall >>> LLViewerShaderMgr::loadBasicShaders(void)" >>> (?loadBasicShaders@LLViewerShaderMgr@@QAEHXZ) >>> llrender.lib(llglslshader.obj) : error LNK2001: unresolved external >>> symbol "public: unsigned int __thiscall >>> LLShaderMgr::loadShaderFile(class std::basic_string>> std::char_traits,class std::allocator > const &,int >>> &,unsigned int)" >>> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >>> llviewerwindow.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::prerender(void)" >>> (?prerender@LLRenderSphere@@QAEXXZ) referenced in function "public: >>> void __thiscall LLViewerWindow::initGLDefaults(void)" >>> (?initGLDefaults@LLViewerWindow@@QAEXXZ) >>> llviewerwindow.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::cleanupGL(void)" >>> (?cleanupGL@LLRenderSphere@@QAEXXZ) referenced in function "private: >>> void __thiscall LLViewerWindow::stopGL(int)" >>> (?stopGL@LLViewerWindow@@AAEXH@Z) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: >>> __thiscall LLCubeMap::LLCubeMap(void)" (??0LLCubeMap@@QAE@XZ) >>> referenced in function "public: void __thiscall >>> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::init(class std::vector>> LLImageRaw>,class std::allocator > > >>> const &)" (?init@LLCubeMap@@QAEXABV?$vector@V?$LLPointer@VLLImageRaw@@@@V?$allocator@V?$LLPointer@VLLImageRaw@@@@@std@@@std@@@Z) >>> referenced in function "public: void __thiscall >>> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::destroyGL(void)" (?destroyGL@LLCubeMap@@QAEXXZ) >>> referenced in function "public: void __thiscall >>> LLVOSky::cleanupGL(void)" (?cleanupGL@LLVOSky@@QAEXXZ) >>> pipeline.obj : error LNK2019: unresolved external symbol "public: >>> unsigned int __thiscall LLCubeMap::getGLName(void)" >>> (?getGLName@LLCubeMap@@QAEIXZ) referenced in function "public: void >>> __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class >>> LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >>> pipeline.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::setReflection(void)" >>> (?setReflection@LLCubeMap@@QAEXXZ) referenced in function "public: >>> void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap >>> *,class LLCamera &)" >>> (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: int __thiscall LLShaderMgr::attachShaderFeatures(class >>> LLGLSLShader *)" >>> (?attachShaderFeatures@LLShaderMgr@@QAEHPAVLLGLSLShader@@@Z) >>> referenced in function "public: int __thiscall >>> LLGLSLShader::createShader(class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *,class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *)" >>> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: static class LLShaderMgr * __cdecl >>> LLShaderMgr::instance(void)" (?instance@LLShaderMgr@@SAPAV1@XZ) >>> referenced in function "public: int __thiscall >>> LLGLSLShader::createShader(class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *,class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *)" >>> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: int __thiscall LLShaderMgr::linkProgramObject(unsigned >>> int,int)" (?linkProgramObject@LLShaderMgr@@QAEHIH@Z) referenced in >>> function "public: int __thiscall LLGLSLShader::link(int)" >>> (?link@LLGLSLShader@@QAEHH@Z) >>> C:\src\maint-render-7\indra\build-vc80\newview\RelWithDebInfo\secondlife-bin.exe >>> : fatal error LNK1120: 30 unresolved externals >>> Build log was saved at >>> "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" >>> secondlife-bin - 44 error(s), 0 warning(s) >>> ------ Skipped Build: Project: ALL_BUILD, Configuration: >>> RelWithDebInfo Win32 ------ >>> Project not selected to build for this solution configuration >>> ------ Skipped Build: Project: server, Configuration: RelWithDebInfo >>> Win32 ------ >>> Project not selected to build for this solution configuration >>> ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo >>> Win32 ------ >>> Project not selected to build for this solution configuration >>> ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== >>> >>> >>> Any suggestions here would be greatly appreciated... >>> >>> thanks, >>> >>> azdel >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> > From brad at lindenlab.com Mon Aug 25 15:34:53 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Mon Aug 25 15:34:57 2008 Subject: [sldev] files missing from svn in maint-render-7? In-Reply-To: References: <1e0ce1090808230244t6ee64048g54c320197983e60d@mail.gmail.com> Message-ID: <48B3338D.8010907@lindenlab.com> Ok, after digging through the logs, the situation is as follows: After maint-render-7 passed QA and merged into the trunk, I attempted to create the branch for the next iteration of the maint-render cycle. I accidentally created maint-render-10 (because maint-viewer-9 had just passed qa at the same time and a bit got flipped in my head). I immediately noticed my error, discarded maint-render-10 and restarted with maint-render-8. However I made a second error and failed to delete the spurious maint-render-10 as I had intended to. So, maint-render-10 (as the apparently most recent maint-render iteration) got exported, and maint-render-8 got ommitted from the export. I have deleted maint-render-10 from both the internal and external repositories. As I've been writing this, maint-render-8 has just been exported, and appears to have have files in question present. Props to soft for cleaning up after me! -Brad Soft wrote: > Hang tight - I'm told there's been a mistake in creating the current > maint-viewer branch. I'm pinging to find out which really is the > current development branch, and I'll update this thread after ensuring > the correct one exports. > > On Sat, Aug 23, 2008 at 6:19 AM, Soft wrote: > >> maint-render-10 is out and most current. (Yes, there was no >> maint-render-9.) You might try against that branch. If you have >> specific need of the -7 branch, I remember that some other branches >> were affected by missing exports on these files. I could track down >> the fixes. >> >> On Sat, Aug 23, 2008 at 4:44 AM, azdel slade wrote: >> >>> Ok, take 2 trying to compile with cmake. >>> >>> I got visual studio 2005 pro. I have to correct my staement yesterday, >>> microsoft's "dreamspark" program does allow students to download >>> visual studio 2008 an 2005. I must've tried to use visual C++ express >>> to save download time. >>> >>> So while configuring with develop.py, I got an error about >>> CMakeLists.txt for llrender and newview referring to cpp files that >>> were missing. To be able to continue, I commented them out. But now, >>> I'm getting linker errors, of course. Can folks direct me to where I >>> should get these files from? >>> >>> The problem files are: >>> >>> llcubemap.cpp >>> llpostprocess.cpp >>> llrendersphere.cpp >>> llshadermgr.cpp >>> >>> I double checked, trying to svn update, and still don't have these files. >>> >>> and I get these linker errors, as expected: >>> >>> Linking... >>> llrender.lib(llrender.obj) : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llappviewer.obj : error LNK2001: unresolved external symbol "public: >>> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llpaneldisplay.obj : error LNK2001: unresolved external symbol >>> "public: static bool LLCubeMap::sUseCubeMaps" >>> (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llvosky.obj : error LNK2001: unresolved external symbol "public: >>> static bool LLCubeMap::sUseCubeMaps" (?sUseCubeMaps@LLCubeMap@@2_NA) >>> llappviewer.obj : error LNK2019: unresolved external symbol "public: >>> static void __cdecl LLPostProcess::cleanupClass(void)" >>> (?cleanupClass@LLPostProcess@@SAXXZ) referenced in function "public: >>> virtual bool __thiscall LLAppViewer::cleanup(void)" >>> (?cleanup@LLAppViewer@@UAE_NXZ) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enable(int)" >>> (?enable@LLCubeMap@@QAEXH@Z) referenced in function "public: void >>> __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enable(int)" >>> (?enable@LLCubeMap@@QAEXH@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enableTextureCoords(int)" >>> (?enableTextureCoords@LLCubeMap@@QAEXH@Z) referenced in function >>> "public: void __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::enableTexture(int)" >>> (?enableTexture@LLCubeMap@@QAEXH@Z) referenced in function "public: >>> void __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> pipeline.obj : error LNK2001: unresolved external symbol "public: void >>> __thiscall LLCubeMap::enableTexture(int)" >>> (?enableTexture@LLCubeMap@@QAEXH@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::setMatrix(int)" >>> (?setMatrix@LLCubeMap@@QAEXH@Z) referenced in function "public: void >>> __thiscall LLDrawPoolBump::beginShiny(bool)" >>> (?beginShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::restoreMatrix(void)" >>> (?restoreMatrix@LLCubeMap@@QAEXXZ) referenced in function "public: >>> void __thiscall LLDrawPoolBump::endShiny(bool)" >>> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolbump.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::disable(void)" >>> (?disable@LLCubeMap@@QAEXXZ) referenced in function "public: void >>> __thiscall LLDrawPoolBump::endShiny(bool)" >>> (?endShiny@LLDrawPoolBump@@QAEX_N@Z) >>> lldrawpoolwater.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLCubeMap::disable(void)" >>> (?disable@LLCubeMap@@QAEXXZ) >>> lldrawpoolwater.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLCubeMap::bind(void)" >>> (?bind@LLCubeMap@@QAEXXZ) referenced in function "public: virtual void >>> __thiscall LLDrawPoolWater::render(int)" >>> (?render@LLDrawPoolWater@@UAEXH@Z) >>> llfloaterpostprocess.obj : error LNK2001: unresolved external symbol >>> "class LLPostProcess * gPostProcess" >>> (?gPostProcess@@3PAVLLPostProcess@@A) >>> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLPostProcess::setSelectedEffect(class >>> std::basic_string,class >>> std::allocator > const &)" >>> (?setSelectedEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >>> referenced in function "public: static void __cdecl >>> LLFloaterPostProcess::onLoadEffect(void *)" >>> (?onLoadEffect@LLFloaterPostProcess@@SAXPAX@Z) >>> llfloaterpostprocess.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLPostProcess::saveEffect(class >>> std::basic_string,class >>> std::allocator > const &)" >>> (?saveEffect@LLPostProcess@@QAEXABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) >>> referenced in function "public: static void __cdecl >>> LLFloaterPostProcess::onSaveEffect(void *)" >>> (?onSaveEffect@LLFloaterPostProcess@@SAXPAX@Z) >>> llglsandbox.obj : error LNK2019: unresolved external symbol "public: >>> void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) referenced in function "public: void >>> __thiscall LLAgent::renderAutoPilotTarget(void)" >>> (?renderAutoPilotTarget@LLAgent@@QAEXXZ) >>> llhudeffectbeam.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) >>> llviewerwindow.obj : error LNK2001: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::render(float)" >>> (?render@LLRenderSphere@@QAEXM@Z) >>> llglsandbox.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llhudeffectbeam.obj : error LNK2019: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) referenced in >>> function __ehhandler$?unpackData@LLHUDEffectBeam@@MAEXPAVLLMessageSystem@@H@Z >>> llviewerjoint.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llviewerwindow.obj : error LNK2001: unresolved external symbol "class >>> LLRenderSphere gSphere" (?gSphere@@3VLLRenderSphere@@A) >>> llstartup.obj : error LNK2019: unresolved external symbol "public: >>> static void __cdecl LLPostProcess::initClass(void)" >>> (?initClass@LLPostProcess@@SAXXZ) referenced in function "int __cdecl >>> idle_startup(void)" (?idle_startup@@YAHXZ) >>> llviewerjoint.obj : error LNK2019: unresolved external symbol "public: >>> void __thiscall LLRenderSphere::render(void)" >>> (?render@LLRenderSphere@@QAEXXZ) referenced in function "public: void >>> __thiscall LLViewerJointCollisionVolume::renderCollision(void)" >>> (?renderCollision@LLViewerJointCollisionVolume@@QAEXXZ) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: virtual __thiscall LLShaderMgr::~LLShaderMgr(void)" >>> (??1LLShaderMgr@@UAE@XZ) referenced in function "public: virtual >>> __thiscall LLViewerShaderMgr::~LLViewerShaderMgr(void)" >>> (??1LLViewerShaderMgr@@UAE@XZ) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: __thiscall LLShaderMgr::LLShaderMgr(void)" >>> (??0LLShaderMgr@@QAE@XZ) referenced in function "public: __thiscall >>> LLViewerShaderMgr::LLViewerShaderMgr(void)" >>> (??0LLViewerShaderMgr@@QAE@XZ) >>> llviewershadermgr.obj : error LNK2001: unresolved external symbol >>> "protected: static class LLShaderMgr * LLShaderMgr::sInstance" >>> (?sInstance@LLShaderMgr@@1PAV1@A) >>> llviewershadermgr.obj : error LNK2019: unresolved external symbol >>> "public: unsigned int __thiscall LLShaderMgr::loadShaderFile(class >>> std::basic_string,class >>> std::allocator > const &,int &,unsigned int)" >>> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >>> referenced in function "public: int __thiscall >>> LLViewerShaderMgr::loadBasicShaders(void)" >>> (?loadBasicShaders@LLViewerShaderMgr@@QAEHXZ) >>> llrender.lib(llglslshader.obj) : error LNK2001: unresolved external >>> symbol "public: unsigned int __thiscall >>> LLShaderMgr::loadShaderFile(class std::basic_string>> std::char_traits,class std::allocator > const &,int >>> &,unsigned int)" >>> (?loadShaderFile@LLShaderMgr@@QAEIABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AAHI@Z) >>> llviewerwindow.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::prerender(void)" >>> (?prerender@LLRenderSphere@@QAEXXZ) referenced in function "public: >>> void __thiscall LLViewerWindow::initGLDefaults(void)" >>> (?initGLDefaults@LLViewerWindow@@QAEXXZ) >>> llviewerwindow.obj : error LNK2019: unresolved external symbol >>> "public: void __thiscall LLRenderSphere::cleanupGL(void)" >>> (?cleanupGL@LLRenderSphere@@QAEXXZ) referenced in function "private: >>> void __thiscall LLViewerWindow::stopGL(int)" >>> (?stopGL@LLViewerWindow@@AAEXH@Z) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: >>> __thiscall LLCubeMap::LLCubeMap(void)" (??0LLCubeMap@@QAE@XZ) >>> referenced in function "public: void __thiscall >>> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::init(class std::vector>> LLImageRaw>,class std::allocator > > >>> const &)" (?init@LLCubeMap@@QAEXABV?$vector@V?$LLPointer@VLLImageRaw@@@@V?$allocator@V?$LLPointer@VLLImageRaw@@@@@std@@@std@@@Z) >>> referenced in function "public: void __thiscall >>> LLVOSky::initCubeMap(void)" (?initCubeMap@LLVOSky@@QAEXXZ) >>> llvosky.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::destroyGL(void)" (?destroyGL@LLCubeMap@@QAEXXZ) >>> referenced in function "public: void __thiscall >>> LLVOSky::cleanupGL(void)" (?cleanupGL@LLVOSky@@QAEXXZ) >>> pipeline.obj : error LNK2019: unresolved external symbol "public: >>> unsigned int __thiscall LLCubeMap::getGLName(void)" >>> (?getGLName@LLCubeMap@@QAEIXZ) referenced in function "public: void >>> __thiscall LLPipeline::generateReflectionMap(class LLCubeMap *,class >>> LLCamera &)" (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >>> pipeline.obj : error LNK2019: unresolved external symbol "public: void >>> __thiscall LLCubeMap::setReflection(void)" >>> (?setReflection@LLCubeMap@@QAEXXZ) referenced in function "public: >>> void __thiscall LLPipeline::generateReflectionMap(class LLCubeMap >>> *,class LLCamera &)" >>> (?generateReflectionMap@LLPipeline@@QAEXPAVLLCubeMap@@AAVLLCamera@@@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: int __thiscall LLShaderMgr::attachShaderFeatures(class >>> LLGLSLShader *)" >>> (?attachShaderFeatures@LLShaderMgr@@QAEHPAVLLGLSLShader@@@Z) >>> referenced in function "public: int __thiscall >>> LLGLSLShader::createShader(class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *,class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *)" >>> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: static class LLShaderMgr * __cdecl >>> LLShaderMgr::instance(void)" (?instance@LLShaderMgr@@SAPAV1@XZ) >>> referenced in function "public: int __thiscall >>> LLGLSLShader::createShader(class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *,class std::vector>> std::basic_string,class >>> std::allocator >,class std::allocator>> std::basic_string,class >>> std::allocator > > > *)" >>> (?createShader@LLGLSLShader@@QAEHPAV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@0@Z) >>> llrender.lib(llglslshader.obj) : error LNK2019: unresolved external >>> symbol "public: int __thiscall LLShaderMgr::linkProgramObject(unsigned >>> int,int)" (?linkProgramObject@LLShaderMgr@@QAEHIH@Z) referenced in >>> function "public: int __thiscall LLGLSLShader::link(int)" >>> (?link@LLGLSLShader@@QAEHH@Z) >>> C:\src\maint-render-7\indra\build-vc80\newview\RelWithDebInfo\secondlife-bin.exe >>> : fatal error LNK1120: 30 unresolved externals >>> Build log was saved at >>> "file://c:\src\maint-render-7\indra\build-vc80\newview\secondlife-bin.dir\RelWithDebInfo\BuildLog.htm" >>> secondlife-bin - 44 error(s), 0 warning(s) >>> ------ Skipped Build: Project: ALL_BUILD, Configuration: >>> RelWithDebInfo Win32 ------ >>> Project not selected to build for this solution configuration >>> ------ Skipped Build: Project: server, Configuration: RelWithDebInfo >>> Win32 ------ >>> Project not selected to build for this solution configuration >>> ------ Skipped Build: Project: viewer, Configuration: RelWithDebInfo >>> Win32 ------ >>> Project not selected to build for this solution configuration >>> ========== Build: 0 succeeded, 2 failed, 23 up-to-date, 3 skipped ========== >>> >>> >>> Any suggestions here would be greatly appreciated... >>> >>> thanks, >>> >>> azdel >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From ravenglassrentals at yahoo.com Mon Aug 25 15:48:39 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Mon Aug 25 15:48:42 2008 Subject: [sldev] Re: SLDev Digest, Vol 20, Issue 56 In-Reply-To: <20080825223502.C43A2113C20@stupor.lindenlab.com> Message-ID: <508406.16231.qm@web55602.mail.re4.yahoo.com> Re: "This thread has been going on a really long time, on a policy rather than strictly technical matter, without finding some constructive outlet (e.g. JIRA feature request or specification on the wiki)". Ok, Rob, you've made that point a number of times, the JIRA was tried, and failed because its own author, suggesting a flag, closed it, precisely because LL did not indicate they were prepared to put in and back up a "crossgrid" flag. So...I fail to see the rationality of being driven back to the JIRA again on this. The reason this debate keeps surfacing is that we really haven't had any clear articulation of policy from Linden Lab on what you plan to do to protect intellectual property when opensims and their interoperability and Second Inventory- type inventory saving become more widespread. The one blog post giving just a sort of philosophical indication from Hamilton Linden that LL will "not allow anyone to violation copyright," although the technical means by which that will be realized aren't articulated. So what is the plan, Rob? Do you expect to tell everybody to tuck notecards into their products and tell them to call their lawyers? Do you plan to stop offering the current flawed, but basically widely viable copy/mod/transfer regime? If so, better to explain that sooner, rather than later. When you can tell us something more about the *mechanical, i.e. coded implementation* of IP opportunities advertised and provided by LL in the past, then you can dispel some of these debates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/abf8f20a/attachment.htm From gbrandon at gmail.com Mon Aug 25 16:16:28 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Mon Aug 25 16:16:36 2008 Subject: [sldev] My question about intellectual property and Second Life Message-ID: I have one question about intellectual property and Second Life. Please consider how much this clarification will help focus the discussions of intellectual property. Is Linden Lab responsible for protecting the intellectual property of the content creators who deposit content in Second Life? My understanding is that Linden Lab is responsible for responding to DMCA claims, like any other service provider should. But the suggestion of machine-enforceable copy protection--is it out of scope, or not? I really hope it's not too grating to ask this. Is there another forum where we should seek an answer (please don't say JIRA and have us wait a year though :D)? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080825/01bd9ca7/attachment.htm From darien.caldwell at gmail.com Mon Aug 25 16:21:44 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Mon Aug 25 16:21:47 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory testssuccessful) In-Reply-To: <48B31905.9000500@lindenlab.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com> <48B2054B.5000306@gmail.com> <61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com> <48B231D0.60901@gmail.com> <61dbdd7d0808250156i78d147ecp4f5d87d46d32baf1@mail.gmail.com> <48B31905.9000500@lindenlab.com> Message-ID: <835a5b860808251621g12a2bc65o3ba686c10d1b4a78@mail.gmail.com> https://jira.secondlife.com/browse/MISC-1277 On 8/25/08, Rob Lanphier wrote: > This thread has been going on a really long time, on a policy rather > than strictly technical matter, without finding some constructive outlet > (e.g. JIRA feature request or specification on the wiki). > > Linden Lab doesn't have any plans to add a new flag at this time. While > this mailing list is ok to raise the question of whether we should, > having the debate exclusively on this list (again) isn't terribly > effective or constructive. Since this is a feature request (and one > that has already been filed if memory serves me correctly), the > discussion is probably best moved to JIRA. If someone could find and > post the appropriate JIRA links, that would be much appreciated. > > Thanks > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tateru.nino at gmail.com Mon Aug 25 21:21:50 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Aug 25 21:21:55 2008 Subject: Exporting stuff, permissions, and licenses (was Re: [sldev] realXtend Global inventory testssuccessful) In-Reply-To: <48B31905.9000500@lindenlab.com> References: <3736d47a0808241053mb061e7dxb5c6c11a1ffc03b3@mail.gmail.com><61dbdd7d0808241059q3ee2f057s427a2fec9dafc5c6@mail.gmail. com><48B2054B.5000306@gmail.com><61dbdd7d0808241827r584952e6yd6dbc19d61aef3c1@mail.gmail.com><48B231D0.60901@gmail.com> <61dbdd7d0808250156i78d147ecp4f5d87d46d32baf1@mail.gmail.com> <48B31905.9000500@lindenlab.com> Message-ID: <48B384DE.5020603@gmail.com> It seems to me that this discussion has also been going on both inworld and on JIRA for a really long time without finding some constructive outlet. Perhaps such policy discussions deserve a mailing list of their own? Rob Lanphier wrote: > This thread has been going on a really long time, on a policy rather > than strictly technical matter, without finding some constructive outlet > (e.g. JIRA feature request or specification on the wiki). > > Linden Lab doesn't have any plans to add a new flag at this time. While > this mailing list is ok to raise the question of whether we should, > having the debate exclusively on this list (again) isn't terribly > effective or constructive. Since this is a feature request (and one > that has already been filed if memory serves me correctly), the > discussion is probably best moved to JIRA. If someone could find and > post the appropriate JIRA links, that would be much appreciated. > > Thanks > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From chess at us.ibm.com Mon Aug 25 21:23:05 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Aug 25 21:23:16 2008 Subject: [sldev] Re: Exporting stuff, permissions, and licenses In-Reply-To: <20080824203931.943EC113AD4@stupor.lindenlab.com> Message-ID: In terms of trying to figure out what carts and horses might look like :) I'd urge people to take a look at the draft trust-model use-cases on the Wiki: https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model_UseCases These give various use-cases to try to put some reality behind the asset-related parts of OGP (which are just starting to be developed). The use cases are built around the various stakeholders and requirements outlined in the draft trust model: https://wiki.secondlife.com/wiki/User:Infinity_Linden/OGP_Trust_Model and finally I've tried to synthesize the existing discussion as it relates to OGP requirements for asset handling (as well as pointers to other related pages) here: https://wiki.secondlife.com/wiki/User:Dale_Innis/Asset_handling_in_OGP So far it doesn't look to me like there has to be much about asset permissions in OGP. An asset's permissions need to be represented in its metadata, and either every domain must know out-of-band what permission scheme(s) are supported by the other domains with which it does business, or OGP needs to have a way for one domain to ask another domain that scheme(s) it supports (and for it to understand the answer). Not looking like rocket science so far. :) And it being a Wiki and all constructuve comments and improvements and expansions are eagerly sought. And little or none of this is assumes anything in particular about what the permission system is (i.e it can be c/m/t, or anything else machine-representable that you like). It only assumes that if I'm (say) SL, and I only want to (say) let a given no-copy object flow to other grids that support no-copy, I need to be able to determine whether or not a given other domain supports that. (Where "determine" doesn't mean "have impossible magic knowledge of", but more like just "find out what the likely / declared state of affairs is".) And similarly if I'm some other virtual world, and I only want to (say) let this always-free item flow to other grids that support always-free, I need to be able to determine whether or not a given other grid supports that. Very simple. :) In terms of the higher-level discussions that have been going on here, I have to say that I take the pragmatic view that, while it's certainly true that no machine-representable permission bits are going to completely capture all of the legal and illegal uses of a given virtual object in a given jurisdiction, it can do a good-enough job in a large-enough set of circumstances to be well worthwhile. A system where the software allows anyone to arbitrarily copy and modify and transport anything, and for IP enforcement we rely on human-readable licenses and the eagerness of all end-users to understand and obey the IP laws, doesn't seem like a system that would actually work, attractive as it might be otherwise. (And apologies if that description is a total straw-man; I have to admit I haven't understood 100% of the recent discussion in this thread.) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080826/b1765acc/attachment.htm From lenglish5 at cox.net Mon Aug 25 21:54:48 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Aug 25 21:54:50 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: References: Message-ID: <48B38C98.4030405@cox.net> Brandon Lockaby wrote: > I have one question about intellectual property and Second Life. > Please consider how much this clarification will help focus the > discussions of intellectual property. > > Is Linden Lab responsible for protecting the intellectual property of > the content creators who deposit content in Second Life? > > My understanding is that Linden Lab is responsible for responding to > DMCA claims, like any other service provider should. But the > suggestion of machine-enforceable copy protection--is it out of scope, > or not? > > I really hope it's not too grating to ask this. Is there another > forum where we should seek an answer (please don't say JIRA and have > us wait a year though :D)? > ------------------------------------------------------------------------ There's always the AWGrupies meeting or Zero's office hours, or Which's to some extent. https://wiki.secondlife.com/wiki/AW_Groupies#AW_Groupies_meeting Lawson From chaosstar at gmail.com Tue Aug 26 00:36:13 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Aug 26 00:36:16 2008 Subject: [sldev] Failing Fmod autodetection in 1.21 cmake/develop Message-ID: <9bb32d430808260036s1eb9fc9fue14d855b9b8d4ac5@mail.gmail.com> Greetings, I would like to point the 1.21 code compilers/tinkerers to the JIRA entry http://jira.secondlife.com/browse/VWR-8776 Pretty much all SVN revisions I've tried in the past, be it the 1.21 trunk or the viewer-1.21 branch seem to have this bug. Can another resident verify this? So far two other people I regularly talk to in-world have witnessed the same behavior and successful workaround, but it never hurts to have other third parties check as well, to see if it might be something system-specific. From robin.cornelius at gmail.com Tue Aug 26 01:07:17 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Aug 26 01:07:20 2008 Subject: [sldev] Failing Fmod autodetection in 1.21 cmake/develop In-Reply-To: <9bb32d430808260036s1eb9fc9fue14d855b9b8d4ac5@mail.gmail.com> References: <9bb32d430808260036s1eb9fc9fue14d855b9b8d4ac5@mail.gmail.com> Message-ID: On Tue, Aug 26, 2008 at 8:36 AM, Ambrosia wrote: > Greetings, > > I would like to point the 1.21 code compilers/tinkerers to the JIRA entry > > http://jira.secondlife.com/browse/VWR-8776 > Yes the fmod issue has been here for a long time, there was a feature request jira to implement the copy fmod files VWR-8393 which is not finished. I think the patch i added to that only helped with the search locations the manifests still need updating to cope with copying the files. Robin From chaosstar at gmail.com Tue Aug 26 02:42:37 2008 From: chaosstar at gmail.com (Ambrosia) Date: Tue Aug 26 02:42:41 2008 Subject: [sldev] Failing Fmod autodetection in 1.21 cmake/develop In-Reply-To: References: <9bb32d430808260036s1eb9fc9fue14d855b9b8d4ac5@mail.gmail.com> Message-ID: <9bb32d430808260242t207367fcpa40e49f910da0bad@mail.gmail.com> Thanks for the heads-up :3 Marked as duplicate and closed. On Tue, Aug 26, 2008 at 10:07, Robin Cornelius wrote: > On Tue, Aug 26, 2008 at 8:36 AM, Ambrosia wrote: >> Greetings, >> >> I would like to point the 1.21 code compilers/tinkerers to the JIRA entry >> >> http://jira.secondlife.com/browse/VWR-8776 >> > > Yes the fmod issue has been here for a long time, there was a feature > request jira to implement the copy fmod files VWR-8393 which is not > finished. I think the patch i added to that only helped with the > search locations the manifests still need updating to cope with > copying the files. > > Robin > From vector at leafpile.com Tue Aug 26 16:13:27 2008 From: vector at leafpile.com (Vector Hastings) Date: Tue Aug 26 16:13:26 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: Message-ID: Hello all, I'm new to this list, never learned C++, but was once a pretty competent programmer on the IBM midrange platform. Please forgive a long first posting, but I've been trying other avenues (as this will make clear) and find myself needing to escalate to client hacking. A full treatment of what I'm seeking involves a certain amount of detail, which now follows: I'm trying to launch an ambitious filmmaking project inside Second Life (machinima). One of the critical keys to getting a more cinematic look to machinima in Second Life is better camera control. The ultimate goal is an in-world camera that can follow a fully reproducible, smooth, and non-colliding path. There's been a lot of work on that already: the 3dNavigator flycam gives us beautiful smooth paths, non-colliding behavior, focal-length control, but there is zero reproducibility. There are a number of waypoint systems that use a vehicle to move the avatar around, allowing for a somewhat reproducible path, but at the cost of collisions which are unacceptable in interior spaces, and the effect is often choppy and fine control of camera angles is not achieved with current systems (even though I suspect that last item is theoretically possible). I've experimented with making a system of waypoints trying to use the llSetCameraParams option to move just the av's camera. I believe this is the best middle-ground approach, and will achieve a major step forward in machinima cameras, but... The inherent desire of the camera to return to the filming avatar's default camera position means my filming results are so choppy that they're only useful for simulating an earthquake. :-\ I know that viewer code is in flux right now, so anything done now is at risk of having to be re-developed later. But I am also on deadlines, so I'm reaching out for guidance in how to do this. Ending up with an older client is workable for me. Hopefully the feature could be ultimately re-engineered for the more stable 1.21. (I'm also happy to use an RC 1.21 viewer, if it becomes usable on the main grid in the next two to three weeks. I was a long-time user of the last two RC candidates, doing a lot of our pre-production filming with them.) What I think I need is a hack of the client to solve the problem with my rig, and there's probably multiple approaches: 1. Create a debug setting that tells the camera to apply its native, manual-mode Cam Transition time and Cam Smoothing to changes in scripted camera location. This sounds relatively simple, since the initial entry and exit into scripted camera control obeys those parameters, but the movement from one location to another does not, which implies to me that the camera routines know whether they are under scripted control or not and have been set to behave in this instantaneous relocation mode when switching from one camera position and/or focus to the next. 2. Create a debug setting that turns off av camera target drift altogether. There are lag parameters in llSetCameraParams, but they only seem to be effective when position_locked = FALSE -- those lag parameters would give excellent speed control in the camera -- but right now, position_locked = FALSE means the camera pulls toward the owning avatar like it's attached with a giant rubber band, and the effect is a seesawing nightmare. 3. Create a flycam recorder. This might be a very general and powerful solution, but authoring a camera path with it would probably be unwieldy. One would want the ability to store a camera path log file to disk in a human readable format so that it could be tweaked into shape. That tweaking could perhaps be done with some sort of statistical analysis program, but I think it would take one dramatically outside the world of SL to do it. 4. Create a waypoint recorder in the client, that simply lets you hit a button to add a camera position/angle to the list of spots to hit, then reposition, add another point. It would be nice to have a speed control, and vital to be able to save it, and helpful to be able to edit it. This is the basics of the scripted waypoint systems in-world, including the one I'm working on. I downloaded the code last night, and went to the library to check out "teach yourself c++" today. Somebody have mercy on me, please! While I will initially use the camera system I develop on my project, as soon as we begin releasing episodes, I will also release the camera as a way of building good-will and buzz in the project. If you want to see a little about the project I'm cooking, you can visit www.vectorpicturestudios.com. All the best to you all, Vector Hastings From q at lindenlab.com Tue Aug 26 22:03:30 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue Aug 26 22:03:33 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: Hi, Victor. Although I work at Linden Lab, I'm not able to give you much help on the details of the code you'll have to write, as I haven't looked at our camera code at all, nor am I an expert in LSL. But what I can do is give you some benefit from having done some work on camera cinematics in a game I worked on. We had the need for an intelligent camera that could track between waypoints, and we also needed a repeatable camera that we could fine-tune the motion track for. I (and others) spent a fair amount of time playing around with the system until we got the sorts of results we wanted. What I can remember (it's been 8 years now) were: For camera motion smoothing: * We had a desired position of the camera eye, and a desired "lookat" point (the target of the camera). The camera had its actual position of the eye and the target. It was possible for both the desired position and the desired lookat to be moving. Each frame, we would move the camera's position a fraction toward its final location, and we'd adjust the rotation fractionally toward the desired location. * The camera also had a velocity and an acceleration. We had a maximum acceleration, and a maximum velocity. We also limited rotational acceleration and rotational velocity. The values for these limits were determined by experiment. * Our position goal was to move the camera each frame 1/16th of the distance to the target position, but without violating our acceleration and velocity constraints. * Our rotational goal was to rotate the camera each frame 1/16th (I think) of the rotation to the target angle, again without violating the speed or acceleration limits. * For position moves, we would start with the camera's current position and target for this frame; that would give us a velocity vector. If that was greater than our max velocity, we'd clamp it. * We'd then subtract that velocity vector from the current velocity vector to get an acceleration; if that was greater than our limit, we'd clamp the acceleration vector. * Finally, we'd add the acceleration vector to the velocity vector to get a new velocity vector. We'd add that to position to get the new position (note that all these calculations need to include a multiplier by delta t). A similar, but independent calculation would take place for camera rotation. Note that using Euler angles for 3D rotations can cause odd tumbling artifacts. There are matrix rotation systems, but all the cool kids (including LL) use quaternions, because they can be interpolated smoothly. But unless you're going to fly over things, you may be able to get away with just dealing with 2D rotations and minor amounts of tilt. Note that in this system, every frame started over, independently; the only carryover from frame to frame was the camera's position and velocity. We also had a minimum distance -- if you're close (for some arbitrary definition of close) you don't even bother to move the camera. This gave rise to some wonderful swooping and beautiful pans with a nice ease into final position -- very much not jerky. For fixed camera motions that were replayable, we actually took (as you suggest) a series of points that corresponded to keyframes, and stored those points and orientations in a database. We then added timing information for each keyframe. We then generated a spline curve through all of those points. Our problem was that we attempted to do it by creating two splines -- one for camera position, and one for camera angle. The trouble was that while each waypoint was perfect for one frame, we tended to get rapid changes in angle around the waypoints, just at the point when you'd like the angle to be most stable. As I recall, we fixed that problem by kicking the math up a notch -- but I don't remember the details, because I wasn't the one who coded it. We probably also added additional keyframes to control where the camera was before and after the key moment. Once you've done that, you can generate all of the other tween frames, and then feed that to some data stream that controls your camera. Good luck! Q On Aug 26, 2008, at 7:13 PM, Vector Hastings wrote: > Hello all, I'm new to this list, never learned C++, but was once a > pretty > competent programmer on the IBM midrange platform. > > Please forgive a long first posting, but I've been trying other > avenues (as > this will make clear) and find myself needing to escalate to client > hacking. > A full treatment of what I'm seeking involves a certain amount of > detail, > which now follows: > > I'm trying to launch an ambitious filmmaking project inside Second > Life > (machinima). One of the critical keys to getting a more cinematic > look to > machinima in Second Life is better camera control. > > The ultimate goal is an in-world camera that can follow a fully > reproducible, smooth, and non-colliding path. > > There's been a lot of work on that already: the 3dNavigator flycam > gives us > beautiful smooth paths, non-colliding behavior, focal-length > control, but > there is zero reproducibility. There are a number of waypoint > systems that > use a vehicle to move the avatar around, allowing for a somewhat > reproducible path, but at the cost of collisions which are > unacceptable in > interior spaces, and the effect is often choppy and fine control of > camera > angles is not achieved with current systems (even though I suspect > that last > item is theoretically possible). > > I've experimented with making a system of waypoints trying to use the > llSetCameraParams option to move just the av's camera. I believe > this is the > best middle-ground approach, and will achieve a major step forward in > machinima cameras, but... > > The inherent desire of the camera to return to the filming avatar's > default > camera position means my filming results are so choppy that they're > only > useful for simulating an earthquake. :-\ > > I know that viewer code is in flux right now, so anything done now > is at > risk of having to be re-developed later. But I am also on deadlines, > so I'm > reaching out for guidance in how to do this. Ending up with an older > client > is workable for me. Hopefully the feature could be ultimately re- > engineered > for the more stable 1.21. (I'm also happy to use an RC 1.21 viewer, > if it > becomes usable on the main grid in the next two to three weeks. I > was a > long-time user of the last two RC candidates, doing a lot of our > pre-production filming with them.) > > > What I think I need is a hack of the client to solve the problem > with my > rig, and there's probably multiple approaches: > > 1. Create a debug setting that tells the camera to apply its native, > manual-mode Cam Transition time and Cam Smoothing to changes in > scripted > camera location. > This sounds relatively simple, since the initial entry and exit into > scripted camera control obeys those parameters, > but the movement from one location to another does not, which > implies to me > that the camera routines know whether > they are under scripted control or not and have been set to behave > in this > instantaneous relocation mode when switching > from one camera position and/or focus to the next. > > 2. Create a debug setting that turns off av camera target drift > altogether. > There are lag parameters in > llSetCameraParams, but they only seem to be effective when > position_locked > = FALSE -- those lag parameters would > give excellent speed control in the camera -- but right now, > position_locked = FALSE means the camera pulls toward > the owning avatar like it's attached with a giant rubber band, and > the > effect is a seesawing nightmare. > > 3. Create a flycam recorder. This might be a very general and > powerful > solution, but authoring a camera path with it > would probably be unwieldy. One would want the ability to store a > camera > path log file to disk in a human readable format > so that it could be tweaked into shape. That tweaking could perhaps > be done > with some sort of statistical analysis program, > but I think it would take one dramatically outside the world of SL > to do > it. > > 4. Create a waypoint recorder in the client, that simply lets you > hit a > button to add a camera position/angle to > the list of spots to hit, then reposition, add another point. It > would be > nice to have a speed control, and vital to be > able to save it, and helpful to be able to edit it. This is the > basics of > the scripted waypoint systems in-world, > including the one I'm working on. > > I downloaded the code last night, and went to the library to check out > "teach yourself c++" today. > > Somebody have mercy on me, please! > > While I will initially use the camera system I develop on my > project, as > soon as we begin releasing episodes, I will also release the camera > as a way > of building good-will and buzz in the project. > > If you want to see a little about the project I'm cooking, you can > visit > www.vectorpicturestudios.com. > > All the best to you all, > > Vector Hastings > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From TammyNowotny at mac.com Tue Aug 26 23:18:25 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Tue Aug 26 23:18:33 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: <48B4F1B1.6000800@mac.com> Kent Quirk (Q Linden) wrote: > Hi, Victor. > > Although I work at Linden Lab, I'm not able to give you much help on > the details of the code you'll have to write, as I haven't looked at > our camera code at all, nor am I an expert in LSL. > > But what I can do is give you some benefit from having done some work > on camera cinematics in a game I worked on. We had the need for an > intelligent camera that could track between waypoints, and we also > needed a repeatable camera that we could fine-tune the motion track for. > > I (and others) spent a fair amount of time playing around with the > system until we got the sorts of results we wanted. What I can > remember (it's been 8 years now) were: > Q for Q: do you have any thoughts on the problems with the erratic camera movements in 1.20 ? (It sounds like the frame was much predictable in that game you worked on 8 years ago.) From me at signpostmarv.name Wed Aug 27 05:34:29 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Aug 27 05:34:31 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: <48B549D5.3080101@signpostmarv.name> Rather odd thought, but rather than modifying the client, why not go for a programmable virtual joystick controller ? Though it's not on the level you're after, I've used GlovePIE to control PPJoy so that I can use the Wii Classic Controller (with full analogue goodness) with Second Life. Since GlovePIE can be used to control PPJoy, it follows that a piece of software could be used to record then play back the input sent to PPJoy. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080827/ff230b7a/smime.bin From monkowsk at watson.ibm.com Wed Aug 27 07:52:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Aug 27 09:22:17 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: <48B56A49.1090804@watson.ibm.com> Vector, Sounds like an interesting project. All of your options look good as well as the one SignpostMarv suggested. I think the choice among them should be based on ease of use rather than ease of coding. So figure out which one you want to do and I'm willing to help. It's not the viewer code that is in flux right now, its the build system. 1.21 is the first version to used CMake, so there are still some bugs in the build process, but there are several people diligently working on fixing that. Once you get a build running with the unmodified code, the rest is the same as always. Mike From q at lindenlab.com Wed Aug 27 11:02:04 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Aug 27 11:02:08 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B4F1B1.6000800@mac.com> References: <48B4F1B1.6000800@mac.com> Message-ID: On Aug 27, 2008, at 2:18 AM, Tammy Nowotny wrote: > Kent Quirk (Q Linden) wrote: >> Hi, Victor. >> >> Although I work at Linden Lab, I'm not able to give you much help >> on the details of the code you'll have to write, as I haven't >> looked at our camera code at all, nor am I an expert in LSL. >> >> But what I can do is give you some benefit from having done some >> work on camera cinematics in a game I worked on. We had the need >> for an intelligent camera that could track between waypoints, and >> we also needed a repeatable camera that we could fine-tune the >> motion track for. >> >> I (and others) spent a fair amount of time playing around with the >> system until we got the sorts of results we wanted. What I can >> remember (it's been 8 years now) were: >> > > Q for Q: do you have any thoughts on the problems with the erratic > camera movements in 1.20 ? (It sounds like the frame was much > predictable in that game you worked on 8 years ago.) Well, it seems to me that the "erratic" camera movement is due more to artifacts in the mouse picking code than to any issues relative to smoothing. At least I assume that's what you're talking about (when you use alt+click to rotate the camera around an object and end up looking at the sun or something). But it's also true that frame rate matters a lot if you want smooth motion. The system I described is reasonably tolerant of varying frame rate, provided that you take the delta T into account each frame -- but it's piecewise linear, so if the frame rate is low you'll see the transitions in velocity. You could move to a time-based system, calculate frames on a fixed timestep, and then interpolate between those frames to get the actual camera motion based on the real framerate. That would give you predictable behavior. Q From sdague at gmail.com Wed Aug 27 12:08:26 2008 From: sdague at gmail.com (Sean Dague) Date: Wed Aug 27 12:08:37 2008 Subject: [sldev] Protocol changes needed to support touch position detection? Message-ID: <48B5A62A.5060000@gmail.com> I'm curious what new protocol bits will be needed to support the llDetectedTouch* features listed here: http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24 so that we can add that in OpenSim as soon as possible. Any pointers would be appreciated. -Sean -- Sean Dague / Neas Bade sdague@gmail.com http://dague.net -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080827/2c8126dc/signature.pgp From secondloop at gmail.com Wed Aug 27 15:20:00 2008 From: secondloop at gmail.com (azdel slade) Date: Wed Aug 27 15:20:03 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: References: Message-ID: <1e0ce1090808271520u1a44184t25960b471da626b8@mail.gmail.com> I don't understand why people keep using this term Intellectual Property with respect to Second Life. It seems to me that we're talking about Copyright, who has the privilege to copy items to where when depending on the license the original author chose. For future discussions, it would be awesome if people would take a look at this article... http://www.gnu.org/philosophy/not-ipr.html "It has become fashionable to toss copyright, patents, and trademarks ? three separate and different entities involving three separate and different sets of laws ? into one pot and call it "intellectual property". The distorting and confusing term did not arise by accident. Companies that gain from the confusion promoted it. The clearest way out of the confusion is to reject the term entirely... The term carries a bias that is not hard to see: it suggests thinking about copyright, patents and trademarks by analogy with property rights for physical objects. (This analogy is at odds with the legal philosophies of copyright law, of patent law, and of trademark law, but only specialists know that.) These laws are in fact not much like physical property law, but use of this term leads legislators to change them to be more so. Since that is the change desired by the companies that exercise copyright, patent and trademark powers, the bias of "intellectual property" suits them... Another problem is that, at the broad scale of "intellectual property", the specific issues raised by the various laws become nearly invisible. These issues arise from the specifics of each law?precisely what the term "intellectual property" encourages people to ignore. For instance, one issue relating to copyright law is whether music sharing should be allowed. Patent law has nothing to do with this. Patent law raises issues such as whether poor countries should be allowed to produce life-saving drugs and sell them cheaply to save lives. Copyright law has nothing to do with such matters. Neither of these issues is solely economic in nature, and their noneconomic aspects are very different; using the shallow economic overgeneralization as the basis for considering them means ignoring the differences. Putting the two laws in the "intellectual property" pot obstructs clear thinking about each one. Thus, any opinions about "the issue of intellectual property" and any generalizations about this supposed category are almost surely foolish. If you think all those laws are one issue, you will tend to choose your opinions from a selection of sweeping overgeneralizations, none of which is any good." On Mon, Aug 25, 2008 at 4:16 PM, Brandon Lockaby wrote: > I have one question about intellectual property and Second Life. Please > consider how much this clarification will help focus the discussions of > intellectual property. > > Is Linden Lab responsible for protecting the intellectual property of the > content creators who deposit content in Second Life? > > My understanding is that Linden Lab is responsible for responding to DMCA > claims, like any other service provider should. But the suggestion of > machine-enforceable copy protection--is it out of scope, or not? > > I really hope it's not too grating to ask this. Is there another forum > where we should seek an answer (please don't say JIRA and have us wait a > year though :D)? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Wed Aug 27 17:34:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Aug 27 17:33:46 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: <48B4F1B1.6000800@mac.com> Message-ID: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> On 2008-08-27, at 13:02, Kent Quirk (Q Linden) wrote: > Well, it seems to me that the "erratic" camera movement is due more > to artifacts in the mouse picking code than to any issues relative > to smoothing. At least I assume that's what you're talking about > (when you use alt+click to rotate the camera around an object and > end up looking at the sun or something). The ones in 1.20 that are most annoying are the ones where there's a prim or avatar behind you, but not quite in the way of the camera, and the camera goes into this nasty feedback loop jumping into and out of the bounding box or something of the prim. Playing with the camera parameters just changes the rate, it doesn't get rid of it. From darien.caldwell at gmail.com Wed Aug 27 17:41:36 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Wed Aug 27 17:41:39 2008 Subject: [sldev] Alt-Cam borkyness (was: Request for help with modifying client camera behavior) Message-ID: <835a5b860808271741u7184259od376bc235ffb997d@mail.gmail.com> For some reason every time there is a new RC i have a lot of Alt-Cam issues the first few versions, and 1.21 (Preview Grid version) is no exception. It always scares me because I rely on it so heavily, having it break would be catastrophic. I am not clear why this keeps changing with every new version, or why it seems to clear itself up after a few iterations of the RC. On 8/27/08, Argent Stonecutter wrote: > On 2008-08-27, at 13:02, Kent Quirk (Q Linden) wrote: >> Well, it seems to me that the "erratic" camera movement is due more >> to artifacts in the mouse picking code than to any issues relative >> to smoothing. At least I assume that's what you're talking about >> (when you use alt+click to rotate the camera around an object and >> end up looking at the sun or something). > > The ones in 1.20 that are most annoying are the ones where there's a > prim or avatar behind you, but not quite in the way of the camera, > and the camera goes into this nasty feedback loop jumping into and > out of the bounding box or something of the prim. Playing with the > camera parameters just changes the rate, it doesn't get rid of it. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From me at signpostmarv.name Wed Aug 27 18:26:20 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Aug 27 18:26:29 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: <48B5FEBC.1040900@signpostmarv.name> Vector Hastings wrote: > That is very cool! So you're able to use the wii controller with SL! That > seems like the cutting edge of our coming, more realistic interfacing with > our virtual worlds. > http://signpostmarvmartin.blip.tv/file/1117080/ I'd say the Wii Classic Controller is far more intuitive (and cheaper) than the Space Navigator. One-handed action vs two-handed action.... > I think I'd lump that in with my option 3: Record the flycam. Only you're > innovating by putting the work outside the client. > You may want to have a look on "speed run" gaming sites to see if there is any existing software for this purpose. The viewer does have a network recorder built in, but I don't think that affects the camera. > Typically, we're more dominated by the actors. This domination by the actors > is even stronger in an animation approach to SL machinima because the bvh > files have to be authored ahead of time, and run on the avatars. Have you looked into playing with the pupeteering branch ? > Another potential downside might have to do with the variable frame rates > achieved in practice. If frame-rate dips during a shoot, will the externally > recorded data for the camera path cause the viewer camera to overshoot its > marks? Essentially, how reproducible is an externally captured camera path? > Use OpenSim, with people logging in remotely or over a local network. Less likely for lagging. > I'm not familiar with GlovePIE, but checking their website, it looks like a > software widget to translate different kinds of input devices to different > kinds of 3dworld inputs. Is that right? Does it have a recorder capacity? > It's primarily meant to allow a device to emulate a joystick. For instance, there are no native drivers for the Wiimote- according to Windows/OSX/*nix, it's a useless piece of bluetooth kit. GlovePIE understands the Wiimote (and it's related peripherals, including the "sensor bar"), allowing it to pass the input onto keyboard commands, mouse control, or a virtual joystick device such as PPJoy. In my setup, the Wiimote talks to GlovePIE, GlovePIE talks to PPJoy, PPJoy talks to SL. An input recorder would likely sit between GlovePIE and PPJoy- recording what GlovePIE tells PPJoy, then repeating it back to PPJoy again at a later time. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080828/aa79923c/smime.bin From gigstaggart at gmail.com Wed Aug 27 20:49:05 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Aug 27 20:49:12 2008 Subject: [sldev] Alt-Cam borkyness (was: Request for help with modifying client camera behavior) In-Reply-To: <835a5b860808271741u7184259od376bc235ffb997d@mail.gmail.com> References: <835a5b860808271741u7184259od376bc235ffb997d@mail.gmail.com> Message-ID: <48B62031.8000702@gmail.com> Darien Caldwell wrote: > For some reason every time there is a new RC i have a lot of Alt-Cam > issues the first few versions, and 1.21 (Preview Grid version) is no > exception. It always scares me because I rely on it so heavily, having > it break would be catastrophic. > > I am not clear why this keeps changing with every new version, or why > it seems to clear itself up after a few iterations of the RC. > I think this time is special, because there is new picking code to support the touch face LSL stuff. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080827/56ce1fdc/smime-0001.bin From gbrandon at gmail.com Wed Aug 27 21:29:19 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Aug 27 21:29:22 2008 Subject: [sldev] Protocol changes needed to support touch position detection? In-Reply-To: <48B5A62A.5060000@gmail.com> References: <48B5A62A.5060000@gmail.com> Message-ID: The changes are already reflected in the wiki: There are new blocks added to the end of the touch messages: http://wiki.secondlife.com/wiki/ObjectGrab http://wiki.secondlife.com/wiki/ObjectGrabUpdate http://wiki.secondlife.com/wiki/ObjectDeGrab The way I learned of the changes was by seeing the patch to the "message template" file on the libsl-commits mailing list. If there's anything I missed I hope someone will point it out! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080828/8643ab6d/attachment.htm From gbrandon at gmail.com Wed Aug 27 21:46:57 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Aug 27 21:46:59 2008 Subject: [sldev] RequestTextureDownload cap In-Reply-To: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> References: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> Message-ID: (I requested the cap but) It isn't granted by 1.24.3.95195 server on the main grid. I'm sorry about the lack of response. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080828/23bbb1c9/attachment.htm From gareth at litesim.com Thu Aug 28 01:54:55 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Aug 28 01:55:02 2008 Subject: [sldev] RequestTextureDownload cap In-Reply-To: References: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> Message-ID: <61dbdd7d0808280154q10b00124hf4a3b0762ad00900@mail.gmail.com> Of course, you won't be able to request it unless it's listed in the seed cap On Thu, Aug 28, 2008 at 5:46 AM, Brandon Lockaby wrote: > (I requested the cap but) It isn't granted by 1.24.3.95195 server on the > main grid. I'm sorry about the lack of response. > From tofu.linden at lindenlab.com Thu Aug 28 04:41:44 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Aug 28 04:41:36 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> Message-ID: <48B68EF8.7060204@lindenlab.com> Argent Stonecutter wrote: > On 2008-08-27, at 13:02, Kent Quirk (Q Linden) wrote: >> Well, it seems to me that the "erratic" camera movement is due more to >> artifacts in the mouse picking code than to any issues relative to >> smoothing. At least I assume that's what you're talking about (when >> you use alt+click to rotate the camera around an object and end up >> looking at the sun or something). > > The ones in 1.20 that are most annoying are the ones where there's a > prim or avatar behind you, but not quite in the way of the camera, and > the camera goes into this nasty feedback loop jumping into and out of > the bounding box or something of the prim. Playing with the camera > parameters just changes the rate, it doesn't get rid of it. That's actually a server-side issue (the camera ray collision is mostly handled by the physics engine). It's recently been fixed internally, though I'm fuzzy on when it will roll-out. From gigstaggart at gmail.com Thu Aug 28 10:46:12 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Aug 28 10:46:21 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B68EF8.7060204@lindenlab.com> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> Message-ID: <48B6E464.8050105@gmail.com> Tofu Linden wrote: > That's actually a server-side issue (the camera ray collision is mostly > handled by the physics engine). It's recently been fixed internally, > though I'm fuzzy on when it will roll-out. Is this newly on the server side? When I worked on the camera focus picking code last, it was very much client-side. The only server side thing I noticed was the rez-object raycast from the camera to a surface. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080828/e9e2ac7f/smime.bin From kelly at lindenlab.com Thu Aug 28 10:54:20 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Thu Aug 28 10:54:41 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B6E464.8050105@gmail.com> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com><48B68EF8.7060204@lindenlab.com> <48B6E464.8050105@gmail.com> Message-ID: <48B6E64C.9050703@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080828/53f38333/attachment.htm From chess at us.ibm.com Thu Aug 28 13:21:42 2008 From: chess at us.ibm.com (David M Chess) Date: Thu Aug 28 13:21:52 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <20080828034915.A5A94113A2B@stupor.lindenlab.com> Message-ID: From: "azdel slade" > I don't understand why people keep using this term Intellectual > Property with respect to Second Life. It seems to me that we're > talking about Copyright, who has the privilege to copy items to where > when depending on the license the original author chose. I think you answered your own question there. :) We're talking mostly about copyright, but since we're also dealing with licenses that may grant or withhold rights that copyright law simpliciter might not, it also gets into licensing, contract law, and less legal stuff like Terms of Service, where a violation may not be a crime or a tort, but may still get you banned from SL. It's kind of nice to have a blanket term for that, although I agree that the implicit analogy to simple property may be a bit forced. (Heck, even simple non-intellectual property isn't all that simple; look at land for instance.) Terminology is always hard... :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080828/e4cf0192/attachment.htm From jan.ciger at gmail.com Thu Aug 28 18:44:58 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Thu Aug 28 18:47:08 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: References: Message-ID: <48B7549A.7020302@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, David M Chess wrote: | I think you answered your own question there. :) We're talking mostly | about copyright, but since we're also dealing with licenses that may | grant or withhold rights that copyright law simpliciter might not, it | also gets into licensing, contract law, and less legal stuff like Terms | of Service, where a violation may not be a crime or a tort, but may | still get you banned from SL. It's kind of nice to have a blanket term | for that, although I agree that the implicit analogy to simple property | may be a bit forced. (Heck, even simple non-intellectual property isn't | all that simple; look at land for instance.) Terminology is always | hard... :) The trouble with the "blanket term" you would like to have is that it is legally meaningless and completely misleading for the lay people. As you have said - we may be dealing with copyright, contracts, TOS (which is a kind of contract), trademarks, design marks (protected designs - not sure whether the English term is correct) even patent law, You cannot lump this under one umbrella term - these things are very different and you will be hard pressed to even find a lawyer proficient in all of them. Oh, and which jurisdiction are we talking about? American law varies between states, European law (which country?) is a yet different beast. And I know some residents from Australia, Japan and Canada too ... Now, what follows is not really targeted as much on you, David, as on the people crying against being ripped off and having their stuff copied. Some people are even trying to simplify this further, pressing for having even stronger DRM controls or blanket banning of people who re-create or copy someone's creation as a solution to all this. Hate to break it to you guys, but SL is not here only for you to make a profit. I am not against healthy in-world commerce or having a copyright on something, but you cannot stop me from remaking your contraption, unless I provably copy your work - which may be tricky to prove. Is putting cubes one next to another in the same way as you did copying? It makes no difference whether I have used a script or did it by hand. If my work looks the same as yours, but didn't use any part of yours and I am not distributing it as yours, it wouldn't be a copy/derivative work in RL. Looks and functionality are not copyrightable, as Apple painfully discovered some years ago when they tried this stunt with MacOS. Some people would like to prevent me from even using the same idea (like one un-named animated ocean wave creator recently!). Good luck with that, because unless you have a patent on your work, you have no leg to stand on. In the case of mathematical algorithms and data (which SL content arguably is) obtaining patent may even not be possible (not to mention the ridiculous expense). So, if the wave maker is reading this, do everyone a favour and remove the ridiculous language from your "license". You will look less like a dork. Finally, for the people pushing for various "EULA"-like fields in the object properties - you do not know what you are getting yourself into. Your license may not even be a valid license in many places, unless it is translated to the official language. E.g. in Germany, all such documents have to be in German to be valid. So, if I want to use your work against your license, all I have to do is to get a German do it because your license is in English only. Also, "click-wrap", non-negotiable contracts are not enforceable in many places. So unless Lindens are planning to create an in-world legal system covering this (TOS extension?), it will be a mess. If you feel harmed by someone's copying your stuff, sue. That is what courts are for and then I will have also a chance to defend myself. Having a company-appointed "policeman" banning people left and right just because someone accused them of theft is not acceptable (some game companies are doing this and there is enough of crying asking for this on the SL forums ...). However, do not push blanket technical measures on everyone for your own sake. Look at the situation in music or video, where the big labels managed to completely obliterate the legitimate media market with their technological and legal efforts. Only one or two big players are able to stay in the market today. And of course, the pirates, who couldn't care less. Everyone else is screwed. I would hate to see this happening in SL too because of short-sighted stop-gap knee-jerk reactions to a perceived problem. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFIt1SWn11XseNj94gRAg7PAJ9/j5l0U1LFmsW0zhklo0s2lWW89wCg0hiI HlCc9d/ANbWof9tQDJ1I1gI= =EosI -----END PGP SIGNATURE----- From robla at lindenlab.com Thu Aug 28 22:26:17 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Aug 28 22:26:23 2008 Subject: [sldev] Patch bundles (Joystick, Chat/IM, other ideas) Message-ID: <48B78879.1090807@lindenlab.com> Hi everyone, At our open source meeting earlier today, we again discussed the concept of bundling related patches together for incorporation in one swell foop. The idea is to save on both developer and QA resources by being able to focus on one area of the code at a time, and have a managable bundle of patches to consider together as a single set of improvements. Tofu is currently blasting through a set of joystick patches right now (I see commits today for VWR-7383, VWR-6482, VWR-6482, VWR-8341, and he's been messing with VWR-5297 in the background for a while). We're pretty optimistic that this is how we should have been doing it all along. In the meeting today, we decided to start bundling right there, and ended up with this meta issue for the batch of pending Chat/IM issues: https://jira.secondlife.com/browse/VWR-8808 I'm sure there are more patches that aren't properly linked up, so please point them out. If you've been thinking about getting a chat patch in, but have been putting it off, now's a good time to dig in. Here's the query for all of the pending patches: https://jira.secondlife.com/secure/IssueNavigator.jspa?reset=true&&status=1&status=3&status=4&customfield_10002=Patch+attached&sorter/field=customfield_10000&sorter/order=ASC&sorter/field=customfield_10020&sorter/order=DESC&sorter/field=components&sorter/order=ASC If there are other logical groupings that you see (e.g. a script editor patch bundle would be handy), please create the meta issue and advertise it to this list. Thanks Rob From darien.caldwell at gmail.com Fri Aug 29 00:46:35 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri Aug 29 00:46:39 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B7549A.7020302@gmail.com> References: <48B7549A.7020302@gmail.com> Message-ID: <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> When people are talking IP, it's just used as a general term, and there's nothing worng with that. There are no lawyers here, so it doesn't have to be 'legally meaningful'. It's a lot easier to say: "I want my IP protected." than to say "I want my Copyright/Patents/Textures/Music/Video/Animations/Desgin/Story/Whatever else protected." It's shorthand, and for the purpose of debate perfectly fine. And when you own copyright on something, you do own it, so it is property. Just like when you own a dog or cat, it's property. Although I know some would debate that assertion too. :) On 8/28/08, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi David, > > David M Chess wrote: > | I think you answered your own question there. :) We're talking mostly > | about copyright, but since we're also dealing with licenses that may > | grant or withhold rights that copyright law simpliciter might not, it > | also gets into licensing, contract law, and less legal stuff like Terms > | of Service, where a violation may not be a crime or a tort, but may > | still get you banned from SL. It's kind of nice to have a blanket term > | for that, although I agree that the implicit analogy to simple property > | may be a bit forced. (Heck, even simple non-intellectual property isn't > | all that simple; look at land for instance.) Terminology is always > | hard... :) > > > The trouble with the "blanket term" you would like to have is that it is > legally meaningless and completely misleading for the lay people. > > As you have said - we may be dealing with copyright, contracts, TOS > (which is a kind of contract), trademarks, design marks (protected > designs - not sure whether the English term is correct) even patent law, > You cannot lump this under one umbrella term - these things are very > different and you will be hard pressed to even find a lawyer proficient > in all of them. Oh, and which jurisdiction are we talking about? > American law varies between states, European law (which country?) is a > yet different beast. And I know some residents from Australia, Japan and > Canada too ... > > Now, what follows is not really targeted as much on you, David, as on > the people crying against being ripped off and having their stuff copied. > > > Some people are even trying to simplify this further, pressing for > having even stronger DRM controls or blanket banning of people who > re-create or copy someone's creation as a solution to all this. > > Hate to break it to you guys, but SL is not here only for you to make a > profit. I am not against healthy in-world commerce or having a copyright > on something, but you cannot stop me from remaking your contraption, > unless I provably copy your work - which may be tricky to prove. Is > putting cubes one next to another in the same way as you did copying? It > makes no difference whether I have used a script or did it by hand. If > my work looks the same as yours, but didn't use any part of yours and I > am not distributing it as yours, it wouldn't be a copy/derivative work > in RL. Looks and functionality are not copyrightable, as Apple painfully > discovered some years ago when they tried this stunt with MacOS. > > Some people would like to prevent me from even using the same idea (like > one un-named animated ocean wave creator recently!). Good luck with > that, because unless you have a patent on your work, you have no leg to > stand on. In the case of mathematical algorithms and data (which SL > content arguably is) obtaining patent may even not be possible (not to > mention the ridiculous expense). So, if the wave maker is reading this, > do everyone a favour and remove the ridiculous language from your > "license". You will look less like a dork. > > Finally, for the people pushing for various "EULA"-like fields in the > object properties - you do not know what you are getting yourself into. > Your license may not even be a valid license in many places, unless it > is translated to the official language. E.g. in Germany, all such > documents have to be in German to be valid. So, if I want to use your > work against your license, all I have to do is to get a German do it > because your license is in English only. Also, "click-wrap", > non-negotiable contracts are not enforceable in many places. So unless > Lindens are planning to create an in-world legal system covering this > (TOS extension?), it will be a mess. > > If you feel harmed by someone's copying your stuff, sue. That is what > courts are for and then I will have also a chance to defend myself. > Having a company-appointed "policeman" banning people left and right > just because someone accused them of theft is not acceptable (some game > companies are doing this and there is enough of crying asking for this > on the SL forums ...). > > However, do not push blanket technical measures on everyone for your own > sake. Look at the situation in music or video, where the big labels > managed to completely obliterate the legitimate media market with their > technological and legal efforts. Only one or two big players are able to > stay in the market today. And of course, the pirates, who couldn't care > less. Everyone else is screwed. I would hate to see this happening in SL > too because of short-sighted stop-gap knee-jerk reactions to a perceived > problem. > > > Regards, > > Jan > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFIt1SWn11XseNj94gRAg7PAJ9/j5l0U1LFmsW0zhklo0s2lWW89wCg0hiI > HlCc9d/ANbWof9tQDJ1I1gI= > =EosI > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From ian at ianbetteridge.co.uk Fri Aug 29 01:18:39 2008 From: ian at ianbetteridge.co.uk (Ian Betteridge) Date: Fri Aug 29 01:18:41 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> References: <48B7549A.7020302@gmail.com> <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> Message-ID: On Fri, Aug 29, 2008 at 8:46 AM, Darien Caldwell wrote: > When people are talking IP, it's just used as a general term, and > there's nothing worng with that. There are no lawyers here, so it > doesn't have to be 'legally meaningful'. It's a lot easier to say: > "I want my IP protected." than to say "I want my > Copyright/Patents/Textures/Music/Video/Animations/Desgin/Story/Whatever > else protected." I'm kind-of reluctant to add to this thread, as I don't really think that it's the right forum for this discussion, and I know it's been thrashed about ad infinitum. But having said that... While generally I'd agree with you, I think it's fair to ask people to be precise about what, exactly, they want protected. As others have pointed out, if you're going to create a technological solution to a problem you need to define fairly precisely what the problem is - and that involves working which kinds of IP you want to attempt to protect. At present, technological protections in SL cover very specific things: objects, scripts, textures. What content creators are, by and large, asking for is that those protections be respected across grids. I'm not going to go into the reasons why they're asking for that, or whether they are ethically right or wrong: what I'm saying is that, having been given those protections, content creators do not want to see them effectively removed by the ability to move objects across-grids, to grids which offer no equivalent protections. Neither should this be a debate about whether those protections are technically effective. The current protections in SL alone are not 100% technically effective, and yet they, combined with an effective micropayments system, provide many content creators with a significant source of income and the whole world with its economy. And that will be all I'll have to say on this subject here. I'm happy to continue the conversation on a one-to-one basis, or in an more appropriate public forum. From jan.ciger at gmail.com Fri Aug 29 02:54:32 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri Aug 29 02:54:39 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> References: <48B7549A.7020302@gmail.com> <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> Message-ID: <48B7C758.601@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Darien, Darien Caldwell wrote: | When people are talking IP, it's just used as a general term, and | there's nothing worng with that. There are no lawyers here, so it | doesn't have to be 'legally meaningful'. It's a lot easier to say: | "I want my IP protected." than to say "I want my | Copyright/Patents/Textures/Music/Video/Animations/Desgin/Story/Whatever | else protected." I do not want to start a longish debate here, however what you are proposing basically boils down to: "I am ignorant, take care of me". What do you mean by "protected"? Sorry to sound rude, but enforcing a copyright (assuming that someone actually says what is covered by it in SL) is vastly different from e.g. a patent. Copyright "protection" (or enforcement) in US can mean as little as filing a DMCA claim. Patent enforcement means a multi-million lawsuit. Trademarks are enforced in a yet different way. Moreover, protecting rights of the authors is first and foremost the authors' own job, with the company only being responsible for facilitating that - e.g. by responding to the DMCA claims and/or subpoenas or court orders - which Lindens are doing already. From this point of view there is little difference between them and e.g. YouTube. It is not YouTube (or Google) who will go after you when you illegally post a copyrighted video there, it will be the right owners (e.g. a big media corp). YouTube will only remove it after e.g. a DMCA notification or as a result of a court ruling. Making it impossible to post a copyrighted video to start with ranges from technically impractical to outright impossible, not to mention the false positives and their impact. In SL this would be even more complicated. | It's shorthand, and for the purpose of debate perfectly fine. And when | you own copyright on something, you do own it, so it is property. Just | like when you own a dog or cat, it's property. Although I know some | would debate that assertion too. :) Well, this is like saying because my daughter is "mine", therefore I own her, so she is property too. A stretch, but I hope it illustrates the point. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFIt8dUn11XseNj94gRAvwWAJoC/PJIdj+A+eOc3Zo77+Y1WHZDkgCcCDgI QFUDYmXN8pXd5ggOdkVAC9A= =+bM4 -----END PGP SIGNATURE----- From secret.argent at gmail.com Fri Aug 29 04:37:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 29 04:36:26 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B68EF8.7060204@lindenlab.com> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> Message-ID: <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> On 2008-08-28, at 06:41, Tofu Linden wrote: > That's actually a server-side issue (the camera ray collision is > mostly > handled by the physics engine). It's recently been fixed internally, > though I'm fuzzy on when it will roll-out. I have often wondered why SL does that ... keeping the camera on the same side as "big enough" prims ... instead of doing what many other games do and leaving the camera free to move but hiding the objects that would obscure the avatar. From secret.argent at gmail.com Fri Aug 29 04:50:52 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 29 04:50:19 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B7549A.7020302@gmail.com> References: <48B7549A.7020302@gmail.com> Message-ID: <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> On 2008-08-28, at 20:44, Jan Ciger wrote: > The trouble with the "blanket term" you would like to have is that > it is > legally meaningless and completely misleading for the lay people. I entirely agree, BUT... English is not a tame language, it evolves out of control of people's wills and wishes. It can't be trapped nor fenced. It can be encouraged to nest where you want it, but it takes a lot of work, and you have to build a new burrow... just filling in the old one will not work. Consider how many years the US government has been trying to suppress derogatory terms for people from certain parts of the world, to no avail. If you want to abolish the term, you have to at the very least come up with a better blanket term and popularize that. > Finally, for the people pushing for various "EULA"-like fields in the > object properties - you do not know what you are getting yourself > into. > Your license may not even be a valid license in many places [...] It only needs to be a valid license in California and Texas. Your idea of using German cut-outs is charming, but the law does not work that way. Perhaps you can ignore the GPL in Germany, but you can't sell your GPL-violating products back to someone in the US. Second Life operates out of California and has an office in Texas. When you log in to SL, your "property" is in California and Texas. Not Germany or Japan or India or China. From secret.argent at gmail.com Fri Aug 29 05:00:22 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 29 04:59:50 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> References: <48B7549A.7020302@gmail.com> <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> Message-ID: On 2008-08-29, at 02:46, Darien Caldwell wrote: > It's shorthand, and for the purpose of debate perfectly fine. And when > you own copyright on something, you do own it, so it is property. Just > like when you own a dog or cat, it's property. Although I know some > would debate that assertion too. :) But what you own is not the thing that you think you own, what you own is a set of monopoly rights. You don't "own the song", you own the right to limit performances and distribution of the song. If I have an MP3 of you singing the song that I bought from someone that didn't have the right to sell it, you don't get to take it away from me, you just get to sue the person who distributed that copy to recover damages and prevent him from doing it again. It's not like a car, where the car will be taken away from the buyer and returned to the owner... and the buyer can even find themselves in legal trouble over it. The problem is there's not a better shorthand (like monopoly rights) in general use. From secret.argent at gmail.com Fri Aug 29 05:07:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Aug 29 05:07:01 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B7C758.601@gmail.com> References: <48B7549A.7020302@gmail.com> <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> <48B7C758.601@gmail.com> Message-ID: <7F26235C-CF4D-4DAC-BD32-78D2C2D6160C@gmail.com> Regardless of anything else, the limited rights created by the SL permissions system are *useful*, so whether Linden Labs is legally required to enforce them or not is irrelevant... I think it unlikely that Linden Labs wants to see them removed. If anything, they have expanded them over time (unwisely, in my opinion, in some cases... for example they abandoned their original commitment to things like the doctrine of first sale)... so it's clear that they see this mechanism to be useful. So it's not really useful to frame the discussion in terms of what LL is required to do. Instead, ask what it is useful for them to do. From jan.ciger at gmail.com Fri Aug 29 05:14:28 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri Aug 29 05:14:34 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> References: <48B7549A.7020302@gmail.com> <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> Message-ID: <48B7E824.6090204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: | If you want to abolish the term, you have to at the very least come up | with a better blanket term and popularize that. The idea is not to abolish the term, but the concept. There is copyright and there are patents and other things, but not one umbrella thing - that is the misleading part of it. | It only needs to be a valid license in California and Texas. | | Your idea of using German cut-outs is charming, but the law does not | work that way. Perhaps you can ignore the GPL in Germany, but you can't | sell your GPL-violating products back to someone in the US. | | Second Life operates out of California and has an office in Texas. When | you log in to SL, your "property" is in California and Texas. Not | Germany or Japan or India or China. Well, many European courts will strongly disagree with this notion. Once you are offering the product on their "territory", you are covered by their jurisdiction. I do not necessarily agree with this notion, because it could unleash lot of other problems, but this has been a position courts have taken before. Also, saying that I am bound by Californian/Texas law when I commit a crime/tort in Germany and have never set a foot on the U.S. soil will be interesting. You may get a default judgement, but how are you going to enforce it? Forget extradition - and the act may not have even been criminal/tort in Germany to start with. Overall, international law is an extremely complex issue and trying to "simplify" the matter by using misleading "simple" terms like intellectual property only murks the water more. However, I suggest we move this discussion elsewhere, I think this is not an appropriate forum for it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFIt+ghn11XseNj94gRAjHGAKDn2mhUBfGoQseJYibc21kLe5OgiACg43ox rE9arHScAW1l/BVlvvnJueg= =0yhM -----END PGP SIGNATURE----- From me at signpostmarv.name Fri Aug 29 05:18:49 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Aug 29 05:18:55 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> Message-ID: <48B7E929.7020207@signpostmarv.name> Argent Stonecutter wrote: > I have often wondered why SL does that ... keeping the camera on the > same side as "big enough" prims ... instead of doing what many other > games do and leaving the camera free to move but hiding the objects > that would obscure the avatar. There are several methods of hiding objects, some of which can affect the FPS performance (anyone who has played Neverwinter Nights 2 will know what I'm talking about). You could fade an object to semi-transparent or remove each prim/object obscuring the view. The viewer has "issues" with alpha sorting (though is that only textures ?), and as for removing/hiding each prim/object, the problem is a little more complex. In "other games", the developers know the precise location of every single object in a given scene, allowing them to pick and choose which objects can be faded (a fence might be kept solid because you can see through most of it, but a building would likely be faded/hidden). The overall immersion isn't affected because of the carefully controlled environment- SL is of course, rarely every a carefully controlled environment. If you remove each prim obscuring the view; 1) do you take the texture into account ? (no point removing a prim you can see through perfectly fine anyway) 2) do you take the cut/dimple/taper into account (no point removing a prim you can see around, even if the prim center is in the way) 3) Sculpties... If you remove each *object* obscuring the view, the entire build could disappear. Content creators would demand LSL commands to selectively control which prim in a linkset could be obscured. The default prim property would likely have to be *not* hiding the prim, otherwise all the old content would be affected. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080829/89c88858/smime.bin From jan.ciger at gmail.com Fri Aug 29 05:23:35 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri Aug 29 05:23:43 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <7F26235C-CF4D-4DAC-BD32-78D2C2D6160C@gmail.com> References: <48B7549A.7020302@gmail.com> <835a5b860808290046q77b14cber24ae175116510c17@mail.gmail.com> <48B7C758.601@gmail.com> <7F26235C-CF4D-4DAC-BD32-78D2C2D6160C@gmail.com> Message-ID: <48B7EA47.2060502@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Argent Stonecutter wrote: | So it's not really useful to frame the discussion in terms of | what LL is required to do. Instead, ask what it is useful for them to do. Yep, that's about the point I wanted to make. Overzealous DRM will only make things worse for everyone, on the other hand a complete free-for-all system in a purely digital world doesn't really work neither. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFIt+pHn11XseNj94gRAv++AJ9/aJa38Lf1fE1F9wApyMoevTTtCACfX07F R/a+qztZQCDk9f6YnKewGxA= =IDen -----END PGP SIGNATURE----- From open at autistici.org Fri Aug 29 05:31:09 2008 From: open at autistici.org (Opensource Obscure) Date: Fri Aug 29 05:31:11 2008 Subject: [sldev] Trivial solution for VWR-2085 Message-ID: I like very much to hide the viewer UI while I'm in cool places in-world - it enhances the sense of immersion, it makes you feel more like being in a movie than using an application, etc. Unfortunately, since 1 year you can't do this on Linux anymore, because the shortcut for this feature has been changed to CTRL-ALT-F1 and Linux users cannot use it. https://jira.secondlife.com/browse/VWR-2085 This is a long-standing bug and it can be solved by changing the shortcut from CTRL-ALT-F1 to CTRL-ALT-1, that is a trivial change. AFAIK, this new shortcut doesn't interfere with existing shortcuts on Linux and Windows, but I couldn't test it on Mac OS X. Mac OS X users - could you please confirm that CTRL-ALT-1 would be ok for you? Here is how to modify the shortcut: - edit indra/newview/llviewermenu.cpp - find this string: KEY_F1 - replace it with: '1' - compile as usual I tested this on many Linux 1.18.x - 1.21.x releases and works fine. BTW, a better long-term solution for this is also available thanks to Jacek Antonelli - https://jira.secondlife.com/browse/VWR-2896 - However I don't see it coming to the viewer anytime soon, while this 1-word change may be accepted more easily and quickly. Opensource Obscure From tom at cornish-pasty.com Fri Aug 29 08:05:39 2008 From: tom at cornish-pasty.com (Thomas Rowland) Date: Fri Aug 29 08:05:47 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B7EA47.2060502@gmail.com> Message-ID: <000801c909e8$b5c06f80$0132a8c0@tomhome> 'copy protection' and 'intellectual property rights' are a necessity of capitalism, & SL is created on a capitalist idea. Jan Cigar wrote: Well, this is like saying because my daughter is "mine", therefore I own her, so she is property too. A stretch, but I hope it illustrates the point. - http://www.actionbioscience.org/genomic/crg.html Next they will be wanting to patent numbers. Oops, sorry they already do. Big ones. Ones that make computers do stuff. Please LL give the people who keep filling this Developers list with IPR etc. discussion a list so that developers can discuss developers stuff here without all this C___ . From timelessprototype at gmail.com Fri Aug 29 08:32:53 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Fri Aug 29 08:32:37 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <000801c909e8$b5c06f80$0132a8c0@tomhome> References: <000801c909e8$b5c06f80$0132a8c0@tomhome> Message-ID: <48B816A5.9020207@gmail.com> Thomas Rowland wrote: > 'copy protection' and 'intellectual property rights' are a necessity of > capitalism, & SL is created on a capitalist idea. > > Jan Cigar wrote: > > Well, this is like saying because my daughter is "mine", therefore I own > her, so she is property too. A stretch, but I hope it illustrates the point. > > - http://www.actionbioscience.org/genomic/crg.html > > > Next they will be wanting to patent numbers. Oops, sorry they already do. > Big ones. Ones that make computers do stuff. > > > Please LL give the people who keep filling this Developers list with IPR > etc. discussion a list so that developers can discuss developers stuff here > without all this C___ . > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > A "sllegal" list would be great - as long as we had some subject matter experts participating. :) From kelly at lindenlab.com Fri Aug 29 08:53:37 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Fri Aug 29 08:53:45 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> References: <48B4F1B1.60008 00@mac.com><580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com><48B68EF8.706020 4@lindenlab.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> Message-ID: <48B81B81.5090601@lindenlab.com> Argent Stonecutter wrote: > On 2008-08-28, at 06:41, Tofu Linden wrote: >> That's actually a server-side issue (the camera ray collision is mostly >> handled by the physics engine). It's recently been fixed internally, >> though I'm fuzzy on when it will roll-out. > > I have often wondered why SL does that ... keeping the camera on the > same side as "big enough" prims ... instead of doing what many other > games do and leaving the camera free to move but hiding the objects > that would obscure the avatar. > > I've seen games that do both. Most games that come to my mind that hide objects between the camera and the avatar are isometric top down games where there isn't a whole lot of camera freedom. Most first or third person games I'm familiar with move the camera. I am admittedly not familiar with a whole lot of games at this point (I was at one point, I swear!). SL's camera system is really not great and makes indoor spaces usually unpleasant (unless they are really large indoor spaces). I would be very interested in seeing a test implementation that hid the objects as you describe. The server side part of camera collision is handled by the server telling the viewer a plane that it should stay in front of. llviewermessage.cpp, process_camera_constraint around line 3657 is where the viewer receives that message. Simply commenting out the gAgent.setCameraCollidePlane call should be enough to disable the server side hint completely. - Kelly From robla at lindenlab.com Fri Aug 29 09:32:44 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Aug 29 09:32:50 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <000801c909e8$b5c06f80$0132a8c0@tomhome> References: <000801c909e8$b5c06f80$0132a8c0@tomhome> Message-ID: <48B824AC.4020203@lindenlab.com> On 8/29/08 8:05 AM, Thomas Rowland wrote: > Please LL give the people who keep filling this Developers list with IPR > etc. discussion a list so that developers can discuss developers stuffhere > without all this C___ . > Here is the place to discuss that topic: https://jira.secondlife.com/browse/MISC-44 ....as well as a rationale for why it isn't likely to happen. I need to point out a mailing list policy here: > This mailing list is for discussing problems and ideas that software > developers can directly address and for collaboration on solutions and > improvements, not for turning Linden Lab development staff into > proxies to reach other parts of Linden Lab (e.g. legal, executive, > human resources, etc). Full policy: https://wiki.secondlife.com/wiki/SLDev Please stick with technical issues here. Thanks Rob From me at signpostmarv.name Fri Aug 29 09:37:30 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Aug 29 09:37:36 2008 Subject: [sldev] SL GUI Collection for Pencil Message-ID: <48B825CA.2060001@signpostmarv.name> I don't suppose anyone would be willing to put together a UI element collection for Pencil ? It seems like a fun way to do UI mockups :-P https://addons.mozilla.org/en-US/firefox/addon/8487 ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080829/67ba2efe/smime.bin From gareth at litesim.com Fri Aug 29 10:00:45 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 29 10:00:51 2008 Subject: [sldev] RequestTextureDownload cap In-Reply-To: <61dbdd7d0808280154q10b00124hf4a3b0762ad00900@mail.gmail.com> References: <61dbdd7d0808220523k286b0021s1b8d257a9a9a25e4@mail.gmail.com> <61dbdd7d0808280154q10b00124hf4a3b0762ad00900@mail.gmail.com> Message-ID: <61dbdd7d0808291000n4b4e9366p461b5f2cc00155bb@mail.gmail.com> I've now filed a JIRA with my patch for this: https://jira.secondlife.com/browse/VWR-8833 From sarah77 at gmail.com Fri Aug 29 10:12:00 2008 From: sarah77 at gmail.com (Sarah Hutchinson) Date: Fri Aug 29 10:12:09 2008 Subject: [sldev] SL GUI Collection for Pencil In-Reply-To: <48B825CA.2060001@signpostmarv.name> References: <48B825CA.2060001@signpostmarv.name> Message-ID: <9010c35c0808291012y5a1e3dcet82d3ffb62db42b25@mail.gmail.com> I hadn't heard of Pencil until now. Could be an interesting project to create the Viewer UI elements as a set of widgets. I'd be willing to give that a go. Anyone else interested? - Kippie On Fri, Aug 29, 2008 at 12:37 PM, SignpostMarv Martin wrote: > I don't suppose anyone would be willing to put together a UI element > collection for Pencil ? > > It seems like a fun way to do UI mockups :-P > > https://addons.mozilla.org/en-US/firefox/addon/8487 > > > ~ Marv. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080829/6c44ebff/attachment.htm From me at signpostmarv.name Fri Aug 29 11:10:42 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Aug 29 11:10:48 2008 Subject: [sldev] SL GUI Collection for Pencil In-Reply-To: <9010c35c0808291012y5a1e3dcet82d3ffb62db42b25@mail.gmail.com> References: <48B825CA.2060001@signpostmarv.name> <9010c35c0808291012y5a1e3dcet82d3ffb62db42b25@mail.gmail.com> Message-ID: <48B83BA2.5030403@signpostmarv.name> The intent here is to reduce the barrier for entry in creating UI mockups for feature requests in JIRA- Firefox not being as bloated as photoshop for example :-P ~ Marv Sarah Hutchinson wrote: > I hadn't heard of Pencil until now. Could be an interesting project to > create the Viewer UI elements as a set of widgets. I'd be willing to > give that a go. Anyone else interested? > > - Kippie > > > On Fri, Aug 29, 2008 at 12:37 PM, SignpostMarv Martin > > wrote: > > I don't suppose anyone would be willing to put together a UI > element collection for Pencil ? > > It seems like a fun way to do UI mockups :-P > > https://addons.mozilla.org/en-US/firefox/addon/8487 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080829/6c41ad2c/smime-0001.bin From gareth at litesim.com Fri Aug 29 11:31:08 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 29 11:31:12 2008 Subject: [sldev] A rather perculiar idea (hear me out) Message-ID: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> Anyone on this list a fan of survival horror games? I know it sounds a totally irrelevant question, but here's what i'm thinking: For those who don't know, survival horror games include things like the resident evil series, dino crisis, silent hill etc They normally involve a sole character exploring a ruined city or some other such "scary" location and trying to escape from some kind of threat - zombies, dinosaurs, demons, whatever. The game mechanics often consist in part of an inventory which the character uses to store supplies, weapons, and the key part........ the puzzle items Puzzles are all through these kinds of games and often can only be solved via clues found in documents which the player picks up all over the place. These are known simply as notes and are bits of paper and documents picked up from various locations. They tend to be simple text with a static background illustrating what the document looks like in the background. Those who have played these games will know what i'm talking about, and will also know how they maintain the atmosphere to an extent while going fullscreen. Now, in SL we don't have the aims of maintaining atmosphere as such (except in certain roleplay or gaming regions) but we do for the most part want immersion. So, what about copying this idea with notecards? Take a notecard fullscreen and allow it to render as pure HTML. This could probably be done with pure clientside mods - just replace the notecard dialog with a web browser control and take it full screen. Thoughts anyone? From me at signpostmarv.name Fri Aug 29 11:36:16 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Aug 29 11:36:21 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> Message-ID: <48B841A0.1040109@signpostmarv.name> Given the current functions available in Second Life, it's possible to "fake" this feature now. I've just not gotten around to making the web service yet. I could probably get something put together in under an hour. Gareth Nelson wrote: > Now, in SL we don't have the aims of maintaining atmosphere as such > (except in certain roleplay or gaming regions) but we do for the most > part want immersion. So, what about copying this idea with notecards? > Take a notecard fullscreen and allow it to render as pure HTML. This > could probably be done with pure clientside mods - just replace the > notecard dialog with a web browser control and take it full screen. > > Thoughts anyone? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080829/d8e770de/smime.bin From gareth at litesim.com Fri Aug 29 11:39:38 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 29 11:39:40 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <48B841A0.1040109@signpostmarv.name> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> Message-ID: <61dbdd7d0808291139o18c0b9c6h75b85fadd1966356@mail.gmail.com> Who mentioned a web service? One could probably do this with a HUD attachement, but you'd need to have HTML on a prim or pre-render your notecards. It would be much cleaner with a client mod. On Fri, Aug 29, 2008 at 7:36 PM, SignpostMarv Martin wrote: > Given the current functions available in Second Life, it's possible to > "fake" this feature now. > > I've just not gotten around to making the web service yet. I could probably > get something put together in under an hour. > > Gareth Nelson wrote: >> >> Now, in SL we don't have the aims of maintaining atmosphere as such >> (except in certain roleplay or gaming regions) but we do for the most >> part want immersion. So, what about copying this idea with notecards? >> Take a notecard fullscreen and allow it to render as pure HTML. This >> could probably be done with pure clientside mods - just replace the >> notecard dialog with a web browser control and take it full screen. >> >> Thoughts anyone? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > From labrat.hb at gmail.com Fri Aug 29 12:50:46 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Aug 29 12:50:50 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <61dbdd7d0808291139o18c0b9c6h75b85fadd1966356@mail.gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <61dbdd7d0808291139o18c0b9c6h75b85fadd1966356@mail.gmail.com> Message-ID: And once more for the entire list: The client should be able to be modified to pop up the in-world browser and display arbitrary HTML (local HTML, a webpage etc) On Fri, Aug 29, 2008 at 11:39 AM, Gareth Nelson wrote: > Who mentioned a web service? > One could probably do this with a HUD attachement, but you'd need to > have HTML on a prim or pre-render your notecards. It would be much > cleaner with a client mod. > > On Fri, Aug 29, 2008 at 7:36 PM, SignpostMarv Martin > wrote: >> Given the current functions available in Second Life, it's possible to >> "fake" this feature now. >> >> I've just not gotten around to making the web service yet. I could probably >> get something put together in under an hour. >> >> Gareth Nelson wrote: >>> >>> Now, in SL we don't have the aims of maintaining atmosphere as such >>> (except in certain roleplay or gaming regions) but we do for the most >>> part want immersion. So, what about copying this idea with notecards? >>> Take a notecard fullscreen and allow it to render as pure HTML. This >>> could probably be done with pure clientside mods - just replace the >>> notecard dialog with a web browser control and take it full screen. >>> >>> Thoughts anyone? >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >>> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From gareth at litesim.com Fri Aug 29 13:05:04 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Aug 29 13:05:07 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <61dbdd7d0808291139o18c0b9c6h75b85fadd1966356@mail.gmail.com> Message-ID: <61dbdd7d0808291305s540cac64qf1298a893aed377d@mail.gmail.com> What i'm talking about is loading HTML from a notecard and making it full-screen On Fri, Aug 29, 2008 at 8:49 PM, Harold Brown wrote: > The client should be able to be modified to pop up the in-world > browser and display arbitrary HTML (local HTML, a webpage etc) > > On Fri, Aug 29, 2008 at 11:39 AM, Gareth Nelson wrote: >> Who mentioned a web service? >> One could probably do this with a HUD attachement, but you'd need to >> have HTML on a prim or pre-render your notecards. It would be much >> cleaner with a client mod. >> >> On Fri, Aug 29, 2008 at 7:36 PM, SignpostMarv Martin >> wrote: >>> Given the current functions available in Second Life, it's possible to >>> "fake" this feature now. >>> >>> I've just not gotten around to making the web service yet. I could probably >>> get something put together in under an hour. >>> >>> Gareth Nelson wrote: >>>> >>>> Now, in SL we don't have the aims of maintaining atmosphere as such >>>> (except in certain roleplay or gaming regions) but we do for the most >>>> part want immersion. So, what about copying this idea with notecards? >>>> Take a notecard fullscreen and allow it to render as pure HTML. This >>>> could probably be done with pure clientside mods - just replace the >>>> notecard dialog with a web browser control and take it full screen. >>>> >>>> Thoughts anyone? >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>>> >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > From ordinal.malaprop at fastmail.fm Fri Aug 29 13:50:23 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Fri Aug 29 13:50:28 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <48B841A0.1040109@signpostmarv.name> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> Message-ID: <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> (originally sent individually by mistake) If you are referring to using the current HTML media system, the media changer would surely have to be deeded to the parcel or owned by the parcel owner. This can work well enough in a private sim (I wrote a system myself recently for use in a museum) but not really in public. On 29 Aug 2008, at 19:36, SignpostMarv Martin wrote: > Given the current functions available in Second Life, it's possible > to "fake" this feature now. > > I've just not gotten around to making the web service yet. I could > probably get something put together in under an hour. > > Gareth Nelson wrote: >> Now, in SL we don't have the aims of maintaining atmosphere as such >> (except in certain roleplay or gaming regions) but we do for the most >> part want immersion. So, what about copying this idea with notecards? >> Take a notecard fullscreen and allow it to render as pure HTML. This >> could probably be done with pure clientside mods - just replace the >> notecard dialog with a web browser control and take it full screen. >> >> Thoughts anyone? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From darien.caldwell at gmail.com Fri Aug 29 19:26:20 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Fri Aug 29 19:26:24 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B81B81.5090601@lindenlab.com> References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B81B81.5090601@lindenlab.com> Message-ID: <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> Interestingly enough, i was playing Elder Scrolls: Oblivion last night and was thinking about how the camera 'respects' walls and doesn't allow camming through them. Of course I was thinking there's a lot in that game I wish was in SL :) Maybe one day... On 8/29/08, Kelly Linden wrote: > Argent Stonecutter wrote: >> On 2008-08-28, at 06:41, Tofu Linden wrote: >>> That's actually a server-side issue (the camera ray collision is mostly >>> handled by the physics engine). It's recently been fixed internally, >>> though I'm fuzzy on when it will roll-out. >> >> I have often wondered why SL does that ... keeping the camera on the >> same side as "big enough" prims ... instead of doing what many other >> games do and leaving the camera free to move but hiding the objects >> that would obscure the avatar. >> >> > I've seen games that do both. Most games that come to my mind that hide > objects between the camera and the avatar are isometric top down games > where there isn't a whole lot of camera freedom. Most first or third > person games I'm familiar with move the camera. I am admittedly not > familiar with a whole lot of games at this point (I was at one point, I > swear!). > > SL's camera system is really not great and makes indoor spaces usually > unpleasant (unless they are really large indoor spaces). I would be > very interested in seeing a test implementation that hid the objects as > you describe. The server side part of camera collision is handled by > the server telling the viewer a plane that it should stay in front of. > llviewermessage.cpp, process_camera_constraint around line 3657 is where > the viewer receives that message. Simply commenting out the > gAgent.setCameraCollidePlane call should be enough to disable the server > side hint completely. > > - Kelly > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From GordonWendt at gmail.com Fri Aug 29 20:39:05 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Aug 29 20:39:09 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B81B81.5090601@lindenlab.com> <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> Message-ID: <493033a70808292039v3e0296f3sad71b4fbfef75345@mail.gmail.com> I think open sourcing the viewer let the cat out of the bag on that one. I'm pretty sure it's impossible to enforce server side and because of the open source client can't be reliably enforced client side. That being said there are numerous other reasons that walls should be able to get a flag that identifies them as such, such as avatar physics and physics for physical flagged objects, although unless LL decides to implement a comprehensive system tagging system for all objects and resources I don't foresee that happening. -G.W. On Fri, Aug 29, 2008 at 10:26 PM, Darien Caldwell wrote: > Interestingly enough, i was playing Elder Scrolls: Oblivion last night > and was thinking about how the camera 'respects' walls and doesn't > allow camming through them. Of course I was thinking there's a lot in > that game I wish was in SL :) Maybe one day... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080829/51870111/attachment.htm From dahliatrimble at gmail.com Fri Aug 29 21:01:29 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Aug 29 21:01:31 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <493033a70808292039v3e0296f3sad71b4fbfef75345@mail.gmail.com> References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B81B81.5090601@lindenlab.com> <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> <493033a70808292039v3e0296f3sad71b4fbfef75345@mail.gmail.com> Message-ID: But it could be enforced server side to some extent, as the server could refuse to send the content that lies behind the wall. On Fri, Aug 29, 2008 at 8:39 PM, Gordon Wendt wrote: > I think open sourcing the viewer let the cat out of the bag on that one. > I'm pretty sure it's impossible to enforce server side and because of the > open source client can't be reliably enforced client side. That being said > there are numerous other reasons that walls should be able to get a flag > that identifies them as such, such as avatar physics and physics for > physical flagged objects, although unless LL decides to implement a > comprehensive system tagging system for all objects and resources I don't > foresee that happening. > > -G.W. > > On Fri, Aug 29, 2008 at 10:26 PM, Darien Caldwell < > darien.caldwell@gmail.com> wrote: > >> Interestingly enough, i was playing Elder Scrolls: Oblivion last night >> and was thinking about how the camera 'respects' walls and doesn't >> allow camming through them. Of course I was thinking there's a lot in >> that game I wish was in SL :) Maybe one day... >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080829/01cc1517/attachment.htm From GordonWendt at gmail.com Fri Aug 29 21:25:34 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Fri Aug 29 21:25:40 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B81B81.5090601@lindenlab.com> <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> <493033a70808292039v3e0296f3sad71b4fbfef75345@mail.gmail.com> Message-ID: <493033a70808292125q6dea8ef7taa10f942ddfbd23f@mail.gmail.com> I honestly don't see that happening for several reasons, first, server overhead would skyrocket if it had to check what's a wall and what isn't (walls would have to be flagged as such) then it would have to check the client location, and it would have to on the fly pretty much based on avatar location and camera angle, the latter I think is controlled client side and could easily be spoofed in a response to the server, figure out what to send. The second problem of course is the network overhead this would cause because even if it were feasible that's many more instructions sent from client to server per second to allow for dynamic updating as the character and/or camer angle move, the third of course is the client side issues this would cause on top of the obvious spoofing dillema it would mean coding an entirely new control system into the client to make it so that you don't go through the walls but can only go as far as the wall and even then can't get past the top layer (which would be displaying the texture of it) and don't visually glitch out if you hit a wall. -G.W. On Sat, Aug 30, 2008 at 12:01 AM, Dahlia Trimble wrote: > But it could be enforced server side to some extent, as the server could > refuse to send the content that lies behind the wall. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080830/8953a75f/attachment-0001.htm From dahliatrimble at gmail.com Fri Aug 29 21:42:00 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Aug 29 21:42:03 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <493033a70808292125q6dea8ef7taa10f942ddfbd23f@mail.gmail.com> References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B81B81.5090601@lindenlab.com> <835a5b860808291926m2ba108f1v4ac21fb448d66fb1@mail.gmail.com> <493033a70808292039v3e0296f3sad71b4fbfef75345@mail.gmail.com> <493033a70808292125q6dea8ef7taa10f942ddfbd23f@mail.gmail.com> Message-ID: I think most of this is happening already with interest list management on the server and the resulting object create and delete messages that it sends to the viewer as the avatar position and camera angle changes. On Fri, Aug 29, 2008 at 9:25 PM, Gordon Wendt wrote: > I honestly don't see that happening for several reasons, first, server > overhead would skyrocket if it had to check what's a wall and what isn't > (walls would have to be flagged as such) then it would have to check the > client location, and it would have to on the fly pretty much based on avatar > location and camera angle, the latter I think is controlled client side and > could easily be spoofed in a response to the server, figure out what to > send. The second problem of course is the network overhead this would cause > because even if it were feasible that's many more instructions sent from > client to server per second to allow for dynamic updating as the character > and/or camer angle move, the third of course is the client side issues this > would cause on top of the obvious spoofing dillema it would mean coding an > entirely new control system into the client to make it so that you don't go > through the walls but can only go as far as the wall and even then can't get > past the top layer (which would be displaying the texture of it) and don't > visually glitch out if you hit a wall. > > -G.W. > > On Sat, Aug 30, 2008 at 12:01 AM, Dahlia Trimble wrote: > >> But it could be enforced server side to some extent, as the server could >> refuse to send the content that lies behind the wall. >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080829/191bd10a/attachment.htm From schlenk at uni-oldenburg.de Sat Aug 30 04:33:55 2008 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sat Aug 30 04:33:57 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> References: <48B7549A.7020302@gmail.com> <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> Message-ID: <48B93023.6050505@uni-oldenburg.de> Argent Stonecutter schrieb: > On 2008-08-28, at 20:44, Jan Ciger wrote: >> Finally, for the people pushing for various "EULA"-like fields in the >> object properties - you do not know what you are getting yourself into. >> Your license may not even be a valid license in many places [...] > > It only needs to be a valid license in California and Texas. > > Your idea of using German cut-outs is charming, but the law does not > work that way. Perhaps you can ignore the GPL in Germany, but you can't > sell your GPL-violating products back to someone in the US. True. > > Second Life operates out of California and has an office in Texas. When > you log in to SL, your "property" is in California and Texas. Not > Germany or Japan or India or China. Thats true, but even if the property is 'physically stored' on a server in California it doesn't mean you can evade customer protection (or other like VAT) laws of other countries like Germany or other EU countries. You cannot always force a different legislation on your customers, e.g. in germany its not working for private persons in general (there are exceptions), but you can agree on it if your a corportation. For example most shrink-wrap EULAs targeting private customers are technically null and void in germany because contract law demands that the customer reads them before he buys, which you usually do not or cannot even do, you only can read them when you install the product. So being valid in California and Texas might be good but doesn't help you if you leave those states with any involved party. Michael From dmahalko at gmail.com Sat Aug 30 04:44:02 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Sat Aug 30 04:44:04 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B7E929.7020207@signpostmarv.name> References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B7E929.7020207@signpostmarv.name> Message-ID: On Fri, Aug 29, 2008 at 7:18 AM, SignpostMarv Martin wrote: > If you remove each *object* obscuring the view, the entire build could > disappear. Additional supporting commentary: Since LL limits the number of prims available, it is common to do weird things with very large prims such as making 4 walls of a building from one huge hollow megaprim so as to save prims. So if you were to hide one wall that is "in the way", they all disappear including the ones you wanted to see. With many high efficiency low-prim builds this prim hiding would screw everything up, and the only real fix is to greatly increase prim limits so that prim building efficiency isn't so much an issue. If you could do "per prim face" hiding then this idea might work, though now you run into problems with scuplties, where technically the entire exterior may be considered one "face" of a sphere, and on a severely deformed sculpted sphere, hiding that face makes the sculpt disappear completely. The deepest and most arcane level is per-triangle/normal hiding on the surfaces of prims, but the triangles that collectively form the faces of a prim are not addressable or selectable by the client/editor/scripts, so new functionality would be needed to deal with them. Also, any semitransparent or alpha surfaces could either be "in the way" of the camera or could be the subject of the camera. The camera cannot make an intelligent guess as to what you are trying to view. - Scalar Tardis / Dale Mahalko From gigstaggart at gmail.com Sat Aug 30 06:39:36 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Aug 30 06:39:40 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B93023.6050505@uni-oldenburg.de> References: <48B7549A.7020302@gmail.com> <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> <48B93023.6050505@uni-oldenburg.de> Message-ID: <48B94D98.6050005@gmail.com> Michael Schlenker wrote: > For example most shrink-wrap EULAs targeting private customers are > technically null and void in germany because contract law demands that > the customer reads them before he buys, which you usually do not or > cannot even do, you only can read them when you install the product. So > being valid in California and Texas might be good but doesn't help you > if you leave those states with any involved party. It's not a given that they are valid throughout the US. In the states that did not pass the UCITA (48 of them), EULAs are on shaky legal ground. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080830/9208120f/smime.bin From robin.cornelius at gmail.com Sat Aug 30 07:02:08 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 30 07:02:13 2008 Subject: [sldev] [VWR] Cmake standalone build issues Message-ID: <48B952E0.2030804@gmail.com> Hey Guys, I've hit some small problems now i have come to actualy package the viewer built with cmake. Sorry i have not brough this up sooner but i got bogged down testing the cmake system with out debian packaging and my RL paied job has to come as a priority. 1) The Viewer source is HARD depending on the artwork. This never use to be the case and is a pain. There are valid reasons (such as packaging the viewer for distros) where building with out the artwork is desired. The only actual dependency are the character/*.xml files which the cmake rules for newview append to the file sources. This idealy should be optional or at least non-fatal as it undoes some of the work added to the unix install target to cope with not having artwork present. http://jira.secondlife.com/browse/VWR-8885 2) glh/glh_linear.h This has again moved and is now included with the downloaded libs at the start of the cmake process. This is not helpful when building standalone. The header is not included anywhere else and does not appear to be used by any other packages i can find within debain for example so i really think this should included with the viewer source not appended as a lib. The licence for distributing the source is no more restrictive that distributing the binary/using the header with your binary so there is no reason why it can't be included with the main source code. 3) Ability to rename binary The binary is hard coded to secondlife-bin this could do with being override able from the build options, due to the old trademark issues. 4) Install A minor issue really as i easily work around this by not installing and staging the packaging directly from the output folders but... It would be really good to use the cmake install target to install for my debian packaging but i have hit a snag I build with the following cmake options :- -DINSTALL:BOOL=TRUE \ -DAPP_SHARE_DIR:STRING=/usr/share/omvviewer/ \ -DAPP_BINARY_DIR:STRING=/usr/games/ \ Which does indeed place the files in the correct location (when running make install) but what i need when building from a debian package is to be able to add a INSTALL_PREFIX on the start which does not then upset the APP_SHARE_DIR location which gets hardcoded into the viewer, the idea is to be able to install into a fake root directory under :- /debian//usr/games/ /debian//usr/share/omvviewer/ etc where also contains indra/ doc/ scripts/ ..... then the packaging picks up the files from the staging folder and they are in the correct place to be installed on a system. The only way i can see to achieve this is to patch the build system as cmake will not respect the CMAKE_INSTALL_PREFIX if the locations are an absolute path. Sorry for the lengthy ramble.. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080830/15f23cb7/signature.pgp From bristle2005 at yahoo.com Sat Aug 30 10:26:28 2008 From: bristle2005 at yahoo.com (Bristle) Date: Sat Aug 30 10:26:32 2008 Subject: [sldev] my first impressions of OpenSim and RealXtend Message-ID: <792807.33386.qm@web52112.mail.re2.yahoo.com> First, i got hooked in 1990 after i visited a MUD and since then i have been on many MUDs and then later 3D games like Everquest and the rest.? For several years i ran the maddog.com with vrml, 3D worlds, MUDs, and related things. ? Today,?a want to bring?personal 3D worlds and the softbots.?And in the process i look at every possible way to make this happened.?Last fall i went on SL and concluded that SL or SL-like would be the way to go. And that lead to libsecondlife, OpenSim, and now RealXtend. ? I used OpenSim a few times now and its fairly decent.? The client is standard SL so that the client stuff is easy do to although from reading of this mail list and few things still need to be done. The OpenSim has a lot of things where is seemed like SL and for the most part, it seemed to work. i had a few problems with regions, but this?was in?feb or so. overall, i like OpenSim. ? Now the RealXtend frustrated me.? i had written a post to rex forum but no answer so last night i keep trying to figure it out.? anyway,? from?log its looked that?it was trying to?do?rex thing twice?so i decide to remove that server and redo it. and after awhile (it take a long time for the db to load up) i went through and this time it was good. the first time through i had last but a minute before a got boot and the second time it couldnt move at all.? so i was ready to kicked the RealXtend and watch for another release.? but i instead (i was really determine) restart every thing and with fine. I beat the the server remove/add has nothing to do with it, but i will pretend that it does. ? Now OpenSim uses the SL client but RealXtend does not; it use OGRE -- a nice piece of 3D graphic engine.? So it was nice to see how it was.? Ok, there was problems but?was little ways that i am sure will be clean up. Right now i am looking to mean-time-to-failure and the bigger stuff. ? The server using OpenSim with same rex stuff that right now i dont understand.? but i was really interesting 3D objects themselves.?? Unfortunately, i will have to wait for that. ? Right now i am on standalone mode for both OpenSim and RealXtend.? I am too chicken for more right now.? I was able to get a different look (some time ago) on my main avatar with OpenSim.? But i would like to know where i can get the skin and hair at least. i believe RealXtend may have a modeler for that. ? I would like to see a more CORE/server/server adds because i believe that the CORE could do with a little less SL-like that may appeal for some people but but?others??may not want that. Or at least hide them.? Look at Everquest & the GUI makers for example.? ? so it looks like i will add them in my page (not maddog.com!) and along the libsecondlife -- which they seems to want a name change.? ? ?frank aka maddog/bristle ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080830/5431877a/attachment-0001.htm From robla at lindenlab.com Sat Aug 30 12:49:23 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Aug 30 12:49:29 2008 Subject: [sldev] XML files in artwork (Cmake standalone build issues) In-Reply-To: <48B952E0.2030804@gmail.com> References: <48B952E0.2030804@gmail.com> Message-ID: <48B9A443.8090000@lindenlab.com> Hi Robin, Thanks for the details. Since each of your points is possibly a conversation in its own right, I've split out this part: On 08/30/2008 07:02 AM, Robin Cornelius wrote: > 1) The Viewer source is HARD depending on the artwork. This never use to > be the case and is a pain. There are valid reasons (such as packaging > the viewer for distros) where building with out the artwork is desired. > > The only actual dependency are the character/*.xml files which the cmake > rules for newview append to the file sources. This idealy should be > optional or at least non-fatal as it undoes some of the work added to > the unix install target to cope with not having artwork present. > > http://jira.secondlife.com/browse/VWR-8885 > I'm going to guess that this should actually be moved to the source bundle rather than remain in the artwork bundle, but I need to ask around about this, and perhaps do a little poking around myself. In particular, I'd like to figure out how much these files constitute the trade dress of the viewer versus the raw mechanics of the viewer. In general, the strictly mechanical stuff should be moved to the source, while the files that are more representative of artistic choices should go into the artwork bundle. Rob From mark at identityserver.net Sat Aug 30 14:03:45 2008 From: mark at identityserver.net (Domino Marama) Date: Sat Aug 30 14:04:00 2008 Subject: [sldev] XML files in artwork (Cmake standalone build issues) In-Reply-To: <48B9A443.8090000@lindenlab.com> References: <48B952E0.2030804@gmail.com> <48B9A443.8090000@lindenlab.com> Message-ID: <1220130225.7322.19.camel@domino-laptop> > I'm going to guess that this should actually be moved to the source > bundle rather than remain in the artwork bundle, but I need to ask > around about this, and perhaps do a little poking around myself. If you do move it, could you make sure the license is kept the same, otherwise it gets confusing for things like my Blender avatar importer script. There I do treat the avatar_lad.xml and associated files as artwork. Best Wishes, Domino From robin.cornelius at gmail.com Sat Aug 30 15:22:15 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Aug 30 15:22:35 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: <48B952E0.2030804@gmail.com> References: <48B952E0.2030804@gmail.com> Message-ID: <48B9C817.2010604@gmail.com> Robin Cornelius wrote: > 3) Ability to rename binary > > The binary is hard coded to secondlife-bin this could do with being > override able from the build options, due to the old trademark issues. > Just though i would note that i've opened http://jira.secondlife.com/browse/VWR-8889 w.r.t issue #3 and i've attached a possible patch for this one that allows the binary name to be changed from the cmake parameters or defaults to secondlife-bin if not specified. Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080830/f4507113/signature.pgp From secret.argent at gmail.com Sat Aug 30 16:03:21 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 30 16:02:48 2008 Subject: [sldev] My question about intellectual property and Second Life In-Reply-To: <48B7E824.6090204@gmail.com> References: <48B7549A.7020302@gmail.com> <0A6C6119-E835-4C29-AED3-FB91B1527523@gmail.com> <48B7E824.6090204@gmail.com> Message-ID: Jan, as far as I'm concerned I've used up my quota of debate on this subject. You don't agree with me, that's fine, men of good will can agree to disagree. I will just note that if you think international law is complex, human nature is more complex still, and your desire to get rid of any kind of umbrella term for copyrights, patents, and other similar temporary monopolies is very much fighting uphill against human nature. Uphill, in the snow, wearing speedos. From secret.argent at gmail.com Sat Aug 30 16:14:43 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 30 16:14:07 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: <48B7E929.7020207@signpostmarv.name> References: <48B4F1B1.60008 00@mac.com> <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B7E929.7020207@signpostmarv.name> Message-ID: <8E1A4D2A-C76E-4433-B565-9F72C2A7E0E4@gmail.com> On 2008-08-29, at 07:18, SignpostMarv Martin wrote: > Argent Stonecutter wrote: >> I have often wondered why SL does that ... keeping the camera on >> the same side as "big enough" prims ... instead of doing what many >> other games do and leaving the camera free to move but hiding the >> objects that would obscure the avatar. > > There are several methods of hiding objects, some of which can > affect the FPS performance (anyone who has played Neverwinter > Nights 2 will know what I'm talking about). Yes, and I know that other games have advantages over SL. You don't need a "perfect solution", though, you just need one that's better than what we have now... and I don't think that requires even dealing with most of the issues you bring up. The client is already doing most of the work needed, in rendering the scene, and whatever was more efficient could be used without hurting the immersion... because almost every prim that would be hidden is a prim that is already not visible, since the camera currently moves between those prims and the avatar as you move around. I doubt very much whether content creators would even notice. > You could fade an object to semi-transparent or remove each prim/ > object obscuring the view. Simply eliminating the prims would be best. SL gives you a cinematographic view of the world, and cameras in movies and TV already "pass through" walls that are not shown because they are not present in the set... people are used to that. The "x-ray" view whare portions of the scene are faded out, though, would be disruptive. From secret.argent at gmail.com Sat Aug 30 16:21:46 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 30 16:21:09 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> Message-ID: <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> On 2008-08-29, at 15:50, ordinal.malaprop@fastmail.fm wrote: > If you are referring to using the current HTML media system, the > media changer would surely have to be deeded to the parcel or owned > by the parcel owner. This can work well enough in a private sim (I > wrote a system myself recently for use in a museum) but not really > in public. I think the idea is that a notecard could contain HTML and be opened in the internal browser window. This is a good idea, though the implementation needs to be very careful to avoid allowing external links that could be used as web bugs. From secret.argent at gmail.com Sat Aug 30 16:29:59 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 30 16:29:28 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: <580EF78B-DF3E-41DF-8704-215F1A3EA7CE@gmail.com> <48B68EF8.7060204@lindenlab.com> <9B0C0632-8E97-4489-8831-0055C79A33A8@gmail.com> <48B7E929.7020207@signpostmarv.name> Message-ID: <06A3F1C9-C6C0-4852-9382-0F1C0B0B017A@gmail.com> I get your point, it would be better "per face". However... On 2008-08-30, at 06:44, Dale Mahalko wrote: > Also, any semitransparent or alpha surfaces could either be "in the > way" of the camera or could be the subject of the camera. The camera > cannot make an intelligent guess as to what you are trying to view. I think this should only be applied when in follow camera mode. When you alt-click on an object to view it you're in a completely different regime. From TammyNowotny at mac.com Sat Aug 30 17:38:51 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Sat Aug 30 17:39:06 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> Message-ID: <48B9E81B.5090704@mac.com> Argent Stonecutter wrote: > On 2008-08-29, at 15:50, ordinal.malaprop@fastmail.fm wrote: >> If you are referring to using the current HTML media system, the >> media changer would surely have to be deeded to the parcel or owned >> by the parcel owner. This can work well enough in a private sim (I >> wrote a system myself recently for use in a museum) but not really in >> public. > > I think the idea is that a notecard could contain HTML and be opened > in the internal browser window. > > This is a good idea, though the implementation needs to be very > careful to avoid allowing external links that could be used as web bugs. > If you disallowed web bugs altogether, you would have to nerf the ability to embed images in the web pages, which is one of the very most basic features of HTML. (Unless of course you wanted to host all the images in-world, which seems problematic: for one thing, you would have to store millions of extra textures on the asset servers, and you would even have to ping the hosts to see if they had been updated since the notecard was created.) You could handle the images many email clients do (and most browsers if you click the right preferences) which is not to upload the images until you specifically ask for them, thus letting you read the text without getting the images. But even then, the images serve as a web bug, since the webmaster can still see the recipient's IP in the server log if the recipient views the images. There are valid reasons to embed hyperlinks in notecards, although that is less of a security risk than embedded images since the user would have to decided to click on the links From secret.argent at gmail.com Sat Aug 30 18:14:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Aug 30 18:14:19 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <48B9E81B.5090704@mac.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> <48B9E81B.5090704@mac.com> Message-ID: On 2008-08-30, at 19:38, Tammy Nowotny wrote: > If you disallowed web bugs altogether, you would have to nerf the > ability to embed images in the web pages, which is one of the very > most basic features of HTML. You can store images in notecards. References to "" from the notecard would refer to images in the notecard. > (Unless of course you wanted to host all the images in-world, which > seems problematic: for one thing, you would have to store millions > of extra textures on the asset servers, I doubt very much it would be significantly more images than existing games and products use. If it turns out to be a problem, then consider allowing remote links. I think that if you gave content creators this option they would still opt to pay the L$10 upload fee to get in-world security (such as it is) applied to their images. > and you would even have to ping the hosts to see if they had been > updated since the notecard was created.) Not if the image is in the notecard. > You could handle the images many email clients do (and most > browsers if you click the right preferences) which is not to upload > the images until you specifically ask for them, thus letting you > read the text without getting the images. Which is the minimal level of web security this should offer, yes. Hyperlinks in notecards that refer to other notecards in the same inventory could also be allowed. From lenglish5 at cox.net Sat Aug 30 18:48:02 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Aug 30 18:48:04 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> Message-ID: <48B9F852.4080602@cox.net> Argent Stonecutter wrote: > On 2008-08-29, at 15:50, ordinal.malaprop@fastmail.fm wrote: >> If you are referring to using the current HTML media system, the >> media changer would surely have to be deeded to the parcel or owned >> by the parcel owner. This can work well enough in a private sim (I >> wrote a system myself recently for use in a museum) but not really in >> public. > > I think the idea is that a notecard could contain HTML and be opened > in the internal browser window. > > This is a good idea, though the implementation needs to be very > careful to avoid allowing external links that could be used as web bugs. > AT the least, the llBrowserHUD window could use this, and I think it is possible that you could allow arbitrary prims a more limited functionality for the same thing, like perhaps no recursive calls, and no scripting. Lawson From candide.lemay at gmail.com Sun Aug 31 01:58:32 2008 From: candide.lemay at gmail.com (Candide LeMay) Date: Sun Aug 31 01:58:35 2008 Subject: [sldev] Request for help with modifying client camera behavior In-Reply-To: References: Message-ID: I've faced a similar problem months ago, but instead of trying to implement a full animation toolset inside of SL, I took a different approach. Which was to use Maya (or any other 3D package you know well enough) to animate the camera movement. Then I exported the final frames from Maya to a file and had SL replay them. This gives you robust tools, ability to save and edit the animation, and most importantly, doesn't require massive changes to the SL client itself. I just made it react to few keyboard shortcuts, basically one to read the file with frames, and two for play/stop. And you don't have to stop at camera movement either, you can keyframe any of the windlight settings for visual effects. This short video is the only remaining artifact from my machinima making career - I didn't finish it due to a series of unfortunate events (lost data, sim closed etc) but it demonstrates what you can do (the last few seconds). The footage is straight from SL, no postprocessing was done beyond the conversion to qt. http://lemoo.net/video/priv1.mov candide On Wed, Aug 27, 2008 at 1:13 AM, Vector Hastings wrote: > Hello all, I'm new to this list, never learned C++, but was once a pretty > competent programmer on the IBM midrange platform. > > Please forgive a long first posting, but I've been trying other avenues (as > this will make clear) and find myself needing to escalate to client hacking. > A full treatment of what I'm seeking involves a certain amount of detail, > which now follows: > > I'm trying to launch an ambitious filmmaking project inside Second Life > (machinima). One of the critical keys to getting a more cinematic look to > machinima in Second Life is better camera control. > > The ultimate goal is an in-world camera that can follow a fully > reproducible, smooth, and non-colliding path. > > There's been a lot of work on that already: the 3dNavigator flycam gives us > beautiful smooth paths, non-colliding behavior, focal-length control, but > there is zero reproducibility. There are a number of waypoint systems that > use a vehicle to move the avatar around, allowing for a somewhat > reproducible path, but at the cost of collisions which are unacceptable in > interior spaces, and the effect is often choppy and fine control of camera > angles is not achieved with current systems (even though I suspect that last > item is theoretically possible). > > I've experimented with making a system of waypoints trying to use the > llSetCameraParams option to move just the av's camera. I believe this is the > best middle-ground approach, and will achieve a major step forward in > machinima cameras, but... > > The inherent desire of the camera to return to the filming avatar's default > camera position means my filming results are so choppy that they're only > useful for simulating an earthquake. :-\ > > I know that viewer code is in flux right now, so anything done now is at > risk of having to be re-developed later. But I am also on deadlines, so I'm > reaching out for guidance in how to do this. Ending up with an older client > is workable for me. Hopefully the feature could be ultimately re-engineered > for the more stable 1.21. (I'm also happy to use an RC 1.21 viewer, if it > becomes usable on the main grid in the next two to three weeks. I was a > long-time user of the last two RC candidates, doing a lot of our > pre-production filming with them.) > > > What I think I need is a hack of the client to solve the problem with my > rig, and there's probably multiple approaches: > > 1. Create a debug setting that tells the camera to apply its native, > manual-mode Cam Transition time and Cam Smoothing to changes in scripted > camera location. > This sounds relatively simple, since the initial entry and exit into > scripted camera control obeys those parameters, > but the movement from one location to another does not, which implies to me > that the camera routines know whether > they are under scripted control or not and have been set to behave in this > instantaneous relocation mode when switching > from one camera position and/or focus to the next. > > 2. Create a debug setting that turns off av camera target drift altogether. > There are lag parameters in > llSetCameraParams, but they only seem to be effective when position_locked > = FALSE -- those lag parameters would > give excellent speed control in the camera -- but right now, > position_locked = FALSE means the camera pulls toward > the owning avatar like it's attached with a giant rubber band, and the > effect is a seesawing nightmare. > > 3. Create a flycam recorder. This might be a very general and powerful > solution, but authoring a camera path with it > would probably be unwieldy. One would want the ability to store a camera > path log file to disk in a human readable format > so that it could be tweaked into shape. That tweaking could perhaps be done > with some sort of statistical analysis program, > but I think it would take one dramatically outside the world of SL to do > it. > > 4. Create a waypoint recorder in the client, that simply lets you hit a > button to add a camera position/angle to > the list of spots to hit, then reposition, add another point. It would be > nice to have a speed control, and vital to be > able to save it, and helpful to be able to edit it. This is the basics of > the scripted waypoint systems in-world, > including the one I'm working on. > > I downloaded the code last night, and went to the library to check out > "teach yourself c++" today. > > Somebody have mercy on me, please! > > While I will initially use the camera system I develop on my project, as > soon as we begin releasing episodes, I will also release the camera as a way > of building good-will and buzz in the project. > > If you want to see a little about the project I'm cooking, you can visit > www.vectorpicturestudios.com. > > All the best to you all, > > Vector Hastings > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From gareth at litesim.com Sun Aug 31 02:05:28 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 31 02:05:30 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> Message-ID: <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> Use the solution email clients use: hide images until the user clicks "display images". A simple pre-processor hack could do this. Just search all image and CSS references, and remove them unless the user visits mynotecard.html?showimages=1 or similar. On Sun, Aug 31, 2008 at 12:21 AM, Argent Stonecutter wrote: > On 2008-08-29, at 15:50, ordinal.malaprop@fastmail.fm wrote: >> >> If you are referring to using the current HTML media system, the media >> changer would surely have to be deeded to the parcel or owned by the parcel >> owner. This can work well enough in a private sim (I wrote a system myself >> recently for use in a museum) but not really in public. > > I think the idea is that a notecard could contain HTML and be opened in the > internal browser window. > > This is a good idea, though the implementation needs to be very careful to > avoid allowing external links that could be used as web bugs. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Sun Aug 31 03:48:37 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 31 03:48:01 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> Message-ID: On 2008-08-31, at 04:05, Gareth Nelson wrote: > Use the solution email clients use: hide images until the user clicks > "display images". Already noted, but... > A simple pre-processor hack could do this. Alas, "simple preprocessor hacks" on HTML have proven a wonderful source of security holes over the years. Restrictions need to be implemented at a lower level. From gareth at litesim.com Sun Aug 31 03:54:45 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 31 03:55:25 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> Message-ID: <61dbdd7d0808310354g39c7f022n3998b68c8640ac7d@mail.gmail.com> Just search through all the tags, remove src and href attributes until the user gives the ok. Another approach of course would be to modify the HTML rendering engine, but this would likely be quite messy and involve maintaining a mini-fork of mozilla. On Sun, Aug 31, 2008 at 11:48 AM, Argent Stonecutter wrote: > On 2008-08-31, at 04:05, Gareth Nelson wrote: >> >> Use the solution email clients use: hide images until the user clicks >> "display images". > > Already noted, but... > >> A simple pre-processor hack could do this. > > Alas, "simple preprocessor hacks" on HTML have proven a wonderful source of > security holes over the years. Restrictions need to be implemented at a > lower level. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Sun Aug 31 04:09:31 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 31 04:08:54 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <61dbdd7d0808310354g39c7f022n3998b68c8640ac7d@mail.gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> <61dbdd7d0808310354g39c7f022n3998b68c8640ac7d@mail.gmail.com> Message-ID: <21CBDE80-D645-4E29-A5AA-17134BB430D5@gmail.com> On 2008-08-31, at 05:54, Gareth Nelson wrote: > Just search through all the tags, remove src and href attributes until > the user gives the ok. Spammers have long since come up with solutions for that. Seriously. That's why things like pop-up blockers are *still* not perfect. > Another approach of course would be to modify > the HTML rendering engine, but this would likely be quite messy and > involve maintaining a mini-fork of mozilla. You mean gecko. The rendering engine Mozilla uses is called gecko. Anyway. I'm pretty sure gecko has a mechanism for selectively disabling this kind of thing at a low level. Thunderbird needs it. If it doesn't have one yet, it needs one badly. So it wouldn't be a "fork", it would be a patch delivered upstream to mozilla.org. From gareth at litesim.com Sun Aug 31 04:12:39 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 31 04:12:42 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <21CBDE80-D645-4E29-A5AA-17134BB430D5@gmail.com> References: <61dbdd7d0808291131m4154f29dwd738d1c5e928291a@mail.gmail.com> <48B841A0.1040109@signpostmarv.name> <6420B911-7AF0-4E6B-A411-F70BD9DC2D90@fastmail.fm> <9C7118EA-87F5-43F8-973E-EB5BE98B06DE@gmail.com> <61dbdd7d0808310205r5242ab53p65a1a043d8bbc324@mail.gmail.com> <61dbdd7d0808310354g39c7f022n3998b68c8640ac7d@mail.gmail.com> <21CBDE80-D645-4E29-A5AA-17134BB430D5@gmail.com> Message-ID: <61dbdd7d0808310412v6a636198nbc50b299a492f50d@mail.gmail.com> So, the next step would be to look at the thunderbird source then :) I'll do that when i've got some free time On Sun, Aug 31, 2008 at 12:09 PM, Argent Stonecutter wrote: > On 2008-08-31, at 05:54, Gareth Nelson wrote: >> >> Just search through all the tags, remove src and href attributes until >> the user gives the ok. > > Spammers have long since come up with solutions for that. Seriously. That's > why things like pop-up blockers are *still* not perfect. > >> Another approach of course would be to modify >> the HTML rendering engine, but this would likely be quite messy and >> involve maintaining a mini-fork of mozilla. > > You mean gecko. The rendering engine Mozilla uses is called gecko. > > Anyway. > > I'm pretty sure gecko has a mechanism for selectively disabling this kind of > thing at a low level. Thunderbird needs it. > > If it doesn't have one yet, it needs one badly. So it wouldn't be a "fork", > it would be a patch delivered upstream to mozilla.org. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From missannotoole at yahoo.com Sun Aug 31 08:32:08 2008 From: missannotoole at yahoo.com (Ann Otoole) Date: Sun Aug 31 08:32:10 2008 Subject: [sldev] A rather perculiar idea (hear me out) Message-ID: <171323.1779.qm@web59101.mail.re1.yahoo.com> Actually you should simply use the same attitude applied towards copyright/TOS/EULA/IP Rights and just do whatever your going to do anyway because you can't stop the hackers and criminals anyway so whats the point? ----- Original Message ---- From: Gareth Nelson To: Argent Stonecutter Cc: SLDev List Sent: Sunday, August 31, 2008 7:12:39 AM Subject: Re: [sldev] A rather perculiar idea (hear me out) So, the next step would be to look at the thunderbird source then :) I'll do that when i've got some free time -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080831/c7abe683/attachment-0001.htm From gareth at litesim.com Sun Aug 31 08:38:00 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sun Aug 31 08:38:02 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <171323.1779.qm@web59101.mail.re1.yahoo.com> References: <171323.1779.qm@web59101.mail.re1.yahoo.com> Message-ID: <61dbdd7d0808310838v47c3970cu4babc50958ceb8d5@mail.gmail.com> Except in this case, it is possible to show you an HTML page with the external references hidden, while in the DRM case you can't give someone the content, without giving them the content. On Sun, Aug 31, 2008 at 4:32 PM, Ann Otoole wrote: > Actually you should simply use the same attitude applied towards > copyright/TOS/EULA/IP Rights and just do whatever your going to do anyway > because you can't stop the hackers and criminals anyway so whats the point? > > ----- Original Message ---- > From: Gareth Nelson > To: Argent Stonecutter > Cc: SLDev List > Sent: Sunday, August 31, 2008 7:12:39 AM > Subject: Re: [sldev] A rather perculiar idea (hear me out) > > So, the next step would be to look at the thunderbird source then :) > I'll do that when i've got some free time > > > > From darien.caldwell at gmail.com Sun Aug 31 09:52:05 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sun Aug 31 09:52:09 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <61dbdd7d0808310838v47c3970cu4babc50958ceb8d5@mail.gmail.com> References: <171323.1779.qm@web59101.mail.re1.yahoo.com> <61dbdd7d0808310838v47c3970cu4babc50958ceb8d5@mail.gmail.com> Message-ID: <835a5b860808310952s5d9fa01axd56135ef9af2104f@mail.gmail.com> But i haz stolen your reference already. :o) *sorry, couldn't resist* On 8/31/08, Gareth Nelson wrote: > Except in this case, it is possible to show you an HTML page with the > external references hidden, while in the DRM case you can't give > someone the content, without giving them the content. > > On Sun, Aug 31, 2008 at 4:32 PM, Ann Otoole wrote: >> Actually you should simply use the same attitude applied towards >> copyright/TOS/EULA/IP Rights and just do whatever your going to do anyway >> because you can't stop the hackers and criminals anyway so whats the >> point? >> >> ----- Original Message ---- >> From: Gareth Nelson >> To: Argent Stonecutter >> Cc: SLDev List >> Sent: Sunday, August 31, 2008 7:12:39 AM >> Subject: Re: [sldev] A rather perculiar idea (hear me out) >> >> So, the next step would be to look at the thunderbird source then :) >> I'll do that when i've got some free time >> >> >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Sun Aug 31 10:04:47 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Aug 31 10:04:10 2008 Subject: [sldev] A rather perculiar idea (hear me out) In-Reply-To: <171323.1779.qm@web59101.mail.re1.yahoo.com> References: <171323.1779.qm@web59101.mail.re1.yahoo.com> Message-ID: <80B01877-F3A0-41B5-857A-BA3C8F58060A@gmail.com> On 2008-08-31, at 10:32, Ann Otoole wrote: > Actually you should simply use the same attitude [...] 1. Just because some people take that attitude that doesn't mean everyone does. 2. I'd love to debate that analogy, but this is not the place to go into it. 3. This is not the place to go into it. 4. There is no rule 4. From sldev at bitparts.org Sun Aug 31 14:52:45 2008 From: sldev at bitparts.org (Buckaroo Mu) Date: Sun Aug 31 14:53:29 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? Message-ID: <48BB12AD.1060709@bitparts.org> Has there ever been discussion about this? Using XMPP as a replacement for the current group chat/im system? It's standards-based, highly active development-wise, and would make it easier to add external IM/chat connectivity. The current group chat is one of the biggest causes of detraction in SL - we all know it's a problem. Most of us just deal with it, but some people are actively hostile about it. I have no idea how this would impact the recent trademark filing of SLim(tm), or what plans are currently underway regarding the chat system (other than the recently added moderation tools, which won't affect the root cause of message lag). From sllists at boroon.dasgupta.ch Sun Aug 31 15:36:58 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun Aug 31 15:37:02 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48BB12AD.1060709@bitparts.org> References: <48BB12AD.1060709@bitparts.org> Message-ID: <48BB1D0A.9060408@boroon.dasgupta.ch> Buckaroo Mu schrieb: > Has there ever been discussion about this? Using XMPP as a replacement > for the current group chat/im system? Yes, see http://www.google.com/search?q=site%3Alists.secondlife.com+xmpp The first few search results are "just" about using jabber/XMPP as a gateway to the current inworld IM system (http://jira.secondlife.com/browse/SVC-419) but there was talk about totally replacing the current system with XMPP, too. cheers, Boroondas From sldev at free.fr Sun Aug 31 15:43:56 2008 From: sldev at free.fr (Henri Beauchamp) Date: Sun Aug 31 15:43:59 2008 Subject: [sldev] cmake-SL: a quick'n dirty (but handy) script to build v1.21 and later. Message-ID: <20080901004356.3885903e.sldev@free.fr> Greetings, I published my cmake-SL script on the Wiki, here: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux%29#Automated_libraries_and_headers_adjustments.2C_compilation_and_packaging Enjoy ! Henri. From vector at leafpile.com Sun Aug 31 17:55:13 2008 From: vector at leafpile.com (Vector Hastings) Date: Sun Aug 31 17:55:20 2008 Subject: [sldev] Compile problems on MSVS2005 Express Message-ID: <00b401c90bcd$64c73d70$2e55b850$@com> I've made extensive use of the wikis and feel like I've gotten very close, but I'm a noob to the c++ environment, and I'm still getting these errors: Executing pre-build batch file master: http://secondlife.com/app/message_template/master_message_template.msg current: c:\SL_1_20_2_r92456\linden\scripts\messages\message_template.msg --- PASS --- Older in message LandStatReply: is less deprecated: NotDeprecated vs. UDPDeprecated in base in message ObjectGrabUpdate: missing 1 extra blocks in message ObjectGrab: missing 1 extra blocks in message ObjectDeGrab: missing 1 extra blocks in message ParcelObjectOwnersReply: is less deprecated: NotDeprecated vs. UDPDeprecated in base PREBUILD SUCCESSFUL Linking... llappviewer.obj : error LNK2019: unresolved external symbol "public: static int __cdecl LLFile::stat(char const *,struct _stat64i32 *)" (?stat@LLFile@@SAHPBDPAU_stat64i32@@@Z) referenced in function "private: bool __thiscall LLAppViewer::initCache(void)" (?initCache@LLAppViewer@@AAE_NXZ) llappviewerwin32.obj : error LNK2001: unresolved external symbol "public: static int __cdecl LLFile::stat(char const *,struct _stat64i32 *)" (?stat@LLFile@@SAHPBDPAU_stat64i32@@@Z) llvoiceclient.obj : error LNK2001: unresolved external symbol "public: static int __cdecl LLFile::stat(char const *,struct _stat64i32 *)" (?stat@LLFile@@SAHPBDPAU_stat64i32@@@Z) llviewerparcelmgr.obj : error LNK2019: unresolved external symbol "public: void __thiscall LLParcel::init(class LLUUID const &,int,int,int,__int64,int,int,int,int,float,int)" (?init@LLParcel@@QAEXABVLLUUID@@HHH_JHHHHMH@Z) referenced in function "public: static void __cdecl LLViewerParcelMgr::processParcelProperties(class LLMessageSystem *,void * *)" (?processParcelProperties@LLViewerParcelMgr@@SAXPAVLLMessageSystem@@PAPAX@Z) llwindebug.obj : error LNK2019: unresolved external symbol "class std::basic_string,class std::allocator > __cdecl ll_convert_wide_to_string(wchar_t const *)" (?ll_convert_wide_to_string@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$a llocator@D@2@@std@@PB_W@Z) referenced in function "void __stdcall GetCallStackData(struct _CONTEXT const *,class LLSD &)" (?GetCallStackData@@YGXPBU_CONTEXT@@AAVLLSD@@@Z) ReleaseForDownload/SecondLife.exe : fatal error LNK1120: 3 unresolved externals Any insight? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080831/8f39ba7e/attachment.htm From jwolk at lindenlab.com Sun Aug 31 20:20:30 2008 From: jwolk at lindenlab.com (jwolk@lindenlab.com) Date: Sun Aug 31 20:20:31 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48BB12AD.1060709@bitparts.org> References: <48BB12AD.1060709@bitparts.org> Message-ID: <1511.98.207.79.217.1220239230.squirrel@mail.lindenlab.com> > I have no idea how this would impact the recent trademark filing of > SLim(tm), or what plans are currently underway regarding the chat system > (other than the recently added moderation tools, which won't affect the > root cause of message lag). > I am unsure what discussions have been happening, and moving to something standard sounds like a good idea. I do know however that no matter what the implementation, there will be some amount of computation needed to send the IM to each user and that the total time to send an IM to N number of participants will always be dependent on N. Now, the implementations may be fast enough that it all seems relatively instantaneous, but, at some amount of participants (in this case...some group size), there will be a measurable amount of "lag." Changing implementations may help remedy the situation but won't have "no lag" for all groups, for all time. -Jonathan Linden From jwolk at lindenlab.com Sun Aug 31 20:39:36 2008 From: jwolk at lindenlab.com (jwolk@lindenlab.com) Date: Sun Aug 31 20:39:37 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <1511.98.207.79.217.1220239230.squirrel@mail.lindenlab.com> References: <48BB12AD.1060709@bitparts.org> <1511.98.207.79.217.1220239230.squirrel@mail.lindenlab.com> Message-ID: <1534.98.207.79.217.1220240376.squirrel@mail.lindenlab.com> > I am unsure what discussions have been happening, and moving to something > standard sounds like a good idea. I do know however that no matter what > the implementation, there will be some amount of computation needed to > send the IM to each user and that the total time to send an IM to N number > of participants will always be dependent on N. > Now, the implementations may be fast enough that it all seems > relatively instantaneous, but, at some amount of participants (in this > case...some group size), there will be a measurable amount of "lag." > Changing implementations may help remedy the situation but won't have > "no lag" for all groups, for all time. > Actually let me rephrase. Some implementations may be able to scale by "just throwing hardware at the problem", but that all depends on the details and how scalable things are. -Jonathan From lenglish5 at cox.net Sun Aug 31 20:42:15 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Aug 31 20:42:18 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48BB1D0A.9060408@boroon.dasgupta.ch> References: <48BB12AD.1060709@bitparts.org> <48BB1D0A.9060408@boroon.dasgupta.ch> Message-ID: <48BB6497.9070902@cox.net> Boroondas Gupte wrote: > Buckaroo Mu schrieb: >> Has there ever been discussion about this? Using XMPP as a >> replacement for the current group chat/im system? > Yes, see http://www.google.com/search?q=site%3Alists.secondlife.com+xmpp > The first few search results are "just" about using jabber/XMPP as a > gateway to the current inworld IM system > (http://jira.secondlife.com/browse/SVC-419) but there was talk about > totally replacing the current system with XMPP, too. > > cheers, > Boroondas > _______________________________________________ A search for zero linden's office hour discussions, Zero being a guy who has actually looked at the specifics of replacing the current IM system with XMPP and other systems as part of his job at Linden Lab, yields just a few hits: http://www.google.com/search?hl=en&client=safari&rls=en-us&q=xmpp+site%3Awiki.secondlife.com%2Fwiki%2FUser%3AZero_LInden&btnG=Search There's a bit of reading material already on the wiki in the form of 80+ discussions on these and other AWG-related topics as well as numerous pages trying to summarize things: https://wiki.secondlife.com/wiki/Category:Grid_Interoperability https://wiki.secondlife.com/wiki/Category:Grid_Interoperability_Chat_Logs Lawson From gigstaggart at gmail.com Sun Aug 31 23:44:36 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Aug 31 23:44:40 2008 Subject: [sldev] Question: Replacing current group chat with IRC? (Was: XMPP) In-Reply-To: <1534.98.207.79.217.1220240376.squirrel@mail.lindenlab.com> References: <48BB12AD.1060709@bitparts.org> <1511.98.207.79.217.1220239230.squirrel@mail.lindenlab.com> <1534.98.207.79.217.1220240376.squirrel@mail.lindenlab.com> Message-ID: <48BB8F54.7050405@gmail.com> jwolk@lindenlab.com wrote: > Actually let me rephrase. Some implementations may be able to scale by > "just throwing hardware at the problem", but that all depends on the > details and how scalable things are. IRC is the only system to have solved the problem of massive group chats in a field tested way. IRC channels with 1000 (online) people in them are common. IRC has very similar usage patterns to SL, massive groups, along with one on one conversations. The path to migrate the current system to IRC would be roughly as follows: - Implement a server side legacy->IRC and IRC->legacy gateway that can map groups to channels (probably the hardest part). - Implement functionality in the client that can use either the legacy method or connect to an IRC server and join channels corresponding to the user's groups. The rest is pretty straightforward.. just do a transitional period of 6 months or so, then kill the old clients. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080901/86cf6ddf/smime-0001.bin